AN1246: Analytic 1246
Detection correlates abnormal installation or modification of root or code-signing certificates, creation/modification of suspicious registry keys for trust providers, and unusual module loads from non-standard locations. Identifies unsigned or improperly signed executables bypassing trust prompts, combined with persistence artifacts.
Analyst context for executives and security teams
AN1246 is a Windows-focused detection analytic for suspicious trust-chain manipulation: changes to root or code-signing certificates, registry trust-provider settings, and unusual module loads that may allow unsigned or improperly signed executables to avoid trust prompts and persist. For leaders, the practical issue is whether the organization can prove that certificate trust stores and Windows trust behavior are monitored well enough to catch changes that could undermine software assurance and endpoint control decisions.
Executive priority
Prioritize this as a control-validation topic where Windows endpoints, code-signing trust, and persistence risk matter to business continuity and audit evidence. Security leaders should ask whether certificate store changes, trust-provider registry modifications, suspicious module loads, and persistence artifacts are logged, retained, and reviewed together rather than as isolated low-priority events. The value is not only detection; it is assurance that endpoint trust decisions have not become a blind spot in incident response, compliance readiness, or software integrity governance.
Technical view
SOC and detection teams should validate whether Windows telemetry can correlate three evidence classes described by the analytic: abnormal root or code-signing certificate installation or modification, suspicious registry key creation or modification for trust providers, and unusual module loads from non-standard locations. Because no ATT&CK tactic or explicit detection logic is supplied, teams should treat AN1246 as a detection-engineering pattern to test against local baselines, approved certificate-management workflows, software deployment tools, and known administrative activity. IR teams should ensure investigation playbooks connect certificate and registry trust changes with executable signing state and persistence artifacts.
Likely telemetry
- Windows certificate store change events or equivalent endpoint telemetry showing root and code-signing certificate installation or modification
- Windows registry telemetry for trust-provider-related key creation or modification
- Endpoint module-load telemetry, including image path and whether modules load from non-standard locations
- Executable signing metadata, including unsigned or improperly signed binaries where available
- Persistence artifact telemetry from endpoint detection, registry, startup locations, or related host evidence
Detection direction
- Validate correlation coverage across certificate changes, trust-provider registry changes, unusual module loads, executable signing status, and persistence artifacts; single-event alerting may miss the pattern described by the analytic.
- Baseline legitimate certificate administration, enterprise software deployment, security tooling, and developer workflows to reduce false positives.
- Tune for module loads from non-standard locations and unexpected trust-provider registry modifications, especially when combined with unsigned or improperly signed executables.
- Confirm telemetry retention is long enough to reconstruct when trust changes occurred and which process, user, or host initiated them.
- Account for the supplied limitation that no official detection logic is provided; local implementation will require environment-specific field mappings and testing.
Mitigation priorities
- Restrict and monitor administrative paths that can modify Windows root or code-signing certificate trust.
- Apply change-control and approval evidence for certificate store and trust-provider registry modifications.
- Harden endpoint configuration so unauthorized persistence artifacts and unsigned or improperly signed executables are investigated promptly.
- Ensure incident response procedures include review of certificate stores, trust-provider registry settings, module-load paths, and executable signing metadata.
- Use managed detection or internal SOC validation to confirm the correlation works in practice, not only that individual log sources exist.
Analyst notes and limits
This object is a detection analytic, not a technique description. Its main defensive value is in validating whether Windows trust manipulation indicators can be correlated with persistence and suspicious execution context. The absence of relationship context means no specific technique, actor, campaign, or tactic should be inferred from this object alone.
The supplied ATT&CK fields provide a description but no official detection logic, no tactics, and no relationships. This take is therefore limited to the Windows platform and the evidence classes explicitly named in the object. Local baselines, logging configuration, and approved administrative workflows are required to determine severity and alert quality.
Analytic 1246
Detection correlates abnormal installation or modification of root or code-signing certificates, creation/modification of suspicious registry keys for trust providers, and unusual module loads from non-standard locations. Identifies unsigned or improperly signed executables bypassing trust prompts, combined with persistence artifacts.
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 | b8d6e7e1dacf… |
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 AN1246Open 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.