When Attackers Buy or Steal Tools: Understanding T1588

Obtain Capabilities (T1588) is a resource development technique tagged PRE. It has seven sub-techniques: Malware, Tool, Code Signing Certificates, Digital Certificates, Exploits, Vulnerabilities and Artificial Intelligence.

It is the counterpart to Develop Capabilities. The adversary does not build. They shop, download or steal. That makes their kit more common, and more detectable, than custom work.

How attackers use it

MITRE says adversaries may buy or steal capabilities. Rather than developing their own in-house, they may purchase, freely download or steal them. This covers malware, software including licenses, exploits, certificates and information about vulnerabilities.

Sources include free downloads from the internet, and purchases from third parties. MITRE names technology companies that specialize in malware and exploits, criminal marketplaces, and individuals.

Theft is the other route. Adversaries may steal software licenses, malware, SSL/TLS and code-signing certificates, or raid closed databases of vulnerabilities or exploits. MITRE adds that stolen capabilities may come from other adversaries.

Two consequences matter for defenders.

First, shared tooling means shared fingerprints. The same malware family or commercial tool may appear in unrelated intrusions, and what you learn from one case may match another.

Second, you may be a source. Your code signing certificate, your software license or your private vulnerability data could be the thing someone steals. Treat them as assets with an attacker's price tag.

How to detect it

MITRE offers a mix of ideas.

• Use services that track newly issued certificates and certificates in use on sites across the internet. In some cases it is possible to pivot on known certificate information to find other adversary infrastructure. Some server components of adversary tools have default TLS certificate values.
• Monitor for contextual data about a malicious payload, such as compilation times, file hashes, watermarks and other identifiable configuration information.
• Because much of the activity is outside your visibility, focus detection on related stages such as defense evasion and command and control.

The default certificate point is a good example of what shared tooling gives you. If a tool ships with a default certificate value, every server running that tool with the default looks alike, and that pattern can be searched for.

Practical steps:

• Ingest indicators from threat reports for the tools and families that apply to your sector, and run them against your logs on a schedule.
• Search your TLS and proxy logs for known default certificate values.
• Keep a record of hashes and configuration details from your own incidents.
• Watch for use of dual-use tools by accounts that should not use them.

How to reduce the risk

MITRE lists Pre-compromise as the mitigation. Preventive controls cannot stop adversaries buying tools from criminal marketplaces.

The theft side is where owners have levers. These are general practices.

• Protect code signing keys. Keep them in hardware or managed key services, restrict who can use them, and log every use.
• Protect license keys and proprietary software from leaks, and revoke credentials when staff leave.
• Protect vulnerability and research data with strong access control, and watch for large downloads.
• Subscribe to threat reports and alerts, so that known tools are recognized when they show up in your environment.
• Control which tools run. Application control and allow lists work against off-the-shelf tools too.
• Keep patching. Obtained exploits still need unpatched flaws.

For teams building a program around this technique, a short intelligence loop works well. Collect reports that name tools and malware families relevant to your sector. Extract the observable details: hashes, certificate values, file names, command line patterns. Run them against your logs. Record hits and misses. Tune.

Do this on a schedule, monthly at first. The first few cycles usually surface surprising things, such as a remote administration tool that nobody remembers installing or a server that presents a default certificate from a well-known tool.

Beyond hunting, use the same cycle to review your own exposure to theft. Which signing keys, licenses and private data sets would an adversary want, and what protects each? Put the answers in a short register with an owner for each. When an adversary obtains capabilities by theft, the victim is often an organization that never thought of itself as a target. The register moves you out of that group.

A final note on the sub-techniques. Obtain Capabilities also includes Vulnerabilities, meaning information about flaws that adversaries buy or collect, and Artificial Intelligence, meaning AI tools that adversaries acquire. Both are covered on the MITRE page. They reinforce the same defensive message: know your own exposure, patch in order of risk and rely on behavior as well as signatures, because the inputs to an adversary's toolkit are widely available.

Check your own environment

• Where are your code signing keys stored, and who can use them? Is each use logged?
• Do you search your TLS logs for default certificate values used by well-known tools?
• Is there an up-to-date list of tools that administrators are allowed to run?
• Windows, PowerShell, read-only: Get-AuthenticodeSignature .\tool.exe shows who signed a tool.
• Linux or macOS, read-only: sha256sum file (Linux) or shasum -a 256 file (macOS) gives a hash you can look up in threat intelligence.

Quick check

Sources

• MITRE ATT&CK T1588: Obtain Capabilities