DET0875: Detection of Code Signing Certificates
This detection strategy matters because code signing certificates can influence whether people and security tools trust software. The ATT&CK relationship t...
Analyst context for executives and security teams
This detection strategy matters because code signing certificates can influence whether people and security tools trust software. The ATT&CK relationship ties DET0875 to adversary resource development around buying or stealing code signing certificates before an intrusion. For leaders, the value is not a single alert; it is validating whether the organization can recognize suspicious certificate acquisition or use early enough to inform trust decisions, incident response scoping, and software supply-chain assurance.
Executive priority
Prioritize this as a trust and resilience control area. Executives should ask whether security, IT, and software governance teams can prove which code-signing certificates are authorized, who controls them, where they are used, and how misuse would be investigated. Because the related ATT&CK technique is pre-compromise resource development, coverage may depend on threat intelligence, certificate inventory, software allowlisting policy, procurement/vendor risk processes, and incident response playbooks rather than endpoint alerts alone.
Technical view
DET0875 has no official ATT&CK detection text, platforms, or tactics specified, so teams should treat it as a validation objective for the related technique T1588.003, Code Signing Certificates. SOC and IR teams should confirm they can distinguish expected signed code and approved certificate use from unusual certificate issuers, subjects, thumbprints, signing chains, newly observed signed binaries or scripts, and certificate use inconsistent with internal software ownership. Detection engineering should avoid assuming that a valid signature means benign activity; the relationship context specifically highlights that users and tools may trust signed code more.
Likely telemetry
- Certificate inventory and ownership records for organization-controlled code-signing certificates
- Endpoint or workload evidence showing signed executable and script execution, including signer, issuer, thumbprint, and signature validity where available
- Software deployment, application control, or allowlisting logs that record signed code trust decisions
- Threat intelligence or external monitoring for suspicious certificates, certificate reuse, or certificates associated with untrusted software
- Build, release, and signing service logs for authorized signing workflows
Detection direction
- Validate whether detections alert on suspicious certificate use, not merely unsigned code; signed malware or untrusted software may otherwise be over-trusted.
- Baseline approved signing certificates, expected publishers, and normal signing workflows before tuning alerts.
- Correlate certificate metadata with file prevalence, first-seen time, distribution path, and business owner to reduce false positives from legitimate new software releases.
- Review blind spots where certificate details are not captured in endpoint, application control, or software inventory telemetry.
- Use the relationship to T1588.003 to include pre-incident intelligence and supply-chain monitoring, since the behavior may occur before direct compromise of the organization.
Mitigation priorities
- Establish and maintain ownership, lifecycle, and access controls for legitimate code-signing certificates.
- Require controlled signing workflows and auditable release processes for internally produced software.
- Ensure SOC and IR procedures preserve certificate metadata when triaging signed executables or scripts.
- Tune trust policies so that a valid signature is one signal, not an automatic allow decision.
- Include code-signing certificate misuse scenarios in incident response and vendor/software risk reviews.
Analyst notes and limits
The official ATT&CK object is a detection strategy with no supplied description, detection text, platforms, or tactics. The practical guidance is therefore derived conservatively from the stated relationship: DET0875 detects T1588.003, Code Signing Certificates, in the enterprise domain, where adversaries may buy or steal certificates during resource development.
This take cannot assert specific data sources, platforms, detection logic, effectiveness, active exploitation, or attribution because those fields were not supplied. Local certificate inventories, endpoint telemetry, signing workflows, and trust policies are required to determine actual coverage.
Detection of Code Signing Certificates
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1588.003 | Code Signing Certificates Sub-technique | This object detects Code Signing Certificates. |
All related ATT&CK context
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 | 564ff4fa93bc… |
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 DET0875Open 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.