ADGPO-022: AppLocker/WDAC Policy Assessment
- Plataforma
- Active Directory
- Categoría
- AD Group Policy
- Severidad
- Medium
- Pilar de Zero Trust
- Governance (peso 1)
- Fixtures de referencia
- 2
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
For each Group Policy Object linked anywhere in the domain the check reads the AppLocker and WDAC policy artifacts and evaluates: - Presence of the AppLocker container in the GPO: Machine\Windows Settings\Security Settings\Application Control Policies\AppLocker. In SYSVOL this appears as the file Registry.pol plus the AppLocker XML under \Machine\Microsoft\Windows NT\Audit\AuditPolicy and the SrpV2 LDAP subtree of the GPC (cn=SrpV2,cn=Machine,cn={GPO-GUID},cn=Policies,cn=System) - Per-rule-collection EnforcementMode for each of the five AppLocker collections (Exe, Msi, Script, Dll, Appx). Valid values: NotConfigured, AuditOnly, Enabled (Enforce). The check flags any collection left at NotConfigured or AuditOnly when Enforce is expected - Service configuration for AppIDSvc (Application Identity service). AppLocker requires AppIDSvc to be running; the check verifies the service start mode is set to Automatic via System Services in the GPO so the kernel driver appid.sys loads at boot - WDAC / App Control for Business policies deployed by GPO under Computer Configuration\Administrative Templates\System\Device Guard\Deploy Windows Defender Application Control, or by the newer multi-policy refresh path. The check parses the binary .p7b policy file referenced and reports whether it is signed, whether it sets Enabled:Audit Mode (option 3) or runs in enforced mode, and whether Enabled:UMCI is set so user-mode code is evaluated - The presence of default rules (e.g. allow Program Files, allow Windows) without any explicit deny entries for known LOLBin paths (writable directories such as C:\Windows\Tasks, C:\Windows\Tracing, C:\Windows\System32\spool\drivers\color, C:\Windows\Temp) - Coverage: the check joins each policy-bearing GPO to the OUs it is linked to and warns if Domain Controllers, member servers, or workstation OUs are not covered by any enforced policy The output is one record per (GPO, rule collection or policy) pair with the enforcement mode, rule count, signing status (WDAC), and the SOMs the policy applies to.
Por qué importa
Application control is one of the few Windows security primitives that can stop arbitrary code execution before it starts, rather than detecting it after the fact. Microsoft, NSA, ASD, CISA, and the Australian Signals Directorate Essential Eight all rank application control as a top-tier mitigation: ASD lists it as Essential Eight Mitigation Strategy 1. Without it, an attacker who lands on a system through phishing (T1566), a malicious document (T1204.002), an exposed service, or stolen credentials can immediately drop and run any payload they choose. With enforced application control plus DLL rule collection enabled, common offensive tradecraft is broken: Cobalt Strike beacon DLLs fail to load, PowerShell drops to Constrained Language Mode when AppLocker script rules are enforced, .NET assemblies loaded via execute-assembly are blocked, and LOLBins like installutil, regsvr32, msbuild, mshta, and rundll32 (T1218) can be denied explicitly. Audit-only deployments are common and produce no defensive value: the rules generate 8003 events in the AppLocker log but allow every blocked binary to run anyway, which means defenders see the attempt only after the foothold is established. WDAC raises the bar further by enforcing in the kernel (rather than user-mode like AppLocker), supporting code-signing-based rules, and providing tamper resistance that local administrators cannot override. The blast radius of missing or audit-only application control is every endpoint in the domain: in incident response engagements, the absence of enforced application control is the single most common reason a commodity loader (IcedID, Qakbot, Bumblebee, SocGholish) successfully establishes a beachhead that ends in a ransomware deployment.
Ruta de ataque
1. Initial access: the attacker delivers a payload via phishing attachment, watering hole, malvertising, or exposed service. The payload is typically an HTA, LNK, ISO, IMG, OneNote, or signed installer that drops a second-stage loader. 2. Execution: with no application control (or AppLocker in AuditOnly), the loader runs unhindered as the user. Common second stages include Cobalt Strike beacon, Sliver, Brute Ratel, Mythic, and commodity malware (IcedID, Qakbot, Bumblebee). 3. LOLBin pivot: the loader uses signed Microsoft binaries (T1218) to load attacker code: rundll32.exe, regsvr32.exe (Squiblydoo), mshta.exe, installutil.exe, msbuild.exe, regasm.exe, regsvcs.exe. Without an AppLocker or WDAC deny rule and without DLL rules enabled, these execute under signed Microsoft trust. 4. Bypass attempts where partial application control exists: attackers drop payloads into user-writable directories that default rules trust (C:\Windows\Tasks, C:\Windows\Tracing, C:\Windows\System32\spool\drivers\color, the Print Spooler color directory), or abuse Microsoft-signed binaries vulnerable to DLL search-order hijack. They also load .NET assemblies in memory via execute-assembly to bypass file-based rules when the DLL collection is disabled. 5. Script execution: without AppLocker script rules in Enforce, PowerShell does not drop to Constrained Language Mode, so the attacker can run PowerShell Empire, PowerSploit, Invoke-Mimikatz, and other offensive PowerShell directly. Without WDAC, signed but unapproved assemblies execute freely. 6. Persistence and lateral movement: the attacker installs a service, scheduled task, or WMI subscription pointing at the unblocked binary, and pivots laterally with the same loader. Each new host repeats the same chain because the application control gap is identical domain-wide. 7. Tooling: AaronLocker (audit baseline generation), Ultimate AppLocker ByPass List by api0cradle, LOLBAS project for living-off-the-land binaries, BloodHound for choosing pivot targets, Cobalt Strike for command and control.
Cómo lo evalúa Guerrilla
Guerrilla enumerates every GPO in the domain via Get-GPO -All and inspects the AppLocker and WDAC artifacts in two places. First, it reads the LDAP subtree under cn=SrpV2,cn=Machine,cn={GPO-GUID},cn=Policies,cn=System,DC=... for each GPO; the SrpV2 container holds one object per rule collection (Appx, Dll, Exe, Msi, Script) with the policy XML stored in the msDS-AppliesToResourceTypes and related attributes. Second, it reads the SYSVOL path \\<domain>\SYSVOL\<domain>\Policies\{GPO-GUID}\Machine\Microsoft\Windows NT\AuditPolicy and the Registry.pol file for any AppLocker policy XML or WDAC deployment policy paths. The XML is parsed to extract each RuleCollection element, its Type attribute, and the EnforcementMode attribute (NotConfigured, AuditOnly, Enabled). For WDAC, the check reads the Administrative Templates settings under Computer Configuration\Policies\Administrative Templates\System\Device Guard, decodes the binary .p7b path, and where the policy file is reachable parses the PolicyRules and SigningScenarios to determine enforcement mode and UMCI status. The check then joins each policy-bearing GPO to the OUs it is linked to (via gPLink on every OU under the domain root) and reports any OU containing Computer objects that is not covered by an enforced policy. It also reads the Application and Services Logs\Microsoft\Windows\AppLocker channels (EXE and DLL, MSI and Script, Packaged app-Deployment, Packaged app-Execution) where available, and the CodeIntegrity\Operational log for WDAC events 3076 (audit block) and 3077 (enforce block), to confirm that the AppIDSvc service is actually running on sample endpoints.
Valor recomendado
AppLocker or WDAC policy deployed via GPO in enforce mode on all workstations and servers with a documented baseline
Remediación
Deploy AppLocker or WDAC policies via GPO starting in audit mode. Analyze audit logs to build a baseline of approved applications. Create allow-list rules based on publisher, path, or hash. Transition from audit to enforce mode after validating the baseline. Monitor for blocked execution events and update rules as needed.
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| informational | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- CM-7(5), CM-7(2), SI-7
- MITRE ATT&CK
- T1059, T1204.002