Recently there have been tweets about Windows Attack Surface Reduction (ASR) rules and I wanted to take the chance to dive into a topic that I have discussed in my Offensive WMI workshops given at Wild West Hackin Fest and BSidesDC.
Matt Graeber wrote an excellent white paper on the topic for BlackHat USA, and attackers have been using WMI to attack organizations for quite some time. One of the actions an attacker can perform is to remotely start a process via WMI. This can easily be done with PowerShell, assuming that the attacker has administrative rights on the targeted system, via the following command:
Invoke-WMIMethod -Class Win32_Process -Name Create -ComputerName <HOSTNAME/IP> -ArgumentList notepad.exe
The above command would start notepad.exe on the targeted system under the context of the user account that ran the PowerShell command.
However, Microsoft is very much aware of attackers leveraging WMI, along with other techniques, to compromise Windows systems. As a result, they’ve begun to create Windows ASR rules to address commonly abused vectors such as:
- Block all Office applications from creating child processes
- Block Office applications from injecting code into another process
- Block untrusted and unsigned processes that run from USB
- Block execution of potentially obfuscated scripts
- …and more
However, there is one rule in particular that piqued my interest when playing with Windows ASR rules:
- Block process creations originating from PSExec or WMI commands
I found this intriguing and wanted to validate that the rule indeed blocked process creations. I tested this on a local system and enabled the ASR rule to block process creations originating from PSExec or WMI commands.
After validating that the rule was enabled, I ran the previous PowerShell command to spawn a notepad.exe process and received the following results:
The first thing I immediately noticed was that the return value was “2”, and not “0”, indicating that the action was not successful. In addition, Windows displayed the pop-up in the bottom right corner of the computer alerting the current user that an action was blocked. Enabling the rule did prevent notepad from ever spawning on the system, and therefore blocked a major vector that’s used to attack systems.
However, I had a theory that I wanted to test. If an administrator has the ability to set a rule remotely on a system, it’s reasonable to assume that they would also have the ability to disable a rule remotely on a system, right? To continue with this line of thought, if an administrator has the ability to set a configuration for a system, they would also have the ability to modify the configuration, correct?
I wanted to test this, and began by reviewing the PowerShell cmdlets which let you change these settings. If you’ve read my last few blog posts on remotely enumerating and remotely modifying antivirus configurations, you’ll recognize the following cmdlets which are used to identify active ASR rules, antivirus, and to set their configuration:
You can use Get-MpPreference to identify if any ASR rules are enabled on a system, and use Set-MpPreference to modify the enforcement of existing rules. But, how can this be done remotely?
If you review the syntax for the Set-MpPreference cmdlet, or our previous blog posts on the topic, you can provide the Set-MpPreference cmdlet a CIM Session to authenticate and modify the targeted system. It’s reasonable to assume since you have local administrative rights on the the targeted system, that you can create a CIM Session with the targeted system and change its Windows ASR rules configuration.
So while I could not create a process over WMI on the the targeted system, I did create a CIM session, and passed it into the Set-MpPreference cmdlet to set the ASR rule pertaining to WMI and PSExec into a disabled state.
After changing the rule, I was successfully able to spawn notepad on the system indicating that I was able to disable the ASR rule preventing that action.
Looking for Modifications
When an ASR rule is enabled on a system, a registry key is set with the rule ID and its current status under the following path:
HKLM\Software\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules
If you are able to identify modifications to the enforcement status of any ASR rule located in this path, it is possibly an indicator of someone attempting to disable ASR rules. It would be worth verifying if it is an authorized change or not.
In the event that an attacker is using PowerShell to modify ASR rule enforcement, PowerShell logging can empower you to trace back to the system and account that made the change to validate if it is authorized.
I hope that this blog posts helps, don’t hesitate to contact us at FortyNorth Security for any questions!