The attacker got his administrative rights over an already patched vulnerability. Unfortunately, the patch had not yet been applied to the system. Then the intruder tried to attack other internal systems using an exploit scanner. Windows 10 AppLocker stopped the execution of the malicious software. Only a few minutes later, the attacker was able to execute his code. How could this happen?

ANALYSIS OF THE ATTACK

When AppLocker processes the Windows group policies, it generates rule files and stores them in the c:\windows\system32\AppLocker directory. These files are queried to decide if a program is allowed to run. As soon as the group policies are changed, all rule files are recreated. This process can be enforced by executing GPUpdate /Force. Rules in this directory can be viewed via the GUI gpedit.msc.

Less known may be that AppLocker rules are also read from the directory c:\windows\system32\applocker (note the lower case). Rules located in this directory are not displayed in the Windows GUI. The hacker had created wildcard rules for executing executable files and copied them to this directory. After that, he only had to reboot the system to execute any code. All this was possible without a GUI. A terminal created with a reverse shell was sufficient. For a system administrator, this change was not visible via a GUI.


CREATE THE WILDCARD RULES

To create the wildcard rules for AppLocker, we must first start the Windows Application Identity service. In Windows PowerShell, we can use the following command to do this.

PS C:\Windows\system32> Start-Service -name "AppIDSvc"


Next we start the Windows Local Group Policy Editor with a right click on Start -> run -> gpedit.msc -> [Enter]. Then navigate to AppLocker/Executable Rules and create a new rule. Click [Next].
Create new AppLocker Rule


Use the default setting for Action: Allow.
Use the default setting for Action: Allow.

Select Path and click [Next].
Select `Path` and click on [Next].


Enter *as Path, click [Next].
Enter * as Path, click on [Next].


We do not need any exceptions, click on [Next].
We do not need any exceptions, click on [Next].


Make sure that you click on [No] in the following dialog box.
Make sure you click on [No] in the follwing dialog box.


After completing the dialog, the Group Policy Editor should look like this.
After completing the dialog, the Group Policy Editor should look like this.


In the Local Group Policy Editor, click AppLocker -> Configure AppLocker -> Configure rule enforcement.
Apply the settings as shown in the picture.
Click on AppLocker -> Configure AppLocker -> Configure rule enforcement and apply the settings


As the last step open a Windows 10 command prompt and run the following command to process our previously configured rules.

C:\Users>gpupdate /force
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.


C:\Users>

After 1 to 5 minutes our new rule files will appear in the directory C:\Windows\System32\AppLocker.
Create new AppLocker Rule


All we need to do now is copy these files to our target system in the directory C:\Windows\System32\applocker. After that the system must be restarted. Now we can run any program we want to run. The manipulated rules are not visible in the Windows GUI.

HOW TO DEFEND AGAINST THE ATTACK

At the moment, on 19 May 2019, the technology described still works. Both on a fully patched Windows 10 (version 1903) and on a Windows Server 2019.

The only way to prevent this attack is to permanently monitor the C:\Windows\System32\applocker and C:\Windows\System32\AppLocker directories for changes. The files in both AppLocker directories should have the same timestamps. If the timestamps are different, manipulation is likely. Unfortunately an attacker can hide his traces very well with a gpupdate /force. Therefore the monitoring should be done in short intervals. But even then, there are some other techniques that a user can use to handle AppLocker administrative privileges. You have to be aware that this technique is actually ineffective for administrators.