ADSTALE-010: Printer Objects
- Plataforma
- Active Directory
- Categoría
- AD Stale & Obsolete Objects
- Severidad
- Low
- Pilar de Zero Trust
- Governance (peso 0)
- Fixtures de referencia
- 2
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check binds to the domain and enumerates all objects of class printQueue across the directory using Get-ADObject -LDAPFilter "(objectClass=printQueue)" -Properties uNCName,serverName,printerName,driverName,location,printShareName,whenCreated,whenChanged,printKeepPrintedJobs. printQueue objects are normally created automatically when an administrator selects "List in the directory" on a shared printer on a Windows print server, and they live under CN=<printserver>,CN=<printserver-computeraccount>,DC=domain in the same NC as the host computer object. For each printQueue the check verifies four conditions. First, the referenced print server (serverName attribute) resolves in DNS and the computer account is enabled and has a recent lastLogonTimestamp (cross-referenced against ADSTALE-002). Second, the UNC path (uNCName) is syntactically valid and points to a server whose computer object still exists in the directory. Third, the whenChanged timestamp on the printQueue is within the operational threshold (default 180 days), which catches queues that were never cleaned up after a print server was decommissioned or replaced. Fourth, the host computer object for the print server (resolved via the parent DN) is itself not stale. Any printQueue that fails any of those four conditions is reported. The check is read-only and uses the default authenticated-user read rights that all printQueue objects expose by design.
Por qué importa
Published printer objects are advertised by Microsoft as a usability feature: domain users can search "Find printers in Active Directory" and locate a queue by location or model without knowing the server name. The trade-off is that every authenticated principal in the forest can also enumerate every print server, every share path, every driver name, and every physical location attribute, with no special rights and no logging on the server side because the read happens against the directory, not against the Spooler service. For an attacker on any foothold, that data is a pre-built target list: server FQDN goes straight into a port-scan or an unauthenticated PrintNightmare probe; location attributes pinpoint floors, buildings, and sometimes executive suites; printShareName plus driver name gives the attacker enough to construct a malicious Point-and-Print payload that masquerades as a legitimate replacement driver. Stale printQueue objects make this worse along three axes. First, they point at servers that are typically older builds running older Spooler binaries and missing the cumulative patches that closed CVE-2021-1675, CVE-2021-34527 (PrintNightmare), CVE-2021-36958, CVE-2022-21999 (SpoolFool), and the long tail of related Spooler CVEs. Second, they advertise hosts that are often outside the EDR and patch-management inventory because IT considers them retired, even though the directory still says they are live. Third, they create false-positive noise during incident response: an analyst chasing a suspected print-driver attack will burn hours validating queues against servers that no longer exist. The directional fix is to publish only the printers that are operationally needed, prune anything else, and treat the printQueue object set as a security inventory that must match reality.
Ruta de ataque
Step 1: Enumeration. An attacker with any authenticated foothold queries printQueue objects with a single LDAP request, for example Get-ADObject -LDAPFilter "(objectClass=printQueue)" -Properties * or the equivalent with PowerView, adfind, or ldapsearch. No elevation is required. The response yields serverName, uNCName, printerName, driverName, location, and the parent DN, which together identify every print server in the forest and a high-value subset of physical locations. Step 2: Target scoring. The attacker correlates serverName against the computer-object inventory (cross-references with stale computer accounts surfaced by ADSTALE-002) to find print servers that are unpatched, unmonitored, or decommissioned-on-paper-only. Old build numbers, missing operating-system service pack values, and lastLogonTimestamps inside the window where PrintNightmare was actively exploited (mid-2021 onward) are strong signals. Step 3: Spooler reconnaissance. Against each candidate server, the attacker probes the Print Spooler RPC interface (MS-RPRN / MS-PAR). A standard primitive is to call RpcEnumPrinterDrivers and RpcAddPrinterDriverEx; the latter is the call abused by the original PrintNightmare exploit chain to load an attacker-controlled DLL as SYSTEM on the spooler host. If the server is unpatched against CVE-2021-34527 or has Point-and-Print configured with NoWarningNoElevationOnInstall=1, the attacker has remote code execution as SYSTEM on the print server with a single authenticated RPC call. Step 4: Pivot through Point-and-Print. Even if the spooler is patched, the attacker can publish a malicious printer driver to the print server (if write rights exist) or convince a client to install a driver by abusing Point-and-Print with a UNC path the attacker controls. The driver runs in the client-side spooler process and gives the attacker code execution on every workstation that installs the printer, including workstations of users who walk past the published printer object in the AD search dialog. Step 5: Lateral movement and persistence. Print servers are frequently joined to Tier 1 (server tier) and run with service accounts that have rights across application servers. A compromised print server commonly yields cached credentials for backup operators, monitoring agents, or a print-management service account that has been delegated print-operator rights across the fleet. The stale printQueue objects that started the kill chain are still in the directory, still readable by any authenticated user, and still advertise the compromised host as a live printer to every employee.
Cómo lo evalúa Guerrilla
Guerrilla calls Get-ADObject with -LDAPFilter "(objectClass=printQueue)" and a properties list of (uNCName, serverName, printerName, driverName, location, printShareName, whenCreated, whenChanged, printKeepPrintedJobs, distinguishedName). For each returned object it (1) parses the parent DN to resolve the host computer object, (2) reads that computer object with Get-ADComputer to retrieve Enabled, lastLogonTimestamp, OperatingSystem, and OperatingSystemVersion, (3) attempts a forward DNS resolution against serverName (and uNCName-derived host) with Resolve-DnsName on the assessor host, and (4) compares whenChanged against the configured staleness threshold (default 180 days). Findings are partitioned into four buckets: orphaned (parent computer object does not exist or is disabled), unresolvable (DNS lookup fails for serverName), stale (whenChanged older than threshold), and outdated-driver (driverName matches a known-vulnerable driver inventory). The check is read-only, requires only authenticated user rights to the domain partition, and triggers no print-server-side logging because no Spooler RPC calls are issued. The 180-day default is calibrated to absorb seasonal queues (warehouse label printers, end-of-quarter check printers) without flooding the report; the threshold is operator-configurable.
Valor recomendado
Only active, managed printer objects published in AD; stale printer objects removed
Remediación
Enumerate all printQueue objects in AD using Get-ADObject -Filter {objectClass -eq 'printQueue'}. Verify that each printer object references an active, accessible print server and printer. Remove printer objects for decommissioned printers or print servers. Review whether printer publishing in AD is required for the environment. Ensure print servers are patched against PrintNightmare vulnerabilities
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 |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- CM-8
- CIS AD Benchmark
- 9.5.2
- MITRE ATT&CK
- T1557