AN2007: Analytic 2007
Consider analyzing code signing certificates for features that may be associated with the adversary and/or their developers, such as the thumbprint, algorithm used, validity period, common name, and certificate authority. Malware repositories can also be used to identify additional samples associated with the adversary and identify patterns an adversary has used in procuring 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
This analytic is about using code-signing certificate characteristics as threat intelligence, not as a normal endpoint alert. The business value is in finding patterns across signed malware samples or suspicious certificates that may indicate recurring adversary procurement or developer habits. Because much of the activity happens before the target organization is involved and outside its direct visibility, leaders should treat this as a specialized intelligence and detection-engineering capability rather than a guaranteed control.
Executive priority
Prioritize this where signed malware, software trust, or certificate abuse would create material business risk. The key decision is whether the organization has the intelligence sources, malware repository access, and certificate-analysis workflow needed to turn certificate attributes into useful defensive action. This also supports incident response scoping and audit evidence around software trust controls, but it should be paired with monitoring for follow-on behaviors such as Code Signing and Install Root Certificate.
Technical view
SOC, threat intelligence, and IR teams should validate whether they can analyze code-signing certificate fields such as thumbprint, signing algorithm, validity period, common name, and certificate authority across malware samples and internal observations. Since the ATT&CK object notes limited direct visibility, this analytic is best used to enrich detections and investigations for related follow-on behavior, especially signed binaries and root certificate installation activity. Detection engineering should avoid treating certificate attributes alone as conclusive; they are context for clustering, pivoting, and prioritizing investigation.
Likely telemetry
- Code-signing certificate metadata from files or malware samples
- Certificate thumbprints and certificate chain details
- Signing algorithm, validity period, common name, and certificate authority fields
- Malware repository or sample-analysis results
- Endpoint or file telemetry for signed executable content, where available
Detection direction
- Confirm whether certificate metadata is collected and searchable across malware analysis, endpoint/file inventory, and incident response tooling.
- Use certificate attributes to cluster related samples and identify recurring patterns, rather than as a standalone proof of maliciousness.
- Tune investigations around suspicious or unusual certificate reuse, certificate authority patterns, validity periods, or common names, with awareness of false positives from legitimate signed software.
- Prioritize correlation with follow-on behaviors referenced by ATT&CK: Code Signing and Install Root Certificate.
- Document visibility gaps, especially where certificate procurement or adversary development activity occurs outside organizational telemetry.
Mitigation priorities
- Maintain strong software trust and certificate validation practices for internally executed code.
- Ensure incident response playbooks include collection and review of signing certificate metadata for suspicious files.
- Integrate malware repository intelligence or sample-analysis outputs into threat intelligence and detection workflows where available.
- Monitor and control root certificate installation activity as a higher-confidence follow-on area.
- Use findings to inform vulnerability management, compliance evidence, and control validation around trusted software execution rather than relying on this analytic alone.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and it has no supplied relationships beyond references in the description to Code Signing and Install Root Certificate. The platform is listed as PRE, indicating pre-compromise or external visibility considerations. Practical value depends heavily on local access to certificate metadata, malware samples, and enrichment sources.
Official detection content is not provided, tactics are not specified, and no relationship context is supplied. The object explicitly states that much of the activity occurs outside target-organization visibility, so this should not be represented as a dependable direct detection without local telemetry and intelligence sources.
Analytic 2007
Consider analyzing code signing certificates for features that may be associated with the adversary and/or their developers, such as the thumbprint, algorithm used, validity period, common name, and certificate authority. Malware repositories can also be used to identify additional samples associated with the adversary and identify patterns an adversary has used in procuring 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 | 6e4ffa52f2d5… |
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 AN2007Open 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.