Registry write to an Active Setup StubPath value

Siemphony@siemphonymediumT1547.014unverified

Matches a registry_set event where the target value is StubPath beneath HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components — the single write AN0871 needs to have happened before any of its logon-time correlation can begin, since a StubPath write is what makes a component ID execute at the next interactive logon at all. AN0871 also wants the subsequent process execution (4672/4688) tied to the same logon session within a TimeWindow, and entropy- or signature-scored on the launched binary; Sigma has no cross-event join and no scoring function, so this rule keeps the registry write, which is the one event both cheap to collect and specific to this mechanism — no other persistence technique writes a StubPath value under this exact key. Requires Sysmon with a registry rule covering the Active Setup subtree, or Security auditing with Audit Registry enabled and a SACL placed on the Installed Components key, neither of which a default install carries. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0312, 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 "\\Active Setup\\Installed Components\\" and RegistryKey endswith "\\StubPath")

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\Active Setup\\Installed Components\\*" AND TargetObject="*\\StubPath")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\active setup\\\\installed components\\\\*" AND TO_LOWER(registry.path) LIKE "*\\\\stubpath")

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)\\Active Setup\\Installed Components\\</field>    <field name="TargetObject" type="pcre2">(?i)\\StubPath$</field>    <description>Registry write to an Active Setup StubPath value</description>    <mitre>      <id>T1547.014</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: 50c3ef1c-34b9-48c8-b2bf-327d5dcb6762

ATT&CKT1547.014

T1547.014Active Setup

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

AN0871 describes a multi-event chain: an Active Setup registry key created or modified with a non-standard StubPath, followed by process execution at the next user logon from an uncommon path, unsigned binary, or unusual parent-child lineage. This rule implements only the first event — the StubPath write — because it is the precondition every path through the technique needs: no StubPath write, no execution at logon, regardless of what the eventual payload looks like. The logon-time correlation, the signature check, and the entropy scoring AN0871 also wants are all out of reach for a single Sigma rule with no cross-event join and no scoring function.

02 · Telemetry you need

Sysmon EventID 13, category: registry_set / product: windows, needing a Sysmon registry rule that covers the Active Setup subtree — not a given in a minimal config. The brief's alternative, Security auditing with a SACL on Installed Components, needs Audit Registry enabled and a SACL placed manually; neither is on in a default install. Without one of the two, this rule returns nothing, and nothing here means blind, not quiet.

03 · How the logic works

Two selections, ANDed, both against TargetObject: selection_key requires contains: '\Active Setup\Installed Components\'; selection_value requires endswith: '\StubPath'. This is the same subkey-vs-value pattern this corpus uses elsewhere for registry_set — because the category concatenates key and value name into one string, contains on the parent path plus endswith on the value name together target the StubPath value specifically, under any component ID, rather than the subkey as a whole. A reviewer confirmed this construction is correct — genuinely testing the value, not just the key — and confirmed the audit-prerequisite language is stated properly rather than pointing the reader at a feed that structurally can't match.

04 · Common false positives

Here is the part worth reading twice. FP1 states plainly that installers "legitimately register an Active Setup component to run a per-user first-launch step — Adobe Reader, Java, and enterprise deployment tools (SCCM, Intune post-install scripts) all write a StubPath entry as part of a normal install, and this is the rule's single largest source of benign hits on any managed fleet." FP2 adds that VDI and terminal-server profile-provisioning tools trigger a write on every new profile on a shared image, not just every install.
That phrasing — "single largest source of benign hits on any managed fleet" — is functionally identical to the "highest-volume match by a wide margin" language AUTHORING.md itself uses as the exact trigger to downgrade a rule's level. A sibling rule in this same review batch (T1557, matching /etc/hosts//etc/resolv.conf rewrites) used nearly the same framing for its loudest false positive and shipped at level: low. This rule uses that same magnitude of claim but ships at level: medium — an inconsistency the reviewer caught directly and named as a calibration miss, not a disagreement about the false positive itself. Read this rule's level field as provisional: the false positive it ships with argues for low, and a learner should notice that mismatch rather than trust the field at face value.

05 · Detection maturity

tier_1: . Derived from a MITRE scaffold with no query logic, never run against a log line — which is exactly why the level/FP mismatch above matters: nothing here has been checked against real volume, so the provisional fields are all this rule has.
tier_2: means running it read-only long enough to settle the level question with actual counts, not just consistent phrasing.
tier_3: ** would add the logon-time correlation AN0871 wants, turning a registration event into a full persistence chain.

Tuning & false positivesexperimental · 2 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 RegistryKeyOwner — MITRE's own knob for this analytic — with the service accounts your installer tooling actually runs under (SCCM's, or whichever RMM agent your fleet uses), and exclude writes performed under those contexts before this rule sees daily use. Resolve the level question above one way or the other: either soften the false-positive language if medium is genuinely intended, or drop to low to match what the rule itself already claims about its own noise.

Declared by the author

Software installers that legitimately register an Active Setup component to run a per-user first-launch step — Adobe Reader, Java, and enterprise deployment tools (SCCM, Intune post-install scripts) all write a StubPath entry as part of a normal install, and this is the rule's single largest source of benign hits on any managed fleet.
Citrix, VDI and terminal-server profile-provisioning tools that use Active Setup by design to re-run a per-user configuration step the first time each account logs onto a shared image, producing a StubPath write on every new profile rather than every install.

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.014, evaluated against their registry_set events.

Share this rule

/u/siemphony/50c3ef1c-34b9-48c8-b2bf-327d5dcb6762

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.

Registry write to an Active Setup StubPath value

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it