Tools · Windows security and Event Logs · 18 / 27
AppLocker vs App Control for Business (WDAC): application allowlisting basics
Understand how each allowlisting technology decides what may run, start with audit mode, read the block events, and roll out rules safely.
Allowlisting in one paragraph
Antivirus tries to block known bad programs. Allowlisting flips that: only approved programs may run. Most ransomware and commodity malware arrive as an executable or script dropped in a user-writable folder, and a policy that blocks execution from those folders stops a large share of them.
Windows has two options. AppLocker is older, configured through Group Policy with rules by path, publisher, or hash, and enforced per user. App Control for Business, formerly Windows Defender Application Control (WDAC), is enforced by the kernel, applies to all users including administrators, and is Microsoft’s recommended direction.
Rule types
Publisher rules trust signed code from a vendor, optionally by product and version. Path rules allow everything under a folder, safe only for folders standard users cannot write, such as Program Files. Hash rules allow one exact file. AppLocker’s default rules allow Windows and Program Files for everyone and everything for administrators, which is a reasonable start.
Both technologies cover scripts, installers, and DLLs in addition to executables, and both push PowerShell into Constrained Language Mode when it is not explicitly trusted.
Lab: AppLocker in audit mode
On a lab Windows Enterprise or Education VM, create AppLocker default executable and script rules, set enforcement to Audit only, and start the Application Identity service. Copy a harmless executable to Downloads and run it. Query the AppLocker EXE and DLL log for Event 8003, which records “would have been blocked”.
After a week of audit data from real machines, you have the list of exceptions to add before switching to enforce, where blocks appear as Event 8004.
Set-Service AppIDSvc -StartupType Automatic; Start-Service AppIDSvc # Create default rules in secpol.msc > Application Control Policies > AppLocker, set Audit only Get-AppLockerPolicy -Effective -Xml | Out-File C:\applocker-effective.xml Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' -MaxEvents 20 | Where-Object Id -in 8003,8004 | Format-Table TimeCreated, Id, Message -Wrap
Rolling out
Start with a pilot group, collect audit events centrally, add publisher rules for legitimate software, then enforce. Keep a documented process for requesting new software so users have a path that is not “turn it off”.
For WDAC, Microsoft provides base policies such as “Allow Microsoft” and “Default Windows”, and the App Control Wizard to merge them with your rules. Test in audit mode with CodeIntegrity Operational events 3076 before enforcing.
Diagram
Allowlisting rule types
Choose the rule that is hardest to abuse.
- Publisher
Trust signed code from a vendor. Durable across updates.
- Path
Trust a folder. Only safe where users cannot write.
- Hash
Trust one exact file. Breaks on every update.
- Audit mode
Log would-be blocks before enforcing.
Check yourself
1. Which AppLocker event means a file would have been blocked in audit mode?
2. Why is a path rule for C:\Users\*\Downloads dangerous?
3. What is a key difference of App Control for Business (WDAC) versus AppLocker?