Статья Weaponizing WDAC: Killing the Dreams of EDR

[stihl]

The Concept​

Windows Defender Application Control (WDAC) is a technology introduced with and automatically enabled by default on Windows 10+ and Windows Server 2016+ that allows organizations fine grained control over the executable code that is permitted to run on their Windows machines. A WDAC configuration applies to the entire machine and affects all users of the device. Applied WDAC configuration is widespread and strict, including rules for user and kernel-mode applications, drivers, DLLs, and scripts. WDAC provides an excellent tool for defenders to block potential threats from execution on Windows endpoints, but WDAC can also be utilized offensively.

While WDAC is often used defensively, it can also be used to block telemetry sources and security solutions such as Endpoint Detection and Response (EDR) sensors. These sensors tend to execute in kernel space and intentionally make themselves difficult to stop or tamper with. However, because WDAC may apply policies to kernel-mode executables and drivers, EDR sensors are at risk if an adversary is able to apply a WDAC policy - which can be done with remote administrative privileges. When a policy is applied at boot the EDR sensor is no longer allowed to run and thus will not load, thereby allowing an adversary to operate without the constraints of EDR.

In short, this is a technique primarily designed at defense evasion and assistance in lateral movement activities within an Active Directory environment. It makes use of a specially crafted WDAC policy to stop defensive solutions across endpoints and could allow adversaries to easily pivot to new hosts without the burden of security solutions such as EDR. At a larger scale, if an adversary is able to write Group Policy Objects (GPOs), then they would be able to distribute this policy throughout the domain and systematically stop most, if not all, security solutions on all endpoints in the domain, potentially allowing for the deployment of post-exploitation tooling and/or ransomware.

• MITRE ATT&CK technique: Impair Defenses (Для просмотра ссылки Войди или Зарегистрируйся)
• Potential Impact: all security tooling across an entire Active Directory Forest may be systematically stopped remotely

Attack Technique​

Although this attack may be executed in a multitude of ways, there is still one common factor - WDAC. Because WDAC policies deny by default, it is extraordinarily trivial to block many EDR sensors from loading. However, a primary consideration for an adversary is both establishing their own access while restricting the access of defensive solutions. Hence the WDAC policy would need to explicitly allow an adversary execution privileges in order to make sense from an offensive perspective. This is where crafting a specialized WDAC policy is most useful. With a custom policy an adversary may stop EDR sensors, while also allowing themselves execution permissions.

This attack may be executed in 3 general phases:

1. An attacker places a WDAC policy in the proper location inside of the Windows Code Integrity folder. C:\Windows\System32\CodeIntegrity
2. Even if the policy is refreshed during runtime, it does not apply to running processes. Thus, the easiest way to restart the EDR sensor is to reboot the machine.
3. Once the machine begins the reboot process, the WDAC policy applies before any EDR driver and stops it before it can execute.

Crafting the WDAC Policy​

The context of the environment being attacked is extremely important for this technique to be successful due to some EDR vendors having Для просмотра ссылки Войди или Зарегистрируйся drivers. These drivers are allowed by default on WDAC policies and will allow WHQL signed EDR drivers to load despite their service binaries being blocked. During testing it was found that although the EDR service was successfully blocked, the EDR’s driver was allowed to load and continued to show activity. While perhaps the most obvious solution to this from an adversarial perspective would be to simply disallow WHQL drivers, this creates significant risk of the endpoint failing to boot. After all, the goal of this technique is ultimately to assist in lateral movement procedures, which becomes impossible if the device never boots. Therefore, a better way to specifically block kernel mode components is to block based off either a specific publisher or file attribute. During testing, it was found that some EDR vendors have drivers that will not allow the machine to boot if not allowed to run. These drivers did not appear to send any network traffic, so it was decided to not block based off of publisher alone and instead focus on blocking based off of file attributes. This proved to be extremely successful, as the targeted drivers and executables were not allowed to load without device disruption.

As previously mentioned, a specialized WDAC policy is extremely important for this attack to make sense from an adversarial perspective. For blocking EDR that does not have WHQL drivers, this policy must at least:

1. Be in enforce mode
2. Allow a generic path so executables (ie post-exploitation capability) may be staged for execution

The first requirement is very easy to implement - just turn off audit mode. For the second requirement, selecting any arbitrary location to store potential post-exploitation capability material will suffice.

Another important consideration is compatibility. Making sure that the WDAC policy will work on the most number of endpoints possible is very important. The policy should therefore use single policy format so as to maximize compatibility. For this example, I will allow application executions in C:\Users\Public. To create this policy, I will be using the App Control Policy Wizard. First, select the Policy Creator

As previously mentioned, a single policy format is the best option for compatibility.

This policy should be restrictive enough to where EDR will surely not run. Therefore, select the Default Windows Mode.

Now, configure the policy with the necessary requirements mentioned earlier. First, disable audit mode and enable the setting Disable Runtime Filepath Rules to allow the whitelisting of file paths in the policy.

Click the Add Custom option and ensure that the:

1. scope is set to user mode only (path rules cannot apply to kernel mode code)
2. action is set to allow
3. rule type is Path
4. Reference File is set to the Folder option, and points to C:\Users\Public\*

Ensure that the rule was correctly added. As a rule of thumb, I generally merge the policy with recommended block rules. Although it is not required.

Now, the policy should generate and appear in the current user’s documents folder.

In addition to the compiled policy, an XML representation of the policy configuration is generated. While the XML file is useful in that it may be edited later to be more versatile, the compiled policy used in the attack itself is the SiPolicy.p7b file.

Finding the Attack Vector​

After creating a WDAC policy, it is time to find a way to use it. There are three major attack types:

1. Local machine
2. Remote machine
3. Full domain

For a single machine (local/remote), all that is needed to deploy a WDAC policy is write permissions on C:\Windows\System32\CodeIntegrity\, which by default requires that you have administrative permissions.

For a full domain deployment of WDAC, a user needs the ability to create Group Policy Objects (GPOs) for the domain and stage the policy in a location that all domain computers can read from. This staging location will typically consist of an SMB share like the SYSVOL share on a domain controller, but is not required to be. Thus, an adversary can get extremely creative with policy locations - it is required to be either a UNC path or a locally valid path that the local machine accounts (LOCAL SYSTEM) on the domain has access to.

Local Machine​

Using this attack on a local machine is by far the most simple out of all methods previously mentioned. To apply the WDAC policy, the policy (SiPolicy.p7b) needs to be moved to the proper location (C:\Windows\System32\CodeIntegrity\).

cp .\SiPolicy.p7b C:\Windows\System32\CodeIntegrity\

Just to confirm, check the status of the EDR service:

Next, reboot the machine and check if the EDR service is still running:

Now that EDR is disabled, it is trivial to disable Windows Defender and begin dropping other tooling to disk in the location whitelisted by the WDAC policy (in this example C:\Users\Public\*).

Remote Machine​

Remote deployment, although very similar to deployment on a local machine, has one slight difference: the movement of the WDAC policy and rebooting occurs remotely. This may occur through a variety of means, but the most convenient way is via Windows built-in SMB shares. Thankfully, because the only action to implement the WDAC configuration is moving the policy into the CodeIntegrity folder, this can be done with administrative privileges through the built in C$ or ADMIN$ shares.

Below is a simple example of uploading the policy directly from a Linux machine.

smbmap -u Administrator -p P@ssw0rd -H 192.168.4.4 --upload "/home/kali/SiPolicy.p7b" "ADMIN\$/System32/CodeIntegrity/SiPolicy.p7b"

After placing the WDAC policy in the correct place, reboot the machine:

smbmap -u Administrator -p P@ssw0rd -H 192.168.4.4 -x "shutdown /r /t 0"

Additionally a purpose-built tool has been created to carry out this attack. Для просмотра ссылки Войди или Зарегистрируйся is a custom tool written in C# by Для просмотра ссылки Войди или Зарегистрируйся specifically meant to be run in memory as part of post-exploitation lateral movement activities. The example below uses inlineExecute-Assembly (created by Для просмотра ссылки Войди или Зарегистрируйся) to execute the .NET assembly in memory.

inlineExecute-Assembly --dotnetassembly C:\Tools\Krueger.exe --assemblyargs --host ms01

Full Domain​

Although using this attack technique on a singular host is already impactful, it can be made much more potent if an adversary is able to gain administrative access to an Active Directory domain. Once attaining the permissions of a Domain Admin, Enterprise Admin, or group that may create GPOs, an adversary may distribute a malicious group policy to computers in the domain. This poses a whole host of threats to an organization, but in the case of this attack technique in particular, every EDR sensor on every endpoint could be stopped within a relatively short period of time by simply applying a WDAC policy and rebooting the machines. The execution flow for this attack is laid out below:

1. Gain administrative access
2. Stage the WDAC policy in a location where every domain computer can access it
3. Create a GPO that:
   • Applies the WDAC policy
   • (Optional) Turns off Windows Defender and Windows Defender Firewall
   • Schedules a reboot as soon as possible
4. Wait for machines to reboot
5. EDR and potentially Defender is no longer active on any Windows machine in the domain

Krueger​

As briefly mentioned previously, Krueger is a .NET post-exploitation Proof of Concept (PoC) for this technique. Krueger is primarily used for assistance with lateral movement activities in Active Directory networks by disabling EDR remotely and is intended to be run in memory with inlineExecute-Assembly or execute-assembly. With administrative permissions over a remote target device, Krueger writes a specially crafted malicious WDAC policy embedded within the .NET assembly at compile-time and referenced for usage at run-time into the CodeIntegrity directory on the target device. Once the policy is read directly out of memory onto the target device, the win32api function InitiateSystemShutDownEx is called from Krueger to trigger a reboot of the remote target device. Once the device is fully rebooted the WDAC policy will be applied, preventing the start of user and kernel-mode EDR protections. Finally, an adversary can use additional tools along with their previously gained administrative access utilized to laterally move to the target.

The tool is available Для просмотра ссылки Войди или Зарегистрируйся.

Для просмотра ссылки Войди или Зарегистрируйся​