AN1965: Analytic 1965
Consider analyzing self-signed code signing certificates for features that may be associated with the adversary and/or their developers, such as the thumbprint, algorithm used, validity period, and common name. Malware repositories can also be used to identify additional samples associated with the adversary and identify patterns an adversary has used in crafting self-signed code signing certificates. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related follow-on behavior, such as Code Signing or Install Root Certificate.
Analyst context for executives and security teams
AN1965 is a detection analytic focused on analyzing self-signed code-signing certificates for repeatable traits such as thumbprint, signing algorithm, validity period, and common name. Its business value is mostly pre-incident and threat intelligence oriented: it can help defenders connect malware samples and recognize certificate patterns that may later appear in signed malicious code. MITRE notes that much of this activity happens outside the target organization’s visibility, so leaders should not treat it as a dependable enterprise detection by itself.
Executive priority
Prioritize this as an intelligence-enrichment and readiness activity rather than a primary control. It matters for incident response speed, malware triage, and evidence quality when suspicious signed code is found. Executives should ask whether SOC, IR, and threat intelligence teams can analyze code-signing certificate metadata from malware repositories and internal investigations, and whether follow-on behaviors such as Code Signing and Install Root Certificate are covered by monitoring and response procedures.
Technical view
For SOC and IR teams, validate the ability to extract and compare certificate metadata from suspicious binaries and malware repository samples, especially self-signed code-signing certificates. Useful pivots include certificate thumbprint, algorithm, validity period, and common name. Because the analytic is marked for PRE and MITRE states much of the activity is outside target visibility, detection engineering should connect this enrichment to downstream enterprise behaviors, especially T1553.002 Code Signing and T1553.004 Install Root Certificate, rather than expecting direct observation of certificate creation or reuse.
Likely telemetry
- Malware repository sample metadata where available
- Certificate metadata extracted from suspicious signed files
- Code-signing certificate thumbprints, algorithms, validity periods, and common names
- Internal malware triage and incident response artifacts
- Endpoint or file-analysis evidence related to suspicious signed code
Detection direction
- Treat this analytic as threat intelligence enrichment and correlation, not a standalone alert source.
- Validate whether analysts can consistently extract and search self-signed code-signing certificate fields across malware samples and internal case data.
- Tune for repeatable certificate patterns across samples, while accounting for benign self-signed certificates used in legitimate development or testing contexts.
- Use certificate-pattern findings to prioritize investigation of related follow-on behavior such as Code Signing and Install Root Certificate.
- Document the visibility gap: certificate creation and adversary development activity may occur outside organizational telemetry.
Mitigation priorities
- Ensure suspicious signed binaries can be triaged for certificate metadata during incident response.
- Maintain processes for comparing certificate traits across internal findings and malware repository data where available.
- Strengthen monitoring and response procedures for suspicious code signing and root certificate installation activity.
- Use findings to improve threat intelligence, detection hypotheses, and IR playbooks rather than relying on this analytic as a preventive control.
- Preserve certificate metadata as investigation and compliance evidence when signed malware or suspicious trusted-code activity is investigated.
Analyst notes and limits
The supplied ATT&CK object provides an analytic description but no official detection logic, no tactics, and no relationship context beyond references in the description to Code Signing and Install Root Certificate. The strongest defensible use is enrichment, clustering, and investigative pivoting around self-signed code-signing certificate features.
Coverage depends on access to malware samples, file-analysis capability, and certificate metadata collection. MITRE explicitly notes that much of the relevant activity occurs outside the target organization’s visibility, so local telemetry may only show follow-on behavior, not the certificate-generation or adversary-development activity itself.
Analytic 1965
Consider analyzing self-signed code signing certificates for features that may be associated with the adversary and/or their developers, such as the thumbprint, algorithm used, validity period, and common name. Malware repositories can also be used to identify additional samples associated with the adversary and identify patterns an adversary has used in crafting self-signed code signing certificates. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related follow-on behavior, such as Code Signing or Install Root Certificate.
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 | 98774f80d23a… |
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 AN1965Open 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.