Registry write to a Subject Interface Package signing function entry

Siemphony@siemphonyhighT1553.003unverified

AN1222 asks for "anomalous registry modifications to Subject Interface Packages (SIPs) or trust provider DLL mappings" and "attempts to redirect WinVerifyTrust validation logic." This corpus already has a rule for the trust-provider half of that sentence: the parent T1553 rule watches writes under `...\Cryptography\Providers\Trust\FinalPolicy\{class-id}`, the key the SpectorOps "Subverting Trust" research this technique's own description cites documents as the trust-provider hijack point. This rule covers the other half, SIP hijacking specifically, which is a genuinely different registry subtree: the same research documents that a SIP's hash-generation and signature-verification behaviour is looked up per-file-type under `HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\ CryptSIPDllGetSignedDataMsg\{SIP GUID}` and the matching `CryptSIPDllVerifyIndirectData\{SIP GUID}` entry, each holding a `Dll` and `FuncName` value pointing at the code that computes or checks a file's signature hash. Repointing either value to an attacker DLL that always reports success turns any file of that SIP's type into one WinVerifyTrust treats as validly signed — replacing, not just weakening, the verification path — which is why any write under either subtree is the selector: neither registers a benign reason to be touched outside a SIP install. The brief maps Security EventID 4657 onto this leg but the rule is written in the Sysmon-shaped `registry_set` vocabulary (`TargetObject` carrying the full key-plus-value path); a native 4657 feed splits that same path across `ObjectName` and `ObjectValueName` and needs both mapped onto `TargetObject` before it can match anything here — turning on *Audit Registry* alone does not make 4657 usable, since the field shape differs, not just the audit policy. The other two logsources in AN1222 are not used: Sysmon EventID 7 (image_load) would need a non-Microsoft-signed module loading into a process that calls WinVerifyTrust, a correlation this rule's single registry write cannot express, and CodeIntegrity EventID 3033's field shape is not established anywhere in this corpus, so a selector against it risks the invented-field trap AUTHORING.md warns against. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0442, 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 "\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllGetSignedDataMsg\\" or RegistryKey contains "\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllVerifyIndirectData\\")

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllGetSignedDataMsg\\*" OR TargetObject="*\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllVerifyIndirectData\\*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\cryptography\\\\oid\\\\encodingtype 0\\\\cryptsipdllgetsigneddatamsg\\\\*" OR TO_LOWER(registry.path) LIKE "*\\\\cryptography\\\\oid\\\\encodingtype 0\\\\cryptsipdllverifyindirectdata\\\\*")

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="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)(\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllGetSignedDataMsg\\|\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllVerifyIndirectData\\)</field>    <description>Registry write to a Subject Interface Package signing function entry</description>    <mitre>      <id>T1553.003</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: high
Category: defense_evasion_subvert_trust
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 6414f678-bbfb-4cf6-a704-6441484492ac

ATT&CKT1553.003

T1553.003SIP and Trust Provider Hijacking

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.

Lessondefense evasion subvert trust

defense evasion subvert trustAI draft — unreviewed

01 · What this rule detects

This rule watches for registry writes that hijack a Subject Interface Package (SIP) — the per-file-type code Windows calls to compute or verify a file's signature hash. AN1222 asks for "anomalous registry modifications to Subject Interface Packages (SIPs) or trust provider DLL mappings" that "redirect WinVerifyTrust validation logic." This corpus already covers the trust-provider half in the parent T1553 rule (writes under ...\Cryptography\Providers\Trust\FinalPolicy\{class-id}); this rule covers the SIP half specifically, a genuinely different registry subtree.

02 · Telemetry you need

A Sysmon registry_set feed (EventID 13) on Windows, with TargetObject carrying the full key-plus-value path. The brief also maps this analytic onto Security EventID 4657, but that's a field-shape trap, not a drop-in substitute — see below.

03 · How the logic works

A single selection with two contains alternatives on TargetObject: - \Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg\ - \Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\ Each entry under these keys is a {SIP GUID} subkey holding a Dll and FuncName value pointing at the code that generates or checks a file type's signature hash — this is the SpectorOps "Subverting Trust" research AN1222 itself cites. Repointing either value to an attacker-controlled DLL that always reports success turns any file of that SIP's type into one WinVerifyTrust treats as validly signed. That's a replacement of the verification path, not a weakening of it, which is why the rule treats any write under either subtree as inherently worth flagging: neither key has a routine reason to be touched outside a SIP installer running. Both GetSignedDataMsg (hash generation) and VerifyIndirectData (hash verification) are matched, because an attacker only needs to control one side of the pair to make a tampered file look clean — patching either breaks the chain the same way.

04 · Common false positives

Two honest sources, both structurally identical to the attack at the registry-path level. First, software that legitimately registers its own SIP for a proprietary or catalog-style file format — some document-signing, DRM or driver-package verification products install a custom SIP under this same OID subtree during setup, and that write is indistinguishable from a hijack of an existing GUID by path alone. Second, security or code-signing vendor tooling that re-registers the built-in SIP GUIDs (EXE, CAB, CAT and similar) during a repair or reinstall, producing a write under keys the operating system already owns. level: high fits: neither false positive is high-volume or routine, both are installer-time events, so the residual signal-to-noise is good even without further tuning.

05 · Detection maturity

tier_1: Lowest tier. This rule is machine-derived from MITRE's prose and the SpectorOps research it cites, and has never been run against a real registry-write log. Treat it as a scaffold to validate, not a working detection, until it has fired on real data.

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

Build an allowlist of the SIP GUIDs your fleet's legitimate software actually registers, and exclude writes where the value already resolves to a known-good Dll/FuncName pair rather than an unrecognized path. Because installers are infrequent, even a coarse allowlist by process (which installer wrote it) will cut most of the two documented false positives.
The brief maps Security EventID 4657 onto this same analytic, and it is tempting to treat that as a second feed for the same rule — it is not. 4657 splits the registry path across ObjectName and ObjectValueName rather than the single TargetObject this rule matches, so turning on Audit Registry and pointing 4657 at this rule does nothing until both fields are explicitly mapped onto TargetObject. Two other logsources in AN1222 are deliberately unused: Sysmon image-load (EventID 7) would need a correlation this single-event rule can't express, and CodeIntegrity EventID 3033's field shape isn't established anywhere in this corpus, so guessing at it risks an invented field that never matches.

Declared by the author

Software that legitimately registers its own Subject Interface Package for a proprietary or catalog-style file format — some document-signing, DRM, or driver-package verification products install a custom SIP under this same OID subtree during setup, which is indistinguishable from a hijack of an existing GUID by path alone.
Security or code-signing vendor tooling that re-registers the built-in SIP GUIDs (for EXE, CAB, CAT and similar formats) as part of a repair or reinstall routine, producing a write under the same keys the operating system already owns.

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

Share this rule

/u/siemphony/6414f678-bbfb-4cf6-a704-6441484492ac

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 a Subject Interface Package signing function entry

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it