Registry write to a Subject Interface Package signing function entry

1title: Registry write to a Subject Interface Package signing function entry2id: 6414f678-bbfb-4cf6-a704-6441484492ac3status: experimental4description: |5  AN1222 asks for "anomalous registry modifications to Subject Interface6  Packages (SIPs) or trust provider DLL mappings" and "attempts to redirect7  WinVerifyTrust validation logic." This corpus already has a rule for the8  trust-provider half of that sentence: the parent T1553 rule watches writes9  under `...\Cryptography\Providers\Trust\FinalPolicy\{class-id}`, the key the10  SpectorOps "Subverting Trust" research this technique's own description11  cites documents as the trust-provider hijack point. This rule covers the12  other half, SIP hijacking specifically, which is a genuinely different13  registry subtree: the same research documents that a SIP's hash-generation14  and signature-verification behaviour is looked up per-file-type under15  `HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\16  CryptSIPDllGetSignedDataMsg\{SIP GUID}` and the matching17  `CryptSIPDllVerifyIndirectData\{SIP GUID}` entry, each holding a `Dll` and18  `FuncName` value pointing at the code that computes or checks a file's19  signature hash. Repointing either value to an attacker DLL that always20  reports success turns any file of that SIP's type into one WinVerifyTrust21  treats as validly signed — replacing, not just weakening, the verification22  path — which is why any write under either subtree is the selector: neither23  registers a benign reason to be touched outside a SIP install.24  The brief maps Security EventID 4657 onto this leg but the rule is written25  in the Sysmon-shaped `registry_set` vocabulary (`TargetObject` carrying the26  full key-plus-value path); a native 4657 feed splits that same path across27  `ObjectName` and `ObjectValueName` and needs both mapped onto `TargetObject`28  before it can match anything here — turning on *Audit Registry* alone does29  not make 4657 usable, since the field shape differs, not just the audit30  policy. The other two logsources in AN1222 are not used: Sysmon EventID 731  (image_load) would need a non-Microsoft-signed module loading into a process32  that calls WinVerifyTrust, a correlation this rule's single registry write33  cannot express, and CodeIntegrity EventID 3033's field shape is not34  established anywhere in this corpus, so a selector against it risks the35  invented-field trap AUTHORING.md warns against.36  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.37references:38  - https://attack.mitre.org/techniques/T1553/00339  - https://attack.mitre.org/detectionstrategies/DET044240author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)41date: 2026-08-1842tags:43  - attack.defense-evasion44  - attack.t1553.00345logsource:46  category: registry_set47  product: windows48detection:49  selection:50    TargetObject|contains:51      - '\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg\'52      - '\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\'53  condition: selection54falsepositives:55  - "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."56  - "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."57level: high