ADGPO-008: GPOs Not Applied Due to WMI Filters
- Plataforma
- Active Directory
- Categoría
- AD Group Policy
- Severidad
- Medium
- Pilar de Zero Trust
- Governance (peso 1)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check pulls every msWMI-Som object from CN=SOM,CN=WMIPolicy,CN=System,DC=domain,DC=tld and every GPO from Get-GPO -All. For each GPO it inspects the gPCWQLFilter attribute (format "[domain;{filter-GUID};0]"), resolves the GUID to the matching msWMI-Som object, and reads the msWMI-Parm2 attribute, which holds the actual WQL query in the form "<n>;3;<namespace-length>;<namespace>;<query-length>;<query>". Each query is parsed into namespace plus WQL, and the WQL is evaluated for the following risk signals: hard-coded OS version strings or build numbers that no longer match the estate (Windows 6.1, 6.3, 10.0.17763, 10.0.19041); references to Win32_ComputerSystem.Model, Win32_BIOS.SerialNumber, or Win32_OperatingSystem.CSDVersion that may evaluate differently after hardware refresh or upgrade; ProductType clauses (1 = workstation, 2 = DC, 3 = member server) that exclude the platform the GPO was meant to cover; filters that reference custom namespaces (root\ccm, root\HP, root\Dell) that are not present on every target; and filter queries that contain syntax errors, unclosed quotes, or LIKE patterns that never match. The check also records the list of GPOs each filter is bound to (msWMI-Author, msWMI-Name, msWMI-ID), the GPO security filtering and link scope, and a computed "intended targets vs filter-passing targets" delta by re-evaluating the WQL via Get-CimInstance against a representative sample of computer objects in the linked scope.
Por qué importa
WMI filters are an additive deny on top of the security filter and the link scope. A GPO applies to a computer only when all three layers permit it: the gPLink reaches the computer through OU or site, the security filter grants Read plus Apply Group Policy to the computer or a group it is a member of, and the WMI filter WQL returns at least one row when run on that computer. If the WMI filter is broken, the GPO silently does not apply, and the resulting gap is invisible in the GPMC link view, which still shows the GPO as enabled and linked. The most common production failures are: a filter written for "Windows 7 and above" that uses Version LIKE "6.%" and therefore excludes every Windows 10 and Windows 11 host (which report 10.0.x); a filter scoped to ProductType=1 attached to a baseline that was later extended to member servers; a filter that references root\CIMV2\Security\MicrosoftTpm on systems that lack the TPM WMI provider; and a filter that depends on a custom inventory namespace populated by an agent that is no longer deployed. The security blast radius depends on what the GPO contained. If the GPO carried the LAPS client GPO settings, every filtered-out host keeps a static or shared local Administrator password (the original LAPS leak vector that drove the Microsoft acquisition and the eventual Windows LAPS shipping in 2023). If the GPO carried AppLocker or WDAC enforcement, the filtered hosts run in audit-only or no policy. If the GPO carried the advanced audit policy or LSA protection (RunAsPPL), the filtered hosts do not emit the logs the SOC depends on and Mimikatz can still read LSASS. WMI filters are also abused offensively: an attacker with GPO edit rights and msWMI-Som write rights can attach a deliberately false WQL filter (SELECT * FROM Win32_OperatingSystem WHERE Version = "0.0") to a security GPO to neutralize it without unlinking the GPO and without raising a "GPO unlinked" audit event. T1484.001 (Group Policy Modification) explicitly covers this technique.
Ruta de ataque
1. Discovery: the attacker enumerates GPOs and their WMI filter bindings with Get-GPO -All | Select DisplayName, WmiFilter, or via PowerView Get-DomainGPO -Properties displayname, gpcwqlfilter. BloodHound (with WriteGPLink and GPO edges) surfaces the same data. The attacker prefers GPOs that carry security baselines: LAPS, AppLocker, Defender exclusions, audit policy, firewall. 2. Permission check: the attacker confirms write rights on either the GPO object (to change gPCWQLFilter) or directly on the msWMI-Som object under CN=SOM,CN=WMIPolicy,CN=System (to rewrite msWMI-Parm2). Group Policy Creator Owners, delegated GPO editors, and OU admins frequently have one or both. ADACL-007 and ADGPO-018 cover the underlying permission misconfigurations. 3. Weaponization (defensive sabotage): the attacker replaces the WQL in msWMI-Parm2 with a query that always returns zero rows, for example SELECT * FROM Win32_OperatingSystem WHERE Version = "0.0.0.0", or attaches an existing broken filter to the target GPO by writing the filter GUID into gPCWQLFilter. SYSVOL replication is not involved because WMI filters live entirely in AD. 4. Weaponization (offensive payload): conversely, an attacker who controls a permissive GPO can attach a true-on-target WQL filter that narrows execution to a specific host class (a DC, a domain admin workstation, a Tier-0 server) before dropping a malicious Scheduled Task or Immediate Task. This is targeted code execution at SYSTEM with no other indicator on the link or security filter. 5. Execution: at the next Group Policy refresh (90 minutes plus 30-minute randomization, immediate on reboot), affected hosts evaluate the new WQL. Filtered-out hosts skip the GPO; targeted hosts execute the payload. The Group Policy event log records Event ID 5017 ("the WMI filter was evaluated") with result "denied (filtering)" on the filtered hosts, which most SOCs do not alert on because it is the normal pathway for WMI-filtered GPOs. 6. Persistence: the broken filter remains in place across reboots and replication cycles. Because the GPO still appears enabled, linked, and security-filtered correctly in GPMC, defenders reviewing the GPO tree see no problem. Only running gpresult /h on a representative host or re-evaluating the WQL surfaces the gap.
Cómo lo evalúa Guerrilla
Guerrilla queries CN=SOM,CN=WMIPolicy,CN=System,DC=domain,DC=tld for every objectClass=msWMI-Som and extracts msWMI-ID, msWMI-Name, msWMI-Author, msWMI-CreationDate, msWMI-ChangeDate, and msWMI-Parm2. The Parm2 string is parsed into namespace plus WQL using the documented length-prefixed format. The check then calls Get-GPO -All and reads the gPCWQLFilter attribute on every GPO, joining filter GUIDs back to the msWMI-Som rows so each GPO has its bound filter resolved. For each (GPO, filter) pair the check runs three evaluations: a syntactic check (does the WQL parse, are quotes balanced, does the namespace exist on a probe host); a content check (does the filter reference deprecated OS versions, ProductType values inconsistent with the GPO link scope, custom namespaces not present in CIMV2 on a representative host); and a live evaluation when a sample of computers from the linked OUs is available (Get-CimInstance -ComputerName $sample -Namespace $ns -Query $wql, with a short timeout). The output row contains GpoDisplayName, GpoId, FilterName, FilterId, FilterAuthor, FilterChangeDate, Namespace, Query, IsValid (bool), Findings (array of strings: "References OS Version 6.1 which is no longer in estate", "ProductType=1 excludes member servers but GPO is linked to OU=Servers", "Namespace root\HP not found on probe host"), IntendedTargets (count from link scope after security filter), PassingTargets (count after WQL evaluation), and CoverageGap (intended minus passing). The check also cross-references Event ID 5017 from forwarded Group Policy operational logs to count how often each filter has denied application in the last 7 days.
Valor recomendado
All security-critical GPOs apply to intended targets; WMI filters validated against actual environment conditions
Remediación
Review WMI filters linked to security-critical GPOs using Get-GPO and examining WMI filter assignments. Test WMI filter queries against representative target systems to verify they evaluate correctly. Use Group Policy Results (gpresult) on sample systems to confirm GPOs are applying. Replace or fix WMI filters that are blocking intended application.
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 |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- CM-6, CM-3
- MITRE ATT&CK
- T1484.001