T1587.003: Digital Certificates
Adversaries may create self-signed SSL/TLS certificates that can be used during targeting. SSL/TLS certificates are designed to instill trust. They include information about the key, information about its owner's identity, and the digital signature of an entity that has verified the certificate's contents are correct. If the signature is valid, and the person examining the certificate trusts the signer, then they know they can use that key to communicate with its owner. In the case of self-signing, digital certificates will lack the element of trust associated with the signature of a third-party certificate authority (CA).
Adversaries may create self-signed SSL/TLS certificates that can be used to further their operations, such as encrypting C2 traffic (ex: Asymmetric Cryptography with Web Protocols) or even enabling Adversary-in-the-Middle if added to the root of trust (i.e. Install Root Certificate).
After creating a digital certificate, an adversary may then install that certificate (see Install Digital Certificate) on infrastructure under their control.
Analyst context for executives and security teams
This is an early-stage resource-development behavior: adversaries may create self-signed TLS certificates to make infrastructure usable for encrypted communications or trust-abuse scenarios. For leaders, the value is not that a self-signed certificate automatically means compromise, but that certificate visibility can expose suspicious infrastructure before or during an intrusion path.
Executive priority
Prioritize this as a control-validation and visibility question. Ask whether the organization can see and review TLS certificate metadata for relevant network paths, whether root-of-trust changes are governed, and whether incident teams can connect suspicious certificates to later activity such as encrypted C2, adversary-in-the-middle, or certificate installation. This matters for resilience because weak certificate visibility can leave encrypted attacker infrastructure looking like normal business traffic.
Technical view
T1587.003 is a PRE-platform, Resource Development sub-technique under Develop Capabilities. MITRE provides no official detection text, but the relationship to DET0844 indicates a detection strategy exists for Digital Certificates. SOC and detection teams should validate collection and analysis of TLS/SSL certificate metadata, especially self-signed certificates observed in network traffic or infrastructure associated with investigations. IR teams should correlate certificate observations with related behaviors named in the description: Web Protocols, Asymmetric Cryptography, Adversary-in-the-Middle, Install Root Certificate, and Install Digital Certificate.
Likely telemetry
- TLS/SSL certificate metadata from network sensors, proxies, firewalls, or packet capture
- Records of self-signed certificates observed in inbound or outbound encrypted sessions
- Certificate issuer, subject, validity period, fingerprint, and trust-chain details
- DNS, domain, and infrastructure context associated with hosts presenting certificates
- Endpoint or system evidence of certificate installation or root trust store changes when investigation scope includes related techniques
Detection direction
- Do not treat all self-signed certificates as malicious; baseline legitimate internal, lab, appliance, and administrative uses first.
- Hunt for unusual or newly observed self-signed certificates, weak or inconsistent identity fields, unusual reuse across infrastructure, or certificates associated with suspicious domains or connections.
- Correlate certificate findings with encrypted command-and-control or web protocol activity rather than relying on certificate metadata alone.
- Validate visibility gaps where TLS inspection is absent, network devices are not logged, or certificate fields are not retained long enough for incident review.
- Use relationship context cautiously: ATT&CK lists multiple groups and campaigns using this technique, but local detection should be based on observed telemetry, not attribution assumptions.
Mitigation priorities
- Apply pre-compromise controls consistent with M1056: reduce exposed attack surface, monitor adversary preparation indicators, and make attacker infrastructure harder to use successfully.
- Maintain governance for trusted certificates and root stores, including change control and review of unauthorized additions.
- Inventory legitimate self-signed certificate use so detections can focus on unexpected or externally associated certificates.
- Ensure SOC and IR playbooks include certificate evidence collection and correlation during investigations involving encrypted traffic or suspected trust abuse.
Analyst notes and limits
The supplied ATT&CK object is about adversary-created self-signed digital certificates during Resource Development, not proof of compromise by itself. Its value is strongest when combined with network, DNS, infrastructure, and trust-store evidence. Relationship context includes detection strategy DET0844, mitigation M1056, parent technique T1587, and several campaign/group uses, which supports prioritizing visibility but not making attribution claims.
MITRE provides no official detection procedure for this object in the supplied fields. The platform is PRE, so many observations may occur outside traditional endpoint telemetry. Local baselines are required because self-signed certificates are common in legitimate environments.
Digital Certificates
Adversaries may create self-signed SSL/TLS certificates that can be used during targeting. SSL/TLS certificates are designed to instill trust. They include information about the key, information about its owner's identity, and the digital signature of an entity that has verified the certificate's contents are correct. If the signature is valid, and the person examining the certificate trusts the signer, then they know they can use that key to communicate with its owner. In the case of self-signing, digital certificates will lack the element of trust associated with the signature of a third-party certificate authority (CA).
Adversaries may create self-signed SSL/TLS certificates that can be used to further their operations, such as encrypting C2 traffic (ex: Asymmetric Cryptography with Web Protocols) or even enabling Adversary-in-the-Middle if added to the root of trust (i.e. Install Root Certificate).
After creating a digital certificate, an adversary may then install that certificate (see Install Digital Certificate) on infrastructure under their control.
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1587 | Develop Capabilities | This object subtechnique of Develop Capabilities. |
Groups, software, and campaigns
G0016: APT29
APT29 is threat group that has been attributed to Russia's Foreign Intelligence Service (SVR).[1][2] They have operated since at least 2008, often targeting government networks in Europe and NATO member countries, research institutes, and think tanks. APT29 reportedly compromised the Democratic National Committee starting in the summer of 2015.[3][4][5][6]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to the SVR; public statements included citations to APT29, Cozy Bear, and The Dukes.[7][8] Industry reporting also referred to the actors involved in this campaign as UNC2452, NOBELIUM, StellarParticle, Dark Halo, and SolarStorm.[9][10][11][12][13][14]
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]
G0047: Gamaredon Group
Gamaredon Group is a suspected Russian cyber espionage group that has targeted military, law enforcement, judiciary, non-profit, and non-governmental organizations in Ukraine since at least 2013. The name Gamaredon Group derives from a misspelling of the word "Armageddon," found in early campaigns.[1][2][3][4][5]
In November 2021, the Ukrainian government publicly attributed Gamaredon Group to Russia’s Federal Security Service (FSB) Center 18, an assessment later supported by multiple independent cybersecurity researchers. [6][5]
G1053: Storm-0501
Storm-0501 is a financially motivated cyber criminal group that uses commodity and open-source tools to conduct ransomware operations. Storm-0501 has been active since 2021 and has previously been affiliated with Sabbath Ransomware and other Ransomware-as-a-Service (RaaS) variants such as Hive, BlackCat, Hunters International, LockBit 3.0, and Embargo ransomware.[1][2][3][4]
C0046: ArcaneDoor
ArcaneDoor is a campaign targeting networking devices from Cisco and other vendors between July 2023 and April 2024, primarily focused on government and critical infrastructure networks. ArcaneDoor is associated with the deployment of the custom backdoors Line Runner and Line Dancer. ArcaneDoor is attributed to a group referred to as UAT4356 or STORM-1849, and is assessed to be a state-sponsored campaign.[1][2]
C0050: J-magic Campaign
The J-magic Campaign was active from mid-2023 to at least mid-2024 and featured the use of the J-magic backdoor, a custom cd00r variant tailored for use against Juniper routers. The J-magic Campaign targeted Junos OS routers serving as VPN gateways primarily in the semiconductor, energy, manufacturing, and IT sectors. [1]
C0011: C0011
C0011 was a suspected cyber espionage campaign conducted by Transparent Tribe that targeted students at universities and colleges in India. Security researchers noted this campaign against students was a significant shift from Transparent Tribe's historic targeting Indian government, military, and think tank personnel, and assessed it was still ongoing as of July 2022.[1]
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | 234d6cffbe0b… |
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]
Splunk Kovar Certificates 2017
Kovar, R. (2017, December 11). Tall Tales of Hunting with TLS/SSL Certificates. Retrieved October 16, 2020.
Open source URL -
[2]
mitre-attack T1587.003Open 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.