AN0153: Analytic 0153
Detection of unauthorized modifications to Windows root certificate stores by monitoring registry keys, certificate installation processes, and creation of new certificate entries not in baseline trusted lists.
Analyst context for executives and security teams
AN0153 focuses on detecting unauthorized changes to Windows trusted root certificate stores. This matters because trust-store changes can alter which software, websites, or communications a Windows system treats as legitimate, making certificate governance and endpoint visibility important for business resilience and audit confidence.
Executive priority
Security leaders should treat Windows root certificate store monitoring as a control-validation issue: do teams know what trusted certificates should exist, can they prove when that trust changes, and can they investigate unexpected additions quickly? The business decision value is in reducing blind trust changes that may undermine identity assurance, secure communications, compliance evidence, and incident response confidence.
Technical view
For Windows environments, validate monitoring around registry keys associated with root certificate stores, certificate installation activity, and creation of certificate entries that are not in an approved baseline. Because no ATT&CK tactics, relationships, or detailed detection logic are supplied, SOC teams should focus on whether certificate-store change events can be collected, normalized, compared against a known-good trusted list, and escalated when unauthorized or unexplained.
Likely telemetry
- Windows registry change telemetry for certificate store locations
- Certificate installation or enrollment process activity
- New certificate entry creation events
- Endpoint process telemetry associated with certificate management utilities or installers
- Approved baseline inventory of trusted root certificates
Detection direction
- Compare newly observed trusted root certificates against an approved baseline rather than alerting on all changes equally.
- Tune for legitimate administrative, enterprise PKI, browser, operating system, and software deployment activity to reduce false positives.
- Validate that registry monitoring covers the relevant Windows certificate store locations used in the environment.
- Ensure alerts retain enough context for investigation, including host, user, process, timestamp, certificate subject/issuer/fingerprint where available, and change source.
- Because no relationship context is supplied, do not assume a specific adversary technique or campaign; use this analytic as a trust-store integrity control.
Mitigation priorities
- Maintain an authorized baseline of Windows trusted root certificates and review deviations.
- Restrict who and what can modify trusted root certificate stores using standard administrative control and change-management practices.
- Integrate certificate-store changes into SOC triage and incident response workflows.
- Periodically audit endpoint certificate trust stores for drift from approved policy.
- Document monitoring and review evidence for compliance and security assurance where certificate trust is in scope.
Analyst notes and limits
The supplied object is a detection analytic for Windows root certificate store modification monitoring. Its value is strongest when paired with local certificate baselines, endpoint telemetry, and change-control records. The object provides no tactics, related techniques, or official detection logic beyond the description, so implementation should be validated against the organization’s Windows build, PKI model, and administrative tooling.
Official detection content and relationship context were not provided. This take does not infer adversary attribution, active exploitation, specific ATT&CK tactics, or guaranteed detection coverage. Local telemetry availability and certificate baseline quality will determine practical usefulness.
Analytic 0153
Detection of unauthorized modifications to Windows root certificate stores by monitoring registry keys, certificate installation processes, and creation of new certificate entries not in baseline trusted lists.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 1ee3e977d6ee… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0153Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.