Driver value written under a Print Monitors registry key

Siemphony@siemphonymediumT1547.010unverified

Matches a `Driver` value written under any subkey of `HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors` — the mechanism itself: a port monitor DLL registered here loads into `spoolsv.exe` under SYSTEM at the next boot or spooler restart, regardless of which process wrote the value. The subkey name is deliberately unconstrained because `AddMonitor` lets an adversary create any arbitrarily named subkey under `...\Monitors\`, so the observable is `TargetObject` ending in `\Driver` beneath that path rather than a specific monitor name. AN0580 also lists Sysmon EventID 1 (the calling process of AddMonitor), EventID 7 (spoolsv.exe loading the DLL) and EventID 11 (the DLL landing in System32); of the four, the registry write is the step every path through this technique shares, so it is the one written here rather than a chain across events Sigma cannot join. Sysmon's `registry_set` category carries the full key-plus-value path in a single `TargetObject` field — the match is on the trailing `Driver` value name, not the monitor subkey itself, which is the subkey-vs-value distinction this rule depends on getting right. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0204, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceRegistryEvents| where (RegistryKey contains "\\Control\\Print\\Monitors\\" and RegistryKey endswith "\\Driver")

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\Control\\Print\\Monitors\\*" AND TargetObject="*\\Driver")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\control\\\\print\\\\monitors\\\\*" AND TO_LOWER(registry.path) LIKE "*\\\\driver")

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,registry_set,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)\\Control\\Print\\Monitors\\</field>    <field name="TargetObject" type="pcre2">(?i)\\Driver$</field>    <description>Driver value written under a Print Monitors registry key</description>    <mitre>      <id>T1547.010</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: c02b9b98-5142-41a2-b16f-af91dc28a6c8

ATT&CKT1547.010

T1547.010Port Monitors

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

AN0580 describes a port-monitor DLL persistence chain: a registry write under HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\*\Driver, a subsequent DLL load by spoolsv.exe, and the file landing in C:\Windows\System32. This rule implements only the first step — the registry write — because it is the one link every path through the technique must cross, regardless of which process performed it or what monitor name the adversary picked.

02 · Telemetry you need

Sysmon EventID 13, tagged registry_set/windows, copied verbatim from the brief. registry_set carries the full key-plus-value path in a single TargetObject field — key and value are not separate fields, and that shapes the whole selector. None of AN0580's five knobs (TargetDLLDirectory, SignedImageValidation, UserContextScope, TimeWindow, AddMonitorCallContext) are implementable here: they describe the DLL-load and API-call legs, not the registry write. Sentinel refuses the logsource outright — no modeled registry_set table — so three of four backends render.

03 · How the logic works

One selection, two conditions on the same field: TargetObject|contains: '\Control\Print\Monitors\' and TargetObject|endswith: '\Driver'. AddMonitor lets an adversary register any arbitrarily named subkey under ...\Monitors\, so the subkey name can't be pinned down — contains on the parent path absorbs that, while endswith anchors specifically on the Driver value name rather than the subkey. That subkey-vs-value distinction is exactly what a reviewer checked this rule against, and it held: because registry_set concatenates key and value into one string, contains plus endswith together isolate "a Driver value, under some subkey, under Monitors" without a false match on, say, a subkey that happens to be named Driver. The reviewer called this the strongest of a six-rule batch on the specific check it was asked to verify.

04 · Common false positives

The registry location exists for legitimate use, and the false positives track that closely: installing or updating a printer through Devices and Printers, which writes exactly this shape of key; vendor driver packages (HP, Canon, Xerox, Epson) that install a custom port monitor DLL during setup; and bulk printer-provisioning or print-server migration scripts that recreate Monitors subkeys across a fleet in one maintenance window. None of the three claims dominant volume by itself, consistent with the level: medium the rule ships at — rare on most endpoints, not rare enough anywhere printers get installed to justify high.

05 · Detection maturity

tier_1: . Authored from a MITRE scaffold containing no query logic and never run against a log line. The subkey/value reasoning above is sound on paper, but paper is all it is — no volume estimate here should be trusted.
tier_2: means running it read-only against real registry telemetry, confirming how often `CurrentControlSet` canonicalization actually holds, and building the writing-process allowlist this rule currently lacks.
tier_3: ** would chain it to AN0580's other legs — the EventID 7 module load and EventID 11 file write — so an alert means the full persistence chain fired, not just a step routine print administration performs constantly.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Populate UserContextScope: if only SYSTEM or a specific installer service account is expected to write here, a companion Sysmon EventID 1 correlation on the writing process separates a routine install from a user-context write that shouldn't be happening. The reviewer flagged one low-severity gap: the match assumes Sysmon always canonicalizes the path to CurrentControlSet rather than a numbered ControlSetNNN — true in practice, but unstated and undefended. A ControlSet00 fallback term costs little for defense in depth. Evasion is comparatively hard since the selector keys on the mechanism itself rather than a process or filename; the real gaps are disabling or filtering Sysmon's registry auditing for this key, or writing the value through a raw registry API call from a process that isn't otherwise flagged.

Declared by the author

Installing or updating a printer through Devices and Printers or the Print Management console, which legitimately writes a Driver value under a new or existing Monitors subkey for Standard TCP/IP Port, Local Port, USB Monitor or WSD Port — the routine path this registry location exists to serve.
Vendor printer, scanner or multifunction-device driver packages (HP, Canon, Xerox, Epson and similar) that install their own custom port monitor DLL during setup, whether run interactively or pushed silently by software deployment tooling.
Print server migration or bulk printer provisioning scripts that recreate Monitors subkeys across many printers in a single maintenance window.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1547.010, evaluated against their registry_set events.

Share this rule

/u/siemphony/c02b9b98-5142-41a2-b16f-af91dc28a6c8

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Driver value written under a Print Monitors registry key

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it