ADGPO-022: Evaluación de políticas AppLocker/WDAC
- 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
Las políticas de control de aplicaciones como AppLocker y Windows Defender Application Control restringen qué ejecutables, scripts y DLL pueden ejecutarse en los sistemas gestionados. Sin control de aplicaciones, los atacantes pueden ejecutar herramientas y malware arbitrarios en los sistemas comprometidos para facilitar el movimiento lateral y la persistencia
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
Política de AppLocker o WDAC desplegada mediante GPO en modo de imposición en todas las estaciones de trabajo y servidores con una línea base documentada
Remediación
Despliegue políticas de AppLocker o WDAC mediante GPO comenzando en modo de auditoría. Analice los registros de auditoría para construir una línea base de aplicaciones aprobadas. Cree reglas de lista de permitidos basadas en el editor, la ruta o el hash. Pase del modo de auditoría al de imposición tras validar la línea base. Supervise los eventos de ejecución bloqueada y actualice las reglas según sea necesario.
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