T1588 Obtain Capabilities: Responding to Stolen Signing Certificates, Bought Tools and AI Access

When an adversary buys a loader, downloads a red team framework or steals a software company's code signing key, the capability arrives already trusted, already tested and often already signed. MITRE ATT&CK T1588 Obtain Capabilities covers adversaries buying, freely downloading or stealing capabilities instead of building them. In ATT&CK v20 it sits in Resource Development (TA0042) on the PRE platform with seven sub-techniques, from malware and tools to code signing certificates, exploits, vulnerability information and access to generative AI. Like the rest of the tactic, its only mitigation is M1056 Pre-compromise, so the defensive core is certificate trust and revocation, tool and signer monitoring, and fast response when your own signing material is the thing that was obtained. This guide is for detection engineers, threat intelligence analysts and PKI owners. For the full incident procedure when your signing key leaks, use the Compromised Code Signing Certificate Playbook; this page explains the technique and the controls around it.

Key takeaways

• Stolen certificates are the highest-impact case. ATT&CK lists many groups signing malware with stolen or purchased certificates, including APT41 (C0040), BlackTech, OilRig, Kimsuky and Threat Group-3390.
• Expiry does not end the risk. The NVIDIA certificates leaked in 2022 had expired, yet Windows still accepted them for driver signing, and signed malware appeared within days.
• Revocation alone is often not enough. Revoking a certificate that also signed legitimate software can break that software, so deny rules for specific signers, hashes or versions carry the immediate protection.
• Commodity tools leave reusable fingerprints. ATT&CK's detection strategy for T1588.002 points to watermarks in Cobalt Strike payloads and to default TLS certificate values in tool server components.
• AI access is now a tracked capability. T1588.007 Artificial Intelligence covers adversaries obtaining access to generative AI, with ATT&CK v20 examples including GTG-1002's use of Claude Code (C0062) and APT28's LAMEHUG.

What T1588 covers

ATT&CK describes the technique as acquiring malware, software and licences, exploits, certificates and vulnerability information, through purchase, free download or theft, including from criminal marketplaces and from other victims. The sub-techniques:

Capabilities the adversary builds are T1587 Develop Capabilities; placing obtained capabilities on infrastructure is T1608 Stage Capabilities. For the commercial market behind bought malware see the Malware-as-a-Service (MaaS) Economy Guide.

Case: leaked signing certificates in use within days

In February 2022 the Lapsus$ group leaked data from NVIDIA that included two code signing certificates. Both had expired, but Windows accepts expired certificates for driver signing, and a Secure Boot timestamp exception covered certificates created before 29 July 2015, which both predated. Malware signed with them, including Cobalt Strike beacons, Mimikatz, remote access trojans and a driver, appeared on public malware repositories within days. Revocation was not a clean fix because it would also affect legitimate drivers, and the guidance given was to use Windows Defender Application Control policies to deny the misused signatures or allow only specific driver versions. See the NVIDIA code signing certificates analysis. The lesson for every organisation that signs code is that a key, once out, stays useful to attackers long after the certificate looks dead.

Detection and monitoring

ATT&CK v20 maps T1588 to detection strategy DET0850 and sub-technique strategies including DET0845 (Malware), DET0852 (Tool), DET0875 (Code Signing Certificates), DET0848 (Digital Certificates), DET0827 (Exploits), DET0808 (Vulnerabilities) and DET0842 (Artificial Intelligence). They rely on malware repository, certificate and internet scan data, and push the rest to the stages where the capability is used.

Measuring it

• Signer allowlist coverage: percentage of endpoints and servers enforcing application control on known publishers.
• Revoked and expired signer hits: count of binaries and drivers loaded with revoked or expired signatures, trending to zero outside documented exceptions.
• Time to deny: hours from a public report of a stolen certificate to a deny rule deployed across the estate.
• Own-key exposure checks: frequency of searches for your certificate serials in malware repositories and threat feeds.
• Exploited flaw patch time: median days from exploit availability for an internet-facing product you run to patch or mitigation.

Certificate trust, revocation and hardening

M1056 Pre-compromise means you cannot stop the purchase or theft elsewhere. The following are NHI Mgmt Group recommendations for limiting what an obtained capability can do in your estate and for protecting your own signing material:

• Treat revoked and expired signers as unsigned: App Control for Business has the policy option 20 Enabled:Revoked Expired As Unsigned, which treats binaries signed with revoked certificates, or expired Lifetime Signing certificates, as unsigned.
• Keep the driver blocklist on: Microsoft's vulnerable driver blocklist covers drivers that are vulnerable, malicious or used to sign malware. It is on by default since the Windows 11 2022 update and is enforced with memory integrity (HVCI), Smart App Control or S mode; Microsoft updates it quarterly and through monthly servicing.
• Deny specific misuse quickly: when a vendor certificate is reported stolen, deploy a deny rule for the abused signer combined with file attributes, or allow only known-good versions, rather than waiting for revocation.
• Protect your own keys: the CA/Browser Forum Code Signing Baseline Requirements (version 3.11.0, June 2026) require subscriber private keys to be generated, stored and used in a suitable hardware crypto module. Use a managed signing service or HSM, restrict who and what can request signatures, and timestamp all signatures. See the Code Signing Security Guide.
• Govern dual-use tools: keep an approved list of admin and red team tools with owners and hosts; anything else is an alert.
• Revoke and reissue cleanly: know the revocation procedure with your CA in advance and which shipped software each certificate signed, so revocation impact is understood before an incident. See the Certificate Revocation Guide.

Rollout

1. Inventory every code signing certificate you own: CA, serial, expiry, key location, which pipelines use it and which products it signed.
2. Move keys that sit in files or on developer machines into an HSM or managed signing service, and record signing events.
3. Deploy App Control with option 20 and the driver blocklist in Enabled:Audit Mode on a pilot ring; review hits for two to four weeks.
4. Enforce on the pilot ring; roll back by redeploying the audit policy if a legitimate driver or tool is blocked, then add a scoped exception.
5. Subscribe to stolen-certificate reporting from your security vendors and set a target time to deny.
6. Rehearse a key compromise with the playbook, including CA contact and customer notification.

Where identity fits

A code signing certificate is a machine identity: it asserts "this code came from us" without any human present. When it is stolen, every system that trusts your signature extends that trust to the attacker. Give signing identities the same governance as other non-human identities: a named owner, a hardware-protected key, scoped signing permissions for build pipelines rather than people, short-lived signing credentials for the pipeline itself, and an audit trail of every signature. See the Code Signing Policy Template.

Responding when a capability is obtained

• A vendor certificate you trust is stolen: search telemetry for the signer, deploy deny rules for misused files, allow only known-good versions, and follow the vendor's advisory.
• Your own certificate is stolen: stop signing with it, request revocation from the CA with the correct revocation date, reissue on a new key in an HSM, re-sign and redistribute, and tell customers which files to trust. Follow the Compromised Code Signing Certificate Playbook.
• A commodity tool appears: extract watermark and C2 configuration, search for other beacons with the same values, and treat the host as compromised.
• Exploit for your edge device goes public: patch or mitigate first, then hunt for exploitation since the earliest plausible date. See the Zero-Day Exploitation Playbook.

How to test

• Revoked signer test: in a lab, sign a benign binary with a test certificate, revoke it on a test CA and confirm App Control with option 20 treats it as unsigned.
• Deny rule drill: pick a publicly reported stolen certificate and time how long it takes to search for it and push a deny rule.
• Key access review: confirm no signing key can be exported and that every signing request is logged with the requesting identity.

Common failure patterns

• Assuming expired means harmless: expired certificates can still validate driver loads, as the NVIDIA case showed.
• Signing keys in files: PFX files on build servers or laptops are exactly what intruders take.
• No list of what a key signed: revocation stalls because nobody knows what will break.
• Allowlisting by "is signed": any certificate from any public CA becomes a free pass.
• Ignoring dual-use tools: remote management and offensive frameworks run without approval or alerting.

Framework mapping

Practitioner checklist

• Inventory every code signing certificate, its key location and what it signed.
• Keep all signing keys in an HSM or managed signing service with logged requests.
• Enable App Control option 20 Enabled:Revoked Expired As Unsigned after an audit period.
• Keep the vulnerable driver blocklist and memory integrity on.
• Set a target time to deny for publicly reported stolen certificates.
• Search malware repositories for your own certificate serials regularly.
• Maintain an approved list of dual-use tools and alert on everything else.
• Rehearse a signing key compromise with the CA contact and customer notice ready.

Standards and references

• MITRE ATT&CK: Obtain Capabilities (T1588)
• MITRE ATT&CK: Obtain Capabilities: Code Signing Certificates (T1588.003)
• MITRE ATT&CK: Obtain Capabilities: Artificial Intelligence (T1588.007)
• CA/Browser Forum: Code Signing Baseline Requirements
• Microsoft Learn: Understand App Control for Business policy rules and file rules
• Microsoft Learn: Microsoft recommended driver block rules
• MITRE ATT&CK: Pre-compromise (M1056)

Related NHI Mgmt Group resources: ATT&CK Resource Development Tactic Guide · NVIDIA code signing certificates analysis · Compromised Code Signing Certificate Playbook · Malware-as-a-Service (MaaS) Economy Guide · MITRE ATT&CK T1553 Subvert Trust Controls