New subkey created under a trusted root certificate store

Siemphony@siemphonymediumT1553.004unverified

AN0153 asks for unauthorised modification of the Windows root certificate stores, and names three feeds for it: Security EventID 4657, Sysmon EventID 12 and Sysmon EventID 1. This rule is written against the Sysmon registry-creation feed, because installing a root certificate creates a new subkey named after the certificate's thumbprint under the store, and a key creation is the single event that says "a certificate the machine did not have before is now trusted". The three paths matched cover the machine-wide store (HKLM\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates), the automatic-root-update store (AuthRoot), the group-policy-pushed store under SOFTWARE\Policies, and the per-user store under HKU\<SID>, since every one of those spellings contains the same middle fragment. The certificate blob itself arrives afterwards as a registry value set, which is a different event class; matching key creation instead keeps this to the moment the trust is granted. Two things to be clear about before deploying it. The vocabulary here is Sysmon's — TargetObject holds the whole key path — so the brief's other feed, Security EventID 4657, cannot be pointed at this rule as an interchangeable source: 4657 is a value-change event and splits the path across ObjectName and ObjectValueName, so it needs a field mapping and a different predicate before it could match anything here. And Sysmon EventID 12 is only emitted for keys a site's Sysmon configuration includes; the widely used community configurations filter registry events aggressively and several do not cover SystemCertificates at all, so confirm the key is in scope for the running config before reading a silent rule as a clean estate. The svchost.exe exclusion drops the two machine-driven writers — the automatic root update service and group-policy certificate deployment, both hosted there — which also means a certificate installed by code injected into a service host will not be seen by this rule. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0056, 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 "\\SystemCertificates\\Root\\Certificates\\" or RegistryKey contains "\\SystemCertificates\\AuthRoot\\Certificates\\" or RegistryKey contains "\\EnterpriseCertificates\\Root\\Certificates\\") and not (InitiatingProcessFolderPath =~ "C:\\Windows\\System32\\svchost.exe"))

Splunk · SPL

Run this as a search.

index=* ((TargetObject="*\\SystemCertificates\\Root\\Certificates\\*" OR TargetObject="*\\SystemCertificates\\AuthRoot\\Certificates\\*" OR TargetObject="*\\EnterpriseCertificates\\Root\\Certificates\\*") AND NOT (Image="C:\\Windows\\System32\\svchost.exe"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(registry.path) LIKE "*\\\\systemcertificates\\\\root\\\\certificates\\\\*" OR TO_LOWER(registry.path) LIKE "*\\\\systemcertificates\\\\authroot\\\\certificates\\\\*" OR TO_LOWER(registry.path) LIKE "*\\\\enterprisecertificates\\\\root\\\\certificates\\\\*") AND NOT (TO_LOWER(process.executable) == "c:\\windows\\system32\\svchost.exe"))

Wazuh · XML rule

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

<group name="sigma,windows,registry_add,">  <!-- 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)(\\SystemCertificates\\Root\\Certificates\\|\\SystemCertificates\\AuthRoot\\Certificates\\|\\EnterpriseCertificates\\Root\\Certificates\\)</field>    <field name="Image" negate="yes" type="pcre2">(?i)^C:\\Windows\\System32\\svchost\.exe$</field>    <description>New subkey created under a trusted root certificate store</description>    <mitre>      <id>T1553.004</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_add / windows
Level: medium
Category: defense_evasion_subvert_trust
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 6ff67238-a6ab-41db-aa0b-256f5075f193

ATT&CKT1553.004

T1553.004Install Root Certificate

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

Installing a root certificate makes anything signed by it trusted machine-wide. On Windows the trust stores are registry-backed, and each trusted certificate is a subkey named for its thumbprint. This rule watches for a new subkey appearing under one of those stores — the moment trust is granted, before the certificate blob itself is written. It is authored from MITRE's DET0056 / AN0153 and has never been run against a log line.

02 · Telemetry you need

Sysmon registry key-creation events, reached through the Sigma registry_add category with product: windows. That is Sysmon EventID 12, and it carries the prerequisite most likely to sink this rule quietly: Sysmon logs only the registry keys its running configuration includes, and several widely used community configs filter registry events hard and never mention SystemCertificates. Confirm the store paths are in scope before reading silence as a clean estate. The brief also offers Security EventID 4657, but that is a value-change event which splits the path across ObjectName and ObjectValueName; it needs a field mapping and a different predicate before it could feed this rule at all.

03 · How the logic works

Two blocks. selection_store matches TargetObject|contains against three path fragments: \SystemCertificates\Root\Certificates\, \SystemCertificates\AuthRoot\Certificates\ and \EnterpriseCertificates\Root\Certificates\. The first covers the machine-wide root store under HKLM, the per-user store under HKU\<SID>, and the group-policy-pushed store — that last spells out as SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates, so the same fragment catches it rather than a pattern of its own. The second is the automatic root update store. The third is the AD-published Enterprise Trust store, which is a different store from the group-policy one. filter_service_host then drops anything whose Image is C:\Windows\System32\svchost.exe, and the condition is selection_store and not filter_service_host.

04 · Common false positives

Installing a root is a routine administrative act. Endpoint management agents — Intune, SCCM, RMM, MDM enrolment — plant a corporate issuing CA on every device they onboard, from their own executables, so nothing filters them; during a fleet rollout or a CA rotation this is the loudest source the rule has, and it is why the level is medium rather than high. TLS-inspection clients reinstall their interception root after every upgrade. Developer tooling — mkcert, Fiddler, Burp, dotnet dev-certs — adds local CAs to the user store several times a week on a single engineering workstation.

05 · Detection maturity

tier_1: Lowest tier. This rule is derived prose turned into YAML — never executed, never matched anything, never had a false positive dismissed by an analyst. There is no baseline for how many certificate installs your estate produces in a day, so medium is an argument rather than a measurement. It stays at the bottom tier until it has been run against real Sysmon data and the noise floor has been counted.

Tuning & false positivesexperimental · 4 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

MITRE names three knobs on AN0153: TrustedRootHashList, MonitoredProcesses and TimeWindow. TimeWindow is unusable here, as this dialect has no timeframe construct. The svchost.exe exclusion is the pipeline's own value standing in for MonitoredProcesses, not MITRE's, and it is blunt: CryptSvc legitimately writes the AuthRoot store and gpsvc writes the Policies path, but a service-host write straight into HKLM\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\ is not normal machine-driven behaviour and is exactly where injected code would land. Narrow the filter to those two paths. Populate TrustedRootHashList from your own thumbprint baseline, and exclude your management agents by Image. One gap to carry with you: refreshing the Blob of a thumbprint already in the store is a registry value set, EventID 13, not a key creation, so it never reaches here.

Declared by the author

Certificate distribution by endpoint management agents. Intune, SCCM, RMM tooling and MDM enrolment agents install a corporate issuing CA or a device-management root into the machine store as a documented onboarding step, and they do it from their own executable rather than from a service host, so every managed device produces a match as it enrols. During a fleet rollout or a CA rotation this is the loudest source this rule has, and it is why the level is medium rather than high.
TLS-inspection, VPN and secure-web-gateway clients. Zscaler, Netskope, Cisco Umbrella, Forcepoint and similar agents must install their own interception root for HTTPS inspection to work, and they reinstall it after each client upgrade, from a signed vendor process under C:\Program Files that this rule does not exclude.
Developer and test tooling on engineering workstations. mkcert, Fiddler, Burp Suite, Charles, the .NET dev-certs tool and local Docker registries all generate a local CA and add it to the user or machine root store, often several times a week on a single developer machine, which matches both the HKU and HKLM spellings covered here.
Vendor software installers. Some backup, print-management and hardware-support packages ship their own signing root and add it during setup, so a routine application deployment window can produce a burst of matches across the hosts it targets.

Noise checknot tested

No baseline event covers this rule’s log type (registry_add / windows), so the rule was never evaluated. This is missing data, not a clean result — nothing was checked either way.

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

Security Datasets — Install root certificate
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.004, evaluated against their registry_add events.

Share this rule

/u/siemphony/6ff67238-a6ab-41db-aa0b-256f5075f193

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.

New subkey created under a trusted root certificate store

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it