Custom Malware Development: Defending Against T1587.001

Develop Capabilities: Malware (T1587.001) is a resource development technique tagged PRE. The adversary writes their own malware and malware components for use against a target.

How attackers use it

MITRE lists what may be built: payloads, droppers, post-compromise tools, backdoors (including backdoored images), packers, command and control protocols and infected removable media. The goal is to keep control of remote machines, evade defenses and carry out post-compromise behavior.

MITRE adds two notable points. During development, adversaries may deliberately include indicators that match other known actors, to mislead attribution. And, as with legitimate development, the skills may be in-house or contracted, with a contractor counted as an extension of the adversary if they shape the requirements and keep exclusivity.

Some parts of development may need extra infrastructure. MITRE gives an example: malware written to talk to Twitter for command and control may require the adversary to obtain web services.

How to detect it

MITRE suggests two approaches.

For analysts, consider looking at malware for features that may be associated with the adversary or its developers, such as the compiler used, debugging artifacts or code similarities. Malware repositories can help find more samples tied to the adversary and show development patterns over time. Contextual data about a payload, such as compilation times, file hashes and watermarks or configuration information, also helps.

For everyone else, MITRE says much of the activity is outside the visibility of the target organization, so detection efforts should focus on post-compromise phases.

Because attackers may plant misleading indicators, MITRE's own point about false attribution is worth keeping in mind: treat attribution from a single artifact as a hypothesis, not a fact.

How to reduce the risk

MITRE lists Pre-compromise as the mitigation. No preventive control stops the writing of malware, so the useful work is limiting what it can do once it arrives.

• Use endpoint protection that looks at behavior as well as signatures.
• Restrict what removable media may do, since MITRE lists infected removable media among the artifacts.
• Control which scripts and executables may run, and from where.
• Limit outbound connections so that unusual command and control protocols have fewer paths.
• Verify images and packages you pull. MITRE mentions backdoored images, so confirm where an image came from and what it contains before you run it.
• Keep telemetry long enough to look back when a sample is found.

A useful exercise is to take one recent alert and ask what would remain if the sample were custom. Which behaviors would still show up in logs: a new process tree, a persistence entry, an outbound connection to a rare destination? If the answer is only the signature match, add a behavioral rule for the stage that fits best and test it with a harmless simulation your team controls.

Check your own environment

• Is your endpoint tool configured for behavior based detection, not just signature matching?
• Are removable media controls in place on sensitive systems?
• Do you pull container images only from registries you approve?
• Linux, read-only: docker history IMAGE shows the layers of an image you have pulled, and docker image ls --digests lists digests (requires the Docker CLI).
• Windows, PowerShell, read-only: Get-AuthenticodeSignature .\file.exe checks a file's signature.

Quick check

Sources

• MITRE ATT&CK T1587.001: Malware