New subkey created under a trusted root certificate store

1title: New subkey created under a trusted root certificate store2id: 6ff67238-a6ab-41db-aa0b-256f5075f1933status: experimental4description: |5  AN0153 asks for unauthorised modification of the Windows root certificate6  stores, and names three feeds for it: Security EventID 4657, Sysmon EventID 127  and Sysmon EventID 1. This rule is written against the Sysmon registry-creation8  feed, because installing a root certificate creates a new subkey named after9  the certificate's thumbprint under the store, and a key creation is the single10  event that says "a certificate the machine did not have before is now trusted".11  The three paths matched cover the machine-wide store12  (HKLM\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates), the13  automatic-root-update store (AuthRoot), the group-policy-pushed store under14  SOFTWARE\Policies, and the per-user store under HKU\<SID>, since every one of15  those spellings contains the same middle fragment. The certificate blob itself16  arrives afterwards as a registry value set, which is a different event class;17  matching key creation instead keeps this to the moment the trust is granted.18  Two things to be clear about before deploying it. The vocabulary here is19  Sysmon's — TargetObject holds the whole key path — so the brief's other feed,20  Security EventID 4657, cannot be pointed at this rule as an interchangeable21  source: 4657 is a value-change event and splits the path across ObjectName and22  ObjectValueName, so it needs a field mapping and a different predicate before23  it could match anything here. And Sysmon EventID 12 is only emitted for keys a24  site's Sysmon configuration includes; the widely used community configurations25  filter registry events aggressively and several do not cover26  SystemCertificates at all, so confirm the key is in scope for the running27  config before reading a silent rule as a clean estate. The svchost.exe28  exclusion drops the two machine-driven writers — the automatic root update29  service and group-policy certificate deployment, both hosted there — which30  also means a certificate installed by code injected into a service host will31  not be seen by this rule.32  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.33references:34  - https://attack.mitre.org/techniques/T1553/00435  - https://attack.mitre.org/detectionstrategies/DET005636author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)37date: 2026-08-1738tags:39  - attack.defense-evasion40  - attack.t1553.00441logsource:42  category: registry_add43  product: windows44detection:45  selection_store:46    TargetObject|contains:47      - '\\SystemCertificates\\Root\\Certificates\\'48      - '\\SystemCertificates\\AuthRoot\\Certificates\\'49      - '\\EnterpriseCertificates\\Root\\Certificates\\'50  filter_service_host:51    Image: 'C:\\Windows\\System32\\svchost.exe'52  condition: selection_store and not filter_service_host53falsepositives:54  - "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."55  - "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."56  - "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."57  - "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."58level: medium