T1547.010: Port Monitors
Adversaries may use port monitors to run an adversary supplied DLL during system boot for persistence or privilege escalation. A port monitor can be set through the AddMonitor API call to set a DLL to be loaded at startup.[1] This DLL can be located in C:\Windows\System32 and will be loaded and run by the print spooler service, `spoolsv.exe`, under SYSTEM level permissions on boot.[2]
Alternatively, an arbitrary DLL can be loaded if permissions allow writing a fully-qualified pathname for that DLL to the `Driver` value of an existing or new arbitrarily named subkey of HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors. The Registry key contains entries for the following:
* Local Port * Standard TCP/IP Port * USB Monitor * WSD Port
Analyst context for executives and security teams
Port Monitors is a Windows persistence and privilege-escalation technique where a DLL can be configured to load at boot through the print spooler service, spoolsv.exe, which runs with SYSTEM-level permissions. For leaders, the significance is that a printing-related configuration path can become a durable execution point, so coverage cannot rely only on common startup folders or run keys.
Executive priority
Prioritize this as a Windows endpoint resilience and incident response readiness issue. Security leaders should ask whether teams can prove visibility into print monitor registry changes, DLL placement or loading around spoolsv.exe, and unauthorized changes to Windows printing components. It is especially relevant for control validation, audit evidence around privileged system changes, and scoping persistence during incident response.
Technical view
This is a sub-technique of Boot or Logon Autostart Execution for Windows, tied to persistence and privilege escalation. SOC and IR teams should validate monitoring around HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors, especially new or modified monitor subkeys and Driver values, and correlate those changes with DLL load activity by spoolsv.exe. Because MITRE provides no official detection text for this object, detection engineering should use the related DET0204 strategy as supporting context and test whether local telemetry can distinguish legitimate print monitor configuration from unexpected DLL paths or recent system changes.
Likely telemetry
- Windows registry change telemetry for HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors
- Process telemetry for spoolsv.exe, especially service start and boot-time activity
- DLL/module load telemetry showing libraries loaded by spoolsv.exe
- File creation or modification telemetry for DLLs in C:\Windows\System32 and any fully qualified Driver value paths
- Administrative or installer activity that changes print monitor configuration
Detection direction
- Baseline expected print monitor entries such as Local Port, Standard TCP/IP Port, USB Monitor, and WSD Port, then alert on new, renamed, or modified monitor subkeys and Driver values.
- Correlate registry modifications with subsequent spoolsv.exe DLL loads, rather than treating either signal in isolation.
- Tune for legitimate printer driver, print management, and operating system update activity to reduce false positives.
- Validate visibility after reboot, because the behavior is specifically relevant to boot-time loading by the print spooler service.
- Check for blind spots where registry auditing, module-load logging, or endpoint telemetry is not enabled on Windows servers and workstations that use printing services.
Mitigation priorities
- Restrict who can modify print monitor configuration and related registry locations on Windows systems.
- Apply least privilege for administrative roles that manage printing components.
- Maintain an approved baseline of print monitors and investigate deviations through change management or incident response workflows.
- Use endpoint hardening and monitoring to identify unexpected DLL creation, modification, or loading in sensitive Windows paths.
- Include Port Monitors in persistence validation for managed detection, incident response playbooks, and compliance evidence around privileged configuration changes.
Analyst notes and limits
The object is Windows-only and is a sub-technique of T1547 Boot or Logon Autostart Execution. ATT&CK notes that configuration can occur through the AddMonitor API or through print monitor registry Driver values, and that spoolsv.exe can load the DLL under SYSTEM permissions at boot. The prior technique T1013 is revoked by this object, so references to T1013 should be mapped to T1547.010 in detection content and reporting.
MITRE does not provide official detection guidance for this object in the supplied fields. This take is limited to the stated Windows platform, persistence and privilege-escalation tactics, external references, and relationship context. Local validation is required to determine normal print monitor baselines, telemetry availability, and acceptable administrative change patterns.
Port Monitors
Adversaries may use port monitors to run an adversary supplied DLL during system boot for persistence or privilege escalation. A port monitor can be set through the AddMonitor API call to set a DLL to be loaded at startup.[1] This DLL can be located in C:\Windows\System32 and will be loaded and run by the print spooler service, `spoolsv.exe`, under SYSTEM level permissions on boot.[2]
Alternatively, an arbitrary DLL can be loaded if permissions allow writing a fully-qualified pathname for that DLL to the `Driver` value of an existing or new arbitrarily named subkey of HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors. The Registry key contains entries for the following:
* Local Port * Standard TCP/IP Port * USB Monitor * WSD Port
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1013 | Port Monitors | Port Monitors revoked by this object. |
| Enterprise | T1547 | Boot or Logon Autostart Execution | This object subtechnique of Boot or Logon Autostart Execution. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.3 | Current bundle | 6c371dd444ad… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
AddMonitor
Microsoft. (n.d.). AddMonitor function. Retrieved September 12, 2024.
Open source URL -
[2]
Bloxham
Bloxham, B. (n.d.). Getting Windows to Play with Itself [PowerPoint slides]. Retrieved November 12, 2014.
Open source URL -
[3]
TechNet Autoruns
Russinovich, M. (2016, January 4). Autoruns for Windows v13.51. Retrieved June 6, 2016.
Open source URL -
[4]
mitre-attack T1547.010Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.