implementing-application-whitelisting-with-applocker
Implements application whitelisting using Windows AppLocker to restrict unauthorized software execution on endpoints, reducing attack surface from malware, unauthorized tools, and shadow IT. Use when enforcing application control policies, meeting compliance requirements for software restriction, or preventing execution of unsigned or untrusted binaries. Activates for requests involving AppLocker, application whitelisting, software restriction, or executable control.
- License 许可
- Apache-2.0
- 最近更新
- 2026-08-31
- Stars
- ★ 3.6w
- Forks
- 4.4k
01 前言 Front Matter
- name
- implementing-application-whitelisting-with-applocker
- tags
- [ "endpoint", "AppLocker", "application-whitelisting", "windows-security", "software-restriction" ]
- author
- mahipal
- domain
- cybersecurity
- license
- Apache-2.0
- version
- 1.0.0
- nist_csf
- [ "PR.PS-01", "PR.PS-02", "DE.CM-01", "PR.IR-01" ]
- subdomain
- endpoint-security
- description
- Implements application whitelisting using Windows AppLocker to restrict unauthorized software execution on endpoints, reducing attack surface from malware, unauthorized tools, and shadow IT. Use when enforcing application control policies, meeting compliance requirements for software restriction, or preventing execution of unsigned or untrusted binaries. Activates for requests involving AppLocker, application whitelisting, software restriction, or executable control.
- mitre_attack
- [ "T1055", "T1547", "T1059", "T1036", "T1027" ]
02 资源文件 7
- 资产文件assets/template.md2.7 KB
- 许可证LICENSE11.0 KB
- 参考文档references/api-reference.md1.5 KB
- 参考文档references/standards.md2.8 KB
- 参考文档references/workflows.md3.8 KB
- 脚本scripts/agent.py7.1 KB
- 脚本scripts/process.py9.1 KB
03 SKILL.md 正文
Implementing Application Whitelisting with AppLocker
When to Use
Use this skill when:
- Implementing application control to prevent unauthorized software execution on Windows endpoints
- Meeting compliance requirements (PCI DSS 6.4.3, NIST 800-53 CM-7, ACSC Essential Eight)
- Blocking common attack vectors: living-off-the-land binaries (LOLBins), script-based attacks, unauthorized admin tools
- Restricting software installation in kiosk, POS, or high-security environments
Do not use this skill for macOS/Linux application control (use OS-native tools like Gatekeeper or AppArmor) or for enterprise-grade WDAC (Windows Defender Application Control) deployments.
Prerequisites
- Windows 10/11 Enterprise or Education, or Windows Server 2016+
- Application Identity service (AppIDSvc) enabled on target endpoints
- Active Directory with Group Policy Management Console (GPMC)
- Complete application inventory of approved software
- Test OU with representative endpoints for policy validation
Workflow
Step 1: Inventory Approved Applications
Before creating AppLocker rules, catalog all legitimate software:
# Generate application inventory on reference endpoint
Get-AppLockerFileInformation -Directory "C:\Program Files" -Recurse `
-FileType Exe | Export-Csv "C:\AppLocker\app_inventory_progfiles.csv" -NoTypeInformation
Get-AppLockerFileInformation -Directory "C:\Program Files (x86)" -Recurse `
-FileType Exe | Export-Csv "C:\AppLocker\app_inventory_progfiles86.csv" -NoTypeInformation
# Include Windows system executables
Get-AppLockerFileInformation -Directory "C:\Windows" -Recurse `
-FileType Exe | Export-Csv "C:\AppLocker\app_inventory_windows.csv" -NoTypeInformation
Step 2: Create AppLocker Policy with Default Rules
# In Group Policy Editor (gpedit.msc) or GPMC:
# Navigate to: Computer Configuration → Policies → Windows Settings
# → Security Settings → Application Control Policies → AppLocker
# Enable default rules for each rule collection:
# - Executable Rules: Allow Everyone to run files in Program Files and Windows
# - Windows Installer Rules: Allow Everyone to run digitally signed MSIs
# - Script Rules: Allow Everyone to run scripts in Program Files and Windows
# - Packaged App Rules: Allow Everyone to run signed packaged apps
# PowerShell: Generate default rules
$defaultRules = Get-AppLockerPolicy -Local -Xml
Set-AppLockerPolicy -XmlPolicy $defaultRules -Merge
Step 3: Create Publisher-Based Rules (Preferred)
Publisher rules are the most maintainable since they survive application updates:
<!-- Example AppLocker policy XML for publisher rules -->
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<!-- Default: Allow Windows binaries -->
<FilePublisherRule Id="a9e18c21-ff54-4677-b3ac-4b9a03261f6c"
Name="Allow Microsoft signed" Description="Allow all Microsoft-signed executables"
UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION*"
ProductName="*" BinaryName="*">
<BinaryVersionRange LowSection="*" HighSection="*"/>
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<!-- Allow specific third-party vendor -->
<FilePublisherRule Id="b2e28c32-aa65-5788-c4bd-5c0b14372e7d"
Name="Allow Adobe Acrobat" Description="Allow Adobe-signed Acrobat executables"
UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=ADOBE INC.*"
ProductName="ADOBE ACROBAT*" BinaryName="*">
<BinaryVersionRange LowSection="*" HighSection="*"/>
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
Step 4: Block Known-Abused Binaries (LOLBins)
# Deny rules for commonly abused living-off-the-land binaries
# These are legitimate Windows tools frequently used by attackers
$denyPaths = @(
"%SYSTEM32%\mshta.exe",
"%SYSTEM32%\wscript.exe",
"%SYSTEM32%\cscript.exe",
"%SYSTEM32%\regsvr32.exe",
"%SYSTEM32%\certutil.exe",
"%SYSTEM32%\msbuild.exe",
"%SYSTEM32%\installutil.exe",
"%WINDIR%\Microsoft.NET\Framework\*\msbuild.exe",
"%WINDIR%\Microsoft.NET\Framework64\*\msbuild.exe"
)
# Create deny rules in AppLocker policy for standard users
# Important: Deny rules take precedence over Allow rules
# Apply only to standard users (not admins who may need these tools)
Step 5: Configure Script Rules
Script Rules (critical for preventing script-based attacks):
Allow:
- Scripts in C:\Program Files\* (publisher or path-based)
- Scripts in C:\Windows\* (default Windows scripts)
- Approved admin scripts from \\fileserver\scripts\*
Deny (for standard users):
- PowerShell scripts from user-writable directories
- VBScript from %TEMP%, %APPDATA%, %USERPROFILE%\Downloads
- JavaScript (.js) from any user-writable location
DLL Rules (optional, high performance impact):
- Enable only in high-security environments
- Allow signed DLLs from Program Files and Windows directories
- Performance impact: 5-10% CPU increase during DLL loading
Step 6: Deploy in Audit Mode First
# CRITICAL: Always deploy AppLocker in Audit mode before Enforce mode
# Audit mode logs what would be blocked without actually blocking
# Set enforcement mode to Audit Only in GPO:
# AppLocker → Executable Rules → Properties → Configured: Audit only
# AppLocker → Script Rules → Properties → Configured: Audit only
# AppLocker → Windows Installer Rules → Properties → Configured: Audit only
# Ensure Application Identity service is running
Set-Service -Name AppIDSvc -StartupType Automatic
Start-Service AppIDSvc
# Link GPO to test OU
New-GPLink -Name "AppLocker-Audit-Policy" `
-Target "OU=AppLocker-Pilot,DC=corp,DC=example,DC=com"
# Monitor audit logs for 2-4 weeks
# Event Log: Applications and Services Logs → Microsoft → Windows → AppLocker
# Event IDs:
# 8003 = EXE/DLL would be blocked
# 8006 = Script/MSI would be blocked
# 8023 = Packaged app would be blocked
Step 7: Analyze Audit Logs and Refine Rules
# Export AppLocker audit events
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" `
-FilterXPath "*[System[EventID=8003]]" |
Select-Object TimeCreated,
@{N='User';E={$_.Properties[0].Value}},
@{N='FilePath';E={$_.Properties[1].Value}},
@{N='FileHash';E={$_.Properties[4].Value}} |
Export-Csv "C:\AppLocker\audit_blocked_exes.csv" -NoTypeInformation
# Review blocked applications
# For each blocked legitimate application:
# 1. Create a publisher rule (if signed) or path rule (if unsigned)
# 2. Add to AppLocker policy
# 3. Re-audit for 1 additional week
Step 8: Switch to Enforce Mode
# After audit period with no legitimate applications blocked:
# Change enforcement mode from Audit to Enforce
# Update GPO:
# AppLocker → Executable Rules → Properties → Configured: Enforce rules
# AppLocker → Script Rules → Properties → Configured: Enforce rules
# Phased enforcement:
# Week 1: Enforce EXE rules only
# Week 2: Enforce Script rules
# Week 3: Enforce MSI rules
# Week 4: (Optional) Enforce DLL rules
# Maintain monitoring: Event IDs 8004 (blocked EXE), 8007 (blocked script)
Key Concepts
| Term | Definition |
|---|---|
| Application Whitelisting | Security model that allows only pre-approved applications to execute, denying everything else by default |
| Publisher Rule | AppLocker rule based on digital signature; most resilient to application updates |
| Path Rule | AppLocker rule based on file system path; less secure as attackers can place files in allowed paths |
| Hash Rule | AppLocker rule based on file hash; most restrictive but breaks on every application update |
| LOLBin | Living Off the Land Binary; legitimate OS tool abused by attackers to avoid detection |
| Audit Mode | AppLocker logs policy violations without blocking; essential for rule refinement |
| Enforcement Mode | AppLocker actively blocks applications that violate policy rules |
Tools & Systems
- AppLocker (built-in): Windows application control feature in Enterprise/Education editions
- WDAC (Windows Defender Application Control): More advanced successor to AppLocker for modern Windows
- Microsoft LAPS: Manages local admin passwords to prevent bypassing AppLocker via admin rights
- WDAC Wizard: GUI tool for creating Windows Defender Application Control policies
- AaronLocker: Open-source AppLocker rule generator by Microsoft employee (GitHub)
Common Pitfalls
- Skipping Audit mode: Deploying AppLocker in Enforce mode without audit period will block critical applications and cause outages.
- Relying solely on path rules: Users with write access to allowed paths (C:\Windows\Temp) can bypass path-based rules. Prefer publisher rules.
- Not blocking user-writable directories: The most common gap is allowing execution from %TEMP%, Downloads, or %APPDATA%.
- Forgetting Application Identity service: AppLocker requires the AppIDSvc service running. If it stops, all rules stop enforcing.
- Admin bypass: Local administrators can bypass AppLocker by default. For full enforcement, combine with WDAC which enforces for all users including admins.
- DLL rule performance: Enabling DLL rules creates significant performance overhead. Only enable in high-security environments where the tradeoff is justified.
04 同仓库更多 Skills
verifying-build-provenance-with-slsa-sigstore
Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI/CD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.
validating-tpm-measured-boot-attestation
Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote/tpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware/kernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.
validating-backup-integrity-for-recovery
Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable/air-gapped backups for silent corruption or tampering.
triaging-windows-with-kape
Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment/triage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.
triaging-vulnerabilities-with-ssvc-framework
Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track/Track*/Attend/Act decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.
triaging-security-incident
Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM/EDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.