DET0833: Detection of Code Signing Certificates
DET0833 is a detection strategy for identifying activity related to adversary-created code signing certificates, mapped to ATT&CK technique T1587.002. The...
Analyst context for executives and security teams
DET0833 is a detection strategy for identifying activity related to adversary-created code signing certificates, mapped to ATT&CK technique T1587.002. The business issue is software trust: signed code can influence user and security-tool decisions, so defenders need evidence that distinguishes approved signing from suspicious or self-signed signing material before it becomes part of an incident.
Executive priority
Prioritize this as a software trust and incident-readiness control, especially where signed executables or scripts are allowed to run with less scrutiny. Leaders should ask whether the organization has an authoritative inventory of legitimate code signing certificates, whether SOC and IR teams can review certificate metadata during investigations, and whether compliance evidence can show governance over internal signing practices. Because the related ATT&CK technique is resource development on the PRE platform, coverage may depend on intelligence, certificate inventory, and file-signing visibility rather than only runtime endpoint alerts.
Technical view
ATT&CK provides no official description or detection text for DET0833, but the relationship states it detects T1587.002, Code Signing Certificates, under resource-development with platform PRE. SOC and detection teams should validate whether they can identify self-signed or unexpected code signing certificates associated with executables or scripts, compare certificate attributes against known-good enterprise signing material, and preserve certificate metadata during triage. Because this is pre-compromise/resource-development context, detections should be treated as enrichment and risk signals, not standalone proof of compromise.
Likely telemetry
- Certificate metadata from signed executables and scripts, including issuer, subject, validity dates, thumbprints, and whether the certificate is self-signed
- Enterprise inventory of approved code signing certificates and signing authorities
- Build, release, and signing workflow records for internally signed software
- Endpoint, file-analysis, or malware-analysis records that capture digital signature details
- Threat intelligence or case-management records that track suspicious certificate indicators
Detection direction
- Validate that digital-signature parsing is available wherever suspicious files are collected or analyzed.
- Tune logic to compare observed signing certificates against an approved certificate inventory rather than treating all signed code as trusted.
- Flag self-signed code signing certificates or certificates inconsistent with expected enterprise software provenance for review.
- Account for false positives from legitimate internal testing, development, or lab signing activity.
- Use the T1587.002 relationship to add context during investigations: certificate creation or use may be preparation activity and may not coincide with execution in the monitored environment.
Mitigation priorities
- Establish ownership and inventory for legitimate organizational code signing certificates.
- Define governance for when self-signed certificates are acceptable, such as development or testing, and ensure those cases are distinguishable from production software.
- Require SOC and IR playbooks to capture and review signing metadata when analyzing executables or scripts.
- Use allowlisting or trust policies carefully so that signed status alone does not bypass scrutiny.
- Review control evidence periodically to confirm certificate inventory, signing workflows, and detection enrichment remain current.
Analyst notes and limits
The most important practical question is whether defenders can separate trusted signing from suspicious signing. This object is a detection strategy, not a technique, and its only supplied relationship is to T1587.002. The related technique description supports concern around self-signed code signing certificates and the trust users or tools may place in signed code.
The supplied ATT&CK object has no official description, no official detection guidance, no tactics, and no platforms of its own. Platform and tactic context comes only from the related T1587.002 technique: PRE and resource-development. Local certificate inventories, signing practices, and file-analysis telemetry are required to determine usable 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 | T1587.002 | 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 | d14e048f2e82… |
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 DET0833Open 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.