Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1587.002: Code Signing Certificates

Adversaries may create self-signed code signing certificates that can be used during targeting. Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted. Code signing provides a level of authenticity for a program from the developer and a guarantee that the program has not been tampered with.[1] Users and/or security tools may trust a signed piece of code more than an unsigned piece of code even if they don't know who issued the certificate or who the author is.

Prior to Code Signing, adversaries may develop self-signed code signing certificates for use in operations.

EnterpriseT1587.002Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This technique matters because it happens before the intrusion: an adversary may create self-signed code signing certificates so later executables or scripts appear more trustworthy than unsigned code. For leaders, the key issue is not the certificate creation itself, which may occur outside the enterprise, but whether security processes treat “signed” as equivalent to “trusted.”

Executive priority

Prioritize this as a control-validation and evidence problem for pre-compromise readiness. Ask whether software trust decisions, SOC triage, and incident response playbooks distinguish trusted certificate chains from self-signed or unknown signers. This supports resilience by reducing the chance that signed-but-untrusted code receives lighter scrutiny during an incident or audit review.

Technical view

T1587.002 is a PRE-platform, resource-development sub-technique under Develop Capabilities. MITRE provides no official detection text, but the relationship to DET0833 indicates a detection strategy exists for code signing certificates. SOC and IR teams should validate that file, script, sandbox, and endpoint analysis workflows record signer details and do not suppress alerts solely because code is signed. Relationship context shows this behavior is associated in ATT&CK with Operation Dream Job and the groups Patchwork, PROMETHIUM, and Daggerfly, but that should be used as historical context rather than local attribution.

Likely telemetry

  • Executable and script metadata showing whether code is signed
  • Certificate issuer, subject, serial number, validity dates, and trust-chain status
  • Endpoint or malware-analysis results that identify self-signed or untrusted code signing certificates
  • Email, web, or detonation telemetry for delivered files that includes signing information
  • Internal certificate inventory or approved-signer lists for comparison against observed signers

Detection direction

  • Validate that detections distinguish self-signed, untrusted, unknown, or rare signing certificates from certificates chaining to approved trust anchors.
  • Tune workflows so signed code is not automatically treated as benign; certificate reputation should be one signal, not a bypass.
  • Account for false positives from internal development, testing, or lab-signed software by maintaining approved internal signer context.
  • Use DET0833 as the ATT&CK-linked detection-strategy reference, but confirm local log sources actually capture signer and certificate-chain fields.
  • Because this is a resource-development behavior on PRE, expect limited direct enterprise visibility unless the signed artifact is later collected, delivered, detonated, or executed.

Mitigation priorities

  • Apply pre-compromise controls consistent with M1056 by reducing opportunities for adversary preparation to translate into successful targeting.
  • Define and enforce software trust policies that require valid, trusted certificate chains rather than accepting any signed code.
  • Maintain an approved-signer baseline for enterprise software and internal development workflows.
  • Ensure SOC and IR procedures require review of signer identity, issuer, and trust-chain status during file analysis.
  • Document certificate-validation controls as compliance and audit evidence where software integrity is in scope.
Analyst notes and limits

The practical decision point is whether the organization can prove that signed code is evaluated for trust quality, not merely for the presence of a signature. Historical ATT&CK relationships to named groups and a campaign demonstrate observed use in ATT&CK, but they do not establish current activity against any specific organization.

The official ATT&CK object has no detection text and is scoped to PRE/resource development, so many creation activities may occur outside defender telemetry. Local evidence from endpoint, sandbox, email/web inspection, and software trust policy enforcement is required to assess coverage.

Official MITRE ATT&CK definition

Code Signing Certificates

Adversaries may create self-signed code signing certificates that can be used during targeting. Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted. Code signing provides a level of authenticity for a program from the developer and a guarantee that the program has not been tampered with.[1] Users and/or security tools may trust a signed piece of code more than an unsigned piece of code even if they don't know who issued the certificate or who the author is.

Prior to Code Signing, adversaries may develop self-signed code signing certificates for use in operations.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1587 Develop Capabilities This object subtechnique of Develop Capabilities.
Associated objects

Groups, software, and campaigns

Group Enterprise

G1034: Daggerfly

Daggerfly is a People's Republic of China-linked APT entity active since at least 2012. Daggerfly has targeted individuals, government and NGO entities, and telecommunication companies in Asia and Africa. Daggerfly is associated with exclusive use of MgBot malware and is noted for several potential supply chain infection campaigns.[1][2][3][4]

Group Enterprise

G0056: PROMETHIUM

PROMETHIUM is an activity group focused on espionage that has been active since at least 2012. The group has conducted operations globally with a heavy emphasis on Turkish targets. PROMETHIUM has demonstrated similarity to another activity group called NEODYMIUM due to overlapping victim and campaign characteristics.[1][2][3]

Group Enterprise

G0040: Patchwork

Patchwork is a cyber espionage group that was first observed in December 2015. While the group has not been definitively attributed, circumstantial evidence suggests the group may be a pro-Indian or Indian entity. Patchwork has been seen targeting industries related to diplomatic and government agencies. Much of the code used by this group was copied and pasted from online forums. Patchwork was also seen operating spearphishing campaigns targeting U.S. think tank groups in March and April of 2018.[1] [2][3][4]

Campaign Enterprise

C0022: Operation Dream Job

Operation Dream Job was a cyber espionage operation likely conducted by Lazarus Group that targeted the defense, aerospace, government, and other sectors in the United States, Israel, Australia, Russia, and India. In at least one case, the cyber actors tried to monetize their network access to conduct a business email compromise (BEC) operation. In 2020, security researchers noted overlapping TTPs, to include fake job lures and code similarities, between Operation Dream Job, Operation North Star, and Operation Interception; by 2022 security researchers described Operation Dream Job as an umbrella term covering both Operation Interception and Operation North Star.[1][2][3][4]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1056: Pre-compromise Enterprise uses · Group G1034: Daggerfly Enterprise uses · Group G0056: PROMETHIUM Enterprise subtechnique of · Technique T1587: Develop Capabilities Enterprise uses · Group G0040: Patchwork Enterprise uses · Campaign C0022: Operation Dream Job Enterprise detects · Detection Strategy DET0833: Detection of Code Signing Certificates Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1056: Pre-compromise

Pre-compromise mitigations involve proactive measures and defenses implemented to prevent adversaries from successfully identifying and exploiting weaknesses during the Reconnaissance and Resource Development phases of an attack. These activities focus on reducing an organization's attack surface, identify adversarial preparation efforts, and increase the difficulty for attackers to conduct successful operations. This mitigation can be implemented through the following measures:

Limit Information Exposure:

- Regularly audit and sanitize publicly available data, including job posts, websites, and social media. - Use tools like OSINT monitoring platforms (e.g., SpiderFoot, Recon-ng) to identify leaked information.

Protect Domain and DNS Infrastructure:

- Enable DNSSEC and use WHOIS privacy protection. - Monitor for domain hijacking or lookalike domains using services like RiskIQ or DomainTools.

External Monitoring:

- Use tools like Shodan, Censys to monitor your external attack surface. - Deploy external vulnerability scanners to proactively address weaknesses.

Threat Intelligence:

- Leverage platforms like MISP, Recorded Future, or Anomali to track adversarial infrastructure, tools, and activity.

Content and Email Protections:

- Use email security solutions like Proofpoint, Microsoft Defender for Office 365, or Mimecast. - Enforce SPF/DKIM/DMARC policies to protect against email spoofing.

Training and Awareness:

- Educate employees on identifying phishing attempts, securing their social media, and avoiding information leaks.

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
87f904ba7ff9c213...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 87f904ba7ff9…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Wikipedia Code Signing

    Wikipedia. (2015, November 10). Code Signing. Retrieved March 31, 2016.

    Open source URL
  2. [2]
    mitre-attack T1587.002
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use