Develop Capabilities (T1587) is a resource development technique tagged PRE. It has four sub-techniques: Malware, Code Signing Certificates, Digital Certificates and Exploits.
The key word is develop. The adversary does not buy, download or steal. They build. That choice has consequences for defenders, because custom tooling has no public history to look up.
How attackers use it
MITRE says adversaries may build capabilities for targeting. Rather than purchasing, freely downloading or stealing them, they develop their own in-house. That means identifying requirements and building solutions such as malware, exploits and self-signed certificates. Capabilities may support many phases of the lifecycle.
The skills needed are the same ones legitimate development needs, and they may sit in-house or be contracted out. MITRE says a contractor can count as an extension of the adversary's development capability when the adversary shapes the requirements and keeps a degree of exclusivity over the result. MITRE also notes that adversaries may use artificial intelligence for development.
The four sub-techniques cover:
- Malware, including payloads, droppers, backdoors and command and control protocols.
- Code signing certificates, self-signed to lend software an air of authenticity.
- Digital certificates, self-signed TLS certificates for encrypting traffic.
- Exploits for software vulnerabilities, sometimes found through methods such as fuzzing and patch analysis.
For defenders, the practical meaning is simple. When capabilities are custom, a signature written against known tools may not match. Behavior is the better target.
How to detect it
MITRE gives two sets of ideas, and it is candid that the activity happens outside your sight.
For people who analyze samples:
- Look for features that may associate a sample with the adversary or its developers, such as the compiler used, debugging artifacts or code similarities.
- Use malware repositories to find additional samples tied to the same adversary and to follow development patterns over time.
- Look at contextual data about a payload, such as compilation times, file hashes, watermarks or other identifiable configuration information.
For everyone else:
- Because much of the activity is outside the visibility of the target organization, focus detection on related stages such as defense evasion and command and control.
That second point is the practical one for most teams. You rarely see the development. You see the result running on a host or talking on the network. So the useful questions are behavioral.
- Which processes make network connections they have never made before?
- Which executables run from user-writable directories?
- Which software is signed by an unfamiliar or self-signed certificate?
- Which hosts present TLS certificates that are self-signed or have unusual subject names?
- What changed on the host just before the first odd connection?
A habit that helps: when you do find a custom sample, save the hash, the certificate details and the timestamps. They are the material you need to find the next sample from the same builder.
How to reduce the risk
MITRE lists Pre-compromise as the mitigation. It explains that this technique cannot be easily mitigated with preventive controls, since it is based on behaviors outside the scope of enterprise defenses.
Since you cannot stop the building, work on making what is built less useful.
- Run application allow listing where you can, so that new executables do not run just because they exist.
- Keep systems and software patched. Custom exploits depend on unpatched flaws, even when the exploit itself is new.
- Collect process, network and certificate telemetry so that behavior can be found without a known signature.
- Treat unsigned or self-signed code as untrusted by default on managed endpoints.
- Share indicators from your own incidents with peers and with sharing groups you trust.
- Keep an inventory of software and dependencies, so that when a new flaw is announced you know where you are exposed.
A last point is about how to explain this technique to non-specialists. Many people picture an adversary as a single genius writing code in a dark room. MITRE's description is more ordinary: a team with requirements, a mix of skills and sometimes contractors. That is a project, and projects leave traces, such as compiler artifacts, build timestamps and reused code.
Those traces are the analyst's friend, but only when samples are kept. Make sure your incident process preserves the binary, the hashes, the certificate details and the network indicators, even when the first goal is only to clean up. A sample that you keep today may match one you meet next year.
It also helps to rehearse the case where signatures fail. Ask your detection team what they would see if the malware were brand new. If the answer is nothing, add a behavioral detection for one common stage, for example unusual child processes from office applications, and test it.
Also keep in mind that MITRE says adversaries may use artificial intelligence in development. That does not change the defensive advice, because behavior and exposure still decide what works, but it is a reminder that the cost of building custom tooling may keep falling. Basic hygiene, such as patching and allow listing, matters more as custom tooling becomes cheaper.
Check your own environment
- Does your endpoint tool let you search for executables that run from user profile or temp directories? Try a search.
- Do you log TLS certificate details for outbound connections at the proxy or network sensor?
- Is application allow listing enabled on at least your most sensitive servers?
- Can you list the software and library versions on your internet-facing systems?
- Windows, PowerShell, read-only:
Get-AuthenticodeSignature -FilePath C:\path\to\file.exeshows signature status and signer for a file. - Windows, PowerShell, read-only:
Get-ChildItem Cert:\LocalMachine\Root | Select Subject,Thumbprint,NotAfterlists trusted root certificates. Compare with your baseline.
Quick check
What separates T1587 from T1588?
In T1587 the adversary develops capabilities in-house. In T1588 they buy, download or steal them.
Can a contractor count as part of the adversary's development?
MITRE says yes, if the adversary shapes the requirements and keeps a degree of exclusivity.
Where should detection focus, given the development is hidden?
On related stages such as defense evasion and command and control.