---
{
  "title": "Develop Capabilities",
  "summary": "Capability development creates tools or materials for later operations.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    4
  ],
  "aliases": [
    "T1587"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1587: Develop Capabilities",
      "url": "https://attack.mitre.org/techniques/T1587"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Capability development creates tools or materials for later operations. Defenders should distinguish observed development evidence from speculation about who authored a tool.

MITRE ATT&CK catalogs this behavior as **T1587**, within resource development. The technique describes a behavior; assigning the label does not by itself prove an actor identity or successful compromise.

## An investigation example

Several related artifacts show a customized feature tied to the organization's environment.

## Evidence to examine

Review code or artifact characteristics, version relationships, infrastructure, and actual observed use.

## A common analytical pitfall

Shared code or a distinctive feature alone is insufficient to identify an actor or establish development ownership.

## Response considerations

Use confirmed behavior to improve defenses and state the evidence and limits behind any tooling or campaign relationship.

## Development is preparation, not proof of deployment

A fictional analyst receives several related malicious samples from an approved research partner. Similar configuration and implementation features suggest a development lineage. That relationship can help organize the investigation, but it does not establish that every sample was deployed against the organization or built by a particular named actor.

Capability development can involve software, exploits, or supporting cryptographic material. The important distinction is that the adversary shapes a capability rather than merely obtaining a ready-made one. Real operations may mix custom and publicly available components, so the categories should describe the evidence instead of forcing a campaign into one exclusive box.

Development artifacts have limits. Timestamps can be altered, common libraries can appear across unrelated projects, and copied code can create misleading similarity. Correlate multiple features and preserve the original sample under approved handling procedures. Beginners should not execute unknown samples on their everyday devices.

## Evaluate a synthetic lineage claim

For a paper exercise, create three fictional sample summaries. Two share a distinctive configuration structure, while all three use the same common library. Explain which overlap provides stronger evidence of a relationship and what additional information would be needed to infer a shared operator.

A defensive response usually focuses on observable behavior and affected systems rather than waiting for definitive authorship. Detection based only on one file hash may miss a rebuilt version, while a behavioral rule needs validation to avoid broad false positives. The useful lesson is to connect capability characteristics with evidence of actual use, state uncertainty clearly, and avoid equating custom development with either guaranteed sophistication or successful compromise.

## Related concepts

- [[osint]]
- [[rules-of-engagement]]
- [[threat-intelligence]]