T1587 Develop Capabilities: Spotting Attacker Built Malware, Exploits and Certificates

Custom malware, private exploits and self-signed certificates are built before the first packet reaches you, so the only fingerprints you will ever see are the ones left on the finished product. MITRE ATT&CK T1587 Develop Capabilities covers adversaries building their own capabilities in-house rather than buying, downloading or stealing them. In ATT&CK v20 it sits in Resource Development (TA0042) on the PRE platform with four sub-techniques: T1587.001 Malware, T1587.002 Code Signing Certificates, T1587.003 Digital Certificates and T1587.004 Exploits. The only listed mitigation is M1056 Pre-compromise, so this guide treats T1587 as an intelligence and exposure problem: which artefacts of attacker development defenders can actually observe, how to pivot on them, and which controls blunt the finished capability when it arrives. It is written for threat intelligence, detection engineering and PKI teams. For the general malware analysis workflow see the Malware Analysis Guide for Defenders; this page does not repeat it.

Key takeaways

• Development is invisible, artefacts are not. ATT&CK's detection strategies for T1587 point defenders at compiler traces, debugging artefacts, code similarity, certificate fields and internet scan data, all gathered after the capability exists.
• Self-signed certificates are reusable fingerprints. Thumbprint, subject, validity period and key choices in attacker-made code signing and TLS certificates repeat across campaigns and let analysts find sibling infrastructure.
• AI has compressed exploit development. ATT&CK v20 records campaign C0062, in which GTG-1002 used Claude Code to research an SSRF flaw and generate a tailored payload, under T1587.004 Exploits.
• Trust controls do the preventive work. Application control that trusts only known publishers, and refuses self-signed and unknown signers, removes much of the value of a freshly built signed binary.
• Measure the pivot, not the alert. Useful KPIs are how fast new indicators from custom tooling reach your controls and how many sibling indicators each pivot uncovers.

What T1587 covers

ATT&CK describes development as identifying requirements and building solutions such as malware, exploits and self-signed certificates, and notes that adversaries may use contractors while still treating the result as their own capability. The four sub-techniques leave different traces:

ATT&CK also lists parent-technique examples outside those four: Kimsuky built a mailing toolkit for spearphishing, and Contagious Interview and Moonstone Sleet developed malicious npm packages for delivery to victims. Bought or stolen capabilities belong to T1588 Obtain Capabilities, and placing built capabilities on infrastructure belongs to T1608 Stage Capabilities. The AI mirror is ATLAS AML.T0017; see the AML.T0017 Develop Capabilities guide for capability development against machine learning systems.

AI-assisted development: what changed

Two campaigns in ATT&CK v20 tie T1587 to generative AI. In C0062 (September 2025), Anthropic reported that a group it assessed with high confidence as Chinese state-sponsored used Claude Code against about thirty organisations, with AI carrying out 80 to 90 percent of the campaign and humans stepping in at a handful of decision points per target. Anthropic states that Claude researched and wrote its own exploit code, and also that it sometimes hallucinated credentials and overstated findings. Anthropic banned the accounts, notified affected entities and authorities, and expanded its classifiers. See the Anthropic GTG-1002 campaign analysis. In C0064, ATT&CK records the adversary using Claude Code to create exploit scripts against Mexican government institutions.

Google Threat Intelligence Group's November 2025 AI Threat Tracker adds the malware side: families such as PROMPTFLUX and PROMPTSTEAL call large language models during execution to generate or rewrite code, actors used pretexts such as capture-the-flag exercises or student projects to get around safety guardrails, and underground forums sell AI tools for malware development and vulnerability research. GTIG described PROMPTFLUX as experimental and still in a development or testing phase. For defenders this has three consequences:

• Shorter patch windows: when exploit development from a published advisory takes hours rather than weeks, the gap between disclosure and exploitation of internet-facing systems shrinks. See the Zero-Day and Exploited Vulnerabilities Guide.
• Less code reuse to cluster on: regenerated or rewritten code weakens hash and string signatures, so behaviour, infrastructure and certificate pivots matter more.
• New network indicators: malware that calls a model API produces outbound traffic to AI provider endpoints from hosts and processes that have no business reason to make it. See the LLM-Powered Malware Guide.

Signals defenders can observe

ATT&CK v20 maps T1587 to detection strategies DET0853 (parent), DET0872 (Malware), DET0833 (Code Signing Certificates), DET0844 (Digital Certificates) and DET0894 (Exploits). Their data components are Malware Content (DC0011), Malware Metadata (DC0003) and Internet Scan data. Each strategy notes that much of the activity happens outside your visibility and directs effort to related stages. Turned into practice:

Certificate transparency logs only contain certificates issued by publicly trusted CAs, so they will not show self-signed certificates; internet-wide scan data and your own TLS telemetry fill that gap. For CA-issued certificates on lookalike domains, use the Certificate Transparency Monitoring Guide for Web Teams.

Measuring it

• Indicator latency: median time from extracting an indicator (hash, signer thumbprint, certificate) to blocking or alerting on it across EDR, proxy and application control.
• Pivot yield: sibling samples or servers found per analysed artefact.
• Signer coverage: share of executables run in the estate whose signer is on the approved publisher list.
• Patch time for exploited flaws: median time to patch or mitigate internet-facing systems after a vendor advisory.
• Unapproved AI egress: number of hosts and processes contacting model APIs outside the approved list, and trend.

Mitigations and hardening

ATT&CK's M1056 Pre-compromise states that this technique cannot easily be mitigated with preventive controls because it happens outside enterprise defences. The following are NHI Mgmt Group recommendations that reduce the value of a newly built capability once it reaches you:

• Trust publishers, not signatures: a signature only proves who signed. In Windows App Control for Business, build allow rules at the Publisher or FilePublisher level for known vendors, so a self-signed certificate claiming a vendor's name does not chain to a trusted PCA. Do not add arbitrary leaf certificates to allow lists. See the Code Signing Security Guide.
• Root store control: self-signed certificates only become trusted if someone installs them, so monitor and restrict root store changes (T1553.004 Install Root Certificate).
• TLS inspection policy: block or alert on outbound connections to servers presenting self-signed or untrusted certificates where business traffic does not need them.
• Exposure management for exploit targets: keep an accurate inventory of internet-facing systems, patch exploited edge devices first and reduce what is exposed. See the Edge Device Exploitation by Threat Actors Guide.
• AI egress control: route AI provider traffic through an approved gateway and alert on direct calls from other processes.
• Threat intelligence intake: subscribe to vendor and government reporting on custom tooling and feed signer thumbprints and certificate fields into controls automatically. See the Threat Intelligence Guide.

Rollout

1. Inventory signers: collect the publishers of every executable and driver run in the last 90 days and agree the approved publisher list.
2. Deploy an App Control policy with Enabled:Audit Mode on a pilot ring and review would-be blocks of unknown and self-signed signers for two to four weeks.
3. Enforce on the pilot ring by removing the audit option; roll back by redeploying the audit policy if a business application breaks.
4. Add Sysmon or EDR signature fields to the SIEM and build alerts for unknown signers on new binaries and drivers.
5. Add self-signed certificate alerts at the proxy, starting with servers contacted by few internal hosts.
6. Write the pivot workflow: every analysed sample produces signer, certificate and infrastructure indicators that go to controls and to the threat intelligence platform.

Where identity fits

Built capabilities increasingly target machine identities. Anthropic reported that GTG-1002's agents harvested credentials and tested them against internal systems, and GTIG describes QUIETVAULT stealing GitHub and npm tokens and using on-host AI command-line tools to look for more secrets. Custom stealers aim at the tokens, API keys and certificates that workloads use, because those rarely carry MFA. Keep secrets out of configuration files, scope service credentials to one purpose and shorten their lifetimes. See the Threat Intelligence for Identity and NHI Guide.

How to test

• Signer control test: in a lab, sign a benign test binary with a self-signed certificate whose subject imitates a real vendor and confirm App Control in audit mode logs it and the SIEM alert fires.
• Certificate alert test: stand up an internal test server with a self-signed certificate and confirm proxy logging and alerting.
• Pivot exercise: take a public report on custom malware, extract its signer and certificate indicators, and time how long it takes to search your telemetry and deploy blocks.
• AI egress check: from a test host, call a model API from an unapproved process and confirm it is logged or blocked.

Common failure patterns

• Trusting any valid signature: allow rules based on "is signed" let self-signed or spoofed publishers through.
• Discarding samples: EDR quarantines a file and nobody extracts compiler, signer or configuration data, so the next variant is unrecognised.
• Relying on hashes alone: AI-rewritten and recompiled code changes hashes on every build.
• Watching CT logs for self-signed certificates: they never appear there; scan data and local TLS logs are needed.
• Treating T1587 as unobservable: teams skip it in coverage maps and never build the pivot workflow.

Framework mapping

Practitioner checklist

• Map T1587 in your coverage model to the observable artefacts above, not to "no detection".
• Extract compiler, signer, certificate and configuration data from every analysed sample.
• Maintain an approved publisher list and enforce application control on it.
• Alert on unknown or self-signed signers for new binaries and drivers.
• Alert on outbound TLS to servers with self-signed certificates where not expected.
• Prioritise patching of exploited internet-facing systems within days of an advisory.
• Control and log AI provider traffic from endpoints and servers.
• Track indicator latency and pivot yield each quarter.

Standards and references

• MITRE ATT&CK: Develop Capabilities (T1587)
• MITRE ATT&CK: Develop Capabilities: Code Signing Certificates (T1587.002)
• MITRE ATT&CK: Anthropic AI-orchestrated Campaign (C0062)
• Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign
• Google Threat Intelligence Group: AI Threat Tracker: Advances in Threat Actor Usage of AI Tools
• Microsoft Learn: Understand App Control for Business policy rules and file rules
• Microsoft Learn: Sysmon
• MITRE ATT&CK: Pre-compromise (M1056)

Related NHI Mgmt Group resources: ATT&CK Resource Development Tactic Guide · Malware Analysis Guide for Defenders · LLM-Powered Malware Guide · AML.T0017 Develop Capabilities · Code Signing Security Guide