Registry write under the trust-provider FinalPolicy key

Siemphony@siemphonyhighT1553unverified

AN1246 describes "creation/modification of suspicious registry keys for trust providers"; this rule targets the one such key the technique's own cited source names precisely — the SpectorOps "Subverting Trust" research the brief references documents that WinVerifyTrust's provider dispatch is driven by the DLL and function values under `HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Trust\FinalPolicy\{class-id}`, and that repointing those values to an attacker DLL makes Windows report a tampered binary as validly signed. Any write under that subtree is the selector, since legitimate software essentially never touches it after install. The brief offers Security EventID 4657 for this leg but maps it onto the Sysmon-shaped `registry_set` category, and the rule is written in that vocabulary (`TargetObject` carrying the full key-plus-value path); a native 4657 feed splits that into `ObjectName` and `ObjectValueName` and needs both mapped onto `TargetObject` before this rule can match anything — turning on *Audit Registry* alone does not make 4657 usable here, since the field shape differs, not just the audit policy. The other two analytics in AN1246 — unusual module loads from non-standard locations, and file creation from Sysmon EventID 11 — are not used; a certificate dropped into the machine or user certificate store without ever touching this registry key, e.g. via `certutil -addstore`, is invisible to this rule. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0452, 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 "\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\"

Splunk · SPL

Run this as a search.

index=* TargetObject="*\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\*"

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE TO_LOWER(registry.path) LIKE "*\\\\software\\\\microsoft\\\\cryptography\\\\providers\\\\trust\\\\finalpolicy\\\\*"

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)\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\</field>    <description>Registry write under the trust-provider FinalPolicy key</description>    <mitre>      <id>T1553</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: b9bd781f-98cf-4b0f-9cb6-81ae66f50288

ATT&CKT1553

T1553Subvert Trust Controls

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

A write to the Windows trust-provider FinalPolicy registry subtree — the key that controls which DLL and function WinVerifyTrust calls to validate a binary's digital signature. Repointing the values under this key to an attacker-supplied DLL makes Windows report a tampered file as validly signed, which is why any write here is treated as suspicious rather than routine.

02 · Telemetry you need

Sysmon registry_set events (EventID 13), which carry a single TargetObject field combining the key path and value name. The brief offers Security EventID 4657 for this leg, but 4657 splits that same information across ObjectName and ObjectValueName — two fields, not one — so a native 4657 feed needs both mapped onto TargetObject before this rule can match anything at all. Turning on Audit Registry is not sufficient by itself: the field shape differs from Sysmon's, not just the audit policy, so a 4657 pipeline that skips the mapping step will run clean and match nothing.

03 · How the logic works

One selection, one condition: TargetObject|contains: '\SOFTWARE\Microsoft\Cryptography\Providers\Trust\FinalPolicy\'. AN1246 describes the broader category as "creation/modification of suspicious registry keys for trust providers"; this rule narrows that to the one key its own cited source names precisely. The brief's reference is the SpectorOps "Subverting Trust" research, which documents that WinVerifyTrust's provider dispatch is driven by the DLL and function values stored under HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Trust\FinalPolicy\{class-id}. Because legitimate software essentially never touches this subtree after install, any write under it — regardless of which class-id or value changes — is the entire selector, with no further narrowing needed. Two of AN1246's three analytics are not used here. Unusual module loads from non-standard locations are not implemented — that would need a separate image_load selector this rule doesn't attempt. Certificate installation into the machine or user certificate store (Sysmon EventID 11, file creation) is also unused: a certificate dropped in via certutil -addstore never touches this registry key, so that entire attack path — squarely within T1553's scope — is invisible to this rule.

04 · Common false positives

Two narrow but real sources. A subset of antivirus and endpoint-security products register their own WinVerifyTrust hook under this exact subtree at install time, to intercept signature checks for content scanning — this is the loudest expected source and the reason the rule doesn't claim critical. Second, Group Policy or endpoint-management security-baseline tooling that detects drift in trust-provider values and remediates them back to defaults writes to the same key, producing a benign match that looks identical to an attacker's write.

05 · Detection maturity

tier_1: Unverified and unrun against real data — this rule sits at the lowest DeBMM maturity tier until it has been fired against a live environment and its two known false-positive sources have been confirmed and tuned out.

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

Baseline the specific security products deployed in your environment and allowlist their installer/update process as the Image/ProcessGuid writing to this key (registry_set events on Sysmon carry a process identity). Cross-reference matches against your GPO/baseline remediation schedule — a write immediately following a scheduled compliance scan is far less interesting than one with no such correlation. Because certificate-store installation bypasses this rule entirely, do not treat "no alerts" here as "no trust-control tampering" — pair it with a certutil -addstore process-creation rule to cover that gap.

Declared by the author

A narrow set of antivirus and endpoint-security products that register their own WinVerifyTrust hook under this same subtree at install time to intercept signature checks for content scanning.
Group Policy or endpoint-management security-baseline remediation that resets trust-provider registry values to their default state after detecting drift, which writes to the same key this rule watches.

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

Share this rule

/u/siemphony/b9bd781f-98cf-4b0f-9cb6-81ae66f50288

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 under the trust-provider FinalPolicy key

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it