Tuesday, June 21, 2016

Malware Disabling UAC

I recently saw malware that when executed dropped and executed another VBS script that was interesting, the VBS script code is here. In a nutshell, what it is doing is disabling UAC (User Access Control) prompting [aka LUA] on the Windows server so that the attacker can accomplish their desired tasks silenty behind the scenes with no prompting of the user.

As you can see below the attacker basically has 2 routes this code could take. The first route (red) is actually a recursive call back to this same script. The 2nd route (green)is the route that actually updates the UAC and restarts the workstation. Basically what this is saying is if the attacker runs this VBS script with no parameters, the 1st route (red) sets the default parameters, and if the attacker runs this VBS script with the appropriate parameters already passed thru then the script skips the 1st section and immediately runs the 2nd block (the else statement) (green).

If WScript.Arguments.length =0 Then
  Set objShell = CreateObject("Shell.Application")
  objShell.ShellExecute "wscript.exe", Chr(34) & WScript.ScriptFullName & Chr(34) & " uac", "", "runas", 1
  Const UAC_DISABLE = 0
  Const UAC_REGKEY = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA"
  Set Shell = CreateObject( "WScript.Shell" )
  Shell.Run "C:\WINDOWS\system32\shutdown.exe -r -t 10"
end if

In the 1st chunk (red) the attacker is checking if there are no parameters passed. If so, then he opens a command prompt shell and executes the wscript.exe executable and sends to the name of this script plus the single parameter 'uac' (which isn't actually used anywhere). But the attacker also makes sure that the wscript.exe executable is run with elevated privileges (runas 1 is the equivalent of right-click run as administrator). This will essentially re-execute the script we're already in but passes in 1 parameter and ensures it's running as admin.

In the 2nd chunk (green) this is where the attacker does the damage. He creates a Windows Script Host object that can run commands against the windows operating system. There are 2 commands of interest. The first is Shell.RegWrite which means he's going to create or overwrite an existing registry entry. In this case he's writing over the EnableLUA property and setting the value to 0 which essentially turns off UAC prompting so the user will be blind to the fact that elevated commands are being run. The only downsides for the attacker is that this script itself will initially prompt the user with a UAC prompt which is windows essentially making a last ditch effort to save the user from disabling UAC. The other downside for the attacker is that the system needs to be rebooted for this to take effect. So the next command is to do Shell Run which runs a command prompt with the shutdown.exe executable saying to restart in 10 seconds.

If the user clicks yes to the UAC prompt and runs this script, there will be no more UAC prompting for elevated commands and the attacker can freely run his malware behind the scenes without the end user noticing.

More about neonprimetime

Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. An Invoice email and a Hot mess of Java

Top Github Contributions
  1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

1 comment:

  1. When it comes to offensive tradecraft, this is about as crude as it gets. However, this example clearly reiterates that malware doesn't have to be sophisticated or elegant to successfully infect some users.

    To prevent this technique from being successful, user's should not be granted Administrative privileges (same recommendation for the past 10 years). For domain users, Group Policy should be implemented which forces UAC to be enabled. Login scripts can be used to validate the status of UAC which doubles as a crude form of locally gathered threat intelligence.