Microsoft has been adding to Windows 10 the features of the Enhanced Mitigation Experience Toolkit (EMET) in to the OS. On the 1709 release they added more features and expanded on them as part of Windows Defender Exploit Guard One of the features of great interest for me is Attack Surface Reduction. I have used this feature in EMET with great success as a mitigation to many techniques that abuse built in functionality in Windows. One of the rules of great interest to me is the "Block JavaScript or VBScript from launching downloaded executable content" rule. With the greater visibility now in Windows PowerShell many of us as going back to the old and tested Windows Scripting Host languages and old techniques that have worked for so long.
The description of the rule as per Microsoft documentations says:
Rule: Block JavaScript ok VBScript From launching downloaded executable content JavaScript and VBScript scripts can be used by malware to launch other malicious apps. This rule prevents these scripts from being allowed to launch apps, thus preventing malicious use of the scripts to spread malware and infect machines.
The Rule title mentions to prevent the execution of a downloaded executable. The description mentions the prevention of Javascript and VBScript running applications. So we have 2 different scenarios there.
The rule can be controlled via GPO, PowerShell cmdlets or via MDM (Mobile Device Management). For the purpose of this blog post I will use the PowerShell cmdlet. I will start by looking at the current setting for the rule using the Get-MpPreference cmdlet. The ASR information is in 2 properties one has the rule GUIDs and the other in order their setting.
PS C:\Windows\system32> Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids 3B576869-A4EC-4529-8536-B80A7769E899 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 D3E037E1-3EB8-44C8-A917-57927947596D D4F940AB-401B-4EfC-AADC-AD5F3C50688A PS C:\Windows\system32> Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions 2 2 2 2 2 2 2
The Rule GUIDs are as follows:
The setting for each are:
Not the most useful way to show this details. This would be better handled by a ASR specific cmdlet that showed each rule and its information as its own object instead of lumping all the settings in to a single cmdlet with GUIDs that need one to reference a table in docs to match what they do.
I want to test a collection of execution methods one can do with VBScript:
'https://ss64.com/vb/shell.html Dim obj0 Set obj0 = CreateObject("Wscript.Shell") obj0.Run "powershell.exe", 0 Dim obj1 Set obj1 = GetObject("new:72C24DD5-D70A-438B-8A42-98424B88AFB8") obj1.Run "powershell.exe", 0 'https://msdn.microsoft.com/en-us/library/windows/desktop/gg537745(v=vs.85).aspx 'Operation paramter supports an undocumented option called runas that will ask the user permission 'to elevate via UAC if enabled. Dim obj2 Set obj2 = CreateObject("Shell.Application") obj2.ShellExecute "PowerShell.exe","","","runas",0 Dim obj3 Set obj3 = GetObject("new:13709620-C279-11CE-A49E-444553540000") obj3.ShellExecute "PowerShell.exe","","","runas",0 'requires to run in a high priviledge. Shell.Application with RunAs could be use. 'https://msdn.microsoft.com/en-us/library/aa815396(v=vs.85).aspx Set objMMC = CreateObject("MMC20.Application") Set objDoc = objMMC.Document.ActiveView objDoc.ExecuteShellCommand "powershell.exe","","",7 Set objMMC1 = CreateObject("new:49B2791A-B1AE-4C90-9B8E-E860BA07F889") Set objDoc1 = objMMC1.Document.ActiveView objDoc1.ExecuteShellCommand "powershell.exe","","",7 'Using WMI Win32_Process Set objWMIService = GetObject("winmgmts:\\.\root\cimv2") Set objStartup = objWMIService.Get("Win32_ProcessStartup") Set objConfig = objStartup.SpawnInstance_ objConfig.ShowWindow = 0 set process = GetObject("winmgmts:Win32_Process") result = process.Create ("powershell.exe",null,objConfig,processid) ' Short WMi Method with win32_process set process = GetObject("winmgmts:Win32_Process") set startup = GetObject("winmgmts:Win32_ProcessStartup") startup.ShowWindow = 0 process.Create "notepad.exe",null,startup,processid
Each one uses the COM object and also has a reference to the GUID of the COM. I found out via long hours of testing that ASR will not block or audit any of this execution methods by themselves but that the script must perform a request.
There are multiple ways to perform a request using VBScript/Jscript. We can leverage any of the COM objects in the table bellow.
The Windows Defender Exploit Guard evaluation package Uses the following scripts to test settings:
Jscript
// SCPT:xmlHttpRequest var xmlHttp = WScript.CreateObject("MSXML2.XMLHTTP"); xmlHttp.open("GET", "https://www.bing.com", false); xmlHttp.send(); // SCPT:JSRunsFile var shell = WScript.CreateObject("WScript.Shell"); shell.Run("notepad.exe");
VBScript
' SCPT:xmlHttpRequest set xmlHttp = CreateObject("MSXML2.XMLHTTP") xmlHttp.Open "GET", "https://www.bing.com", False xmlHttp.Send ' SCPT:JSRunsFile set shell = CreateObject("WScript.Shell") shell.run("notepad.exe")
If we remove any of the 2 components the script will not be blocked.
Lets configure the ASR rule for blocking using the Add0MpPreference cmdlet by providing the rule GUID and the Action for it.
Add-MpPreference -AttackSurfaceReductionRules_Ids D3E037E1-3EB8-44C8-A917-57927947596D -AttackSurfaceReductionRules_Actions Enabled
Once that is set we should see an entry in the eventlog indicating that the settings of Windows Defender where modified. The event Id should 5007 and it the data is structured so as to make it easy to parse
The vent will include the old and new value information.
When a script is ran and blocked it is logged under Event Id 1121 and under EventData the ID attribute will reference the ASR rule GUID
For testing I tested each of the execution methods and tested each as a standard VBS/Js script, HTA and as a Scriptlet using the MS2XML COM object for the download segment.
If we look at the COM objects we can use as the download part of a cradle the results are bellow:
We now know as of the version tested that we have some ways to bypass the rules. Would not be surprised if Microsoft updated the engine to also catch these. I did try to also encode the scripts but those that where caught where still caught after being encoded.
One thing I noticed during testing is that when a HTA and a Scriptlet (SCT) was blocked the path to the script was empty. Thankfully the event also includes the Process ID that can be used to match what process was using the specified engine when it was blocked as you can see bellow.
Do remember that Process ID numbers are re-used so the time stamp is of great value in the correlation.
The solution covers some techniques an attacker/Red Team may use but it does not cover all, the fact that both download and execution have to be in the same script is a limiting factor of the ASR rule since some other program may have placed a file on disk or the script may simply execute PowerShell with the payload in the command line. Both red and blue teams should set some automated way to test the rules as Microsoft releases new versions so as to keep they playbooks updated. Blue should work on XPath filters for the rule ID and EventID to aid in their threat hunting action, like the filter bellow to find all actions for blocked events for this specific rule.
$Filter=@{ ID=1121 LogName='Microsoft-Windows-Windows Defender/Operational' Data='D3E037E1-3EB8-44C8-A917-57927947596D'} Get-WinEvent -FilterHashtable $filter
Blue should start by setting the rule in audit mode, collect logs and build a whitelist if false positives are experienced and then build exclusions for those.
As always I hope you found the blog post useful.
Click to Open Code Editor