Recently I followed the tracks of an attacker who had exploited administrator rights on an unpatched Windows 10 System. Further attacks on other internal systems were initially stopped by Windows 10 AppLocker. The execution of powershell/cmd where also forbidden by AppLocker. Minutes later, the hacker had overcome this security measure and continued his attack. AppLocker obviously had to have a vulnerability.
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
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 ->
[Enter]. Then navigate to AppLocker/Executable Rules and create a new rule. Click
Use the default setting for Action:
*as Path, click
We do not need any exceptions, click on
Make sure that you click on
[No]in the following dialog box.
After completing the dialog, the Group Policy Editor should look like this.
In the Local Group Policy Editor, click
Configure rule enforcement.
Apply the settings as shown in the picture.
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
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.
If you want to play around with this technique and learn how to protect against this hack, we have made the generated files available for download in our github repository.
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 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.