Obtain Capabilities: Tool (T1588.002) is a resource development technique tagged PRE. The adversary buys, steals or downloads software tools that were not built as malware.
This is the technique behind living off the shelf. The tool might be a commercial product, an open source utility or a licensed red team framework.
How attackers use it
MITRE says tools can be open or closed source, free or commercial. A tool can be used for malicious purposes but, unlike malware, was not intended for those purposes. PsExec is the example given.
Adversaries may obtain tools to support their operations, including post-compromise behavior. Tools may also serve for testing, for example evaluating malware against commercial antivirus or EDR products.
Acquisition may involve buying commercial software licenses, including for red teaming tools such as Cobalt Strike. In addition to downloading or buying, adversaries may steal software or licenses from third parties, including other adversaries. They may also crack trial versions of software.
The significance for defenders is that a tool's presence is not proof of malice, and its absence from a blocklist is not proof of safety. Context decides.
How to detect it
MITRE suggests monitoring for contextual data about a payload, such as compilation times, file hashes, watermarks and other identifiable configuration information. It also says malware repositories can help identify features of tool use tied to an adversary, such as watermarks in Cobalt Strike payloads. Because much of the activity is outside your visibility, effort should focus on post-compromise phases.
What this means in practice:
- Build a baseline of the administrative tools used in your environment, and by whom. A remote execution tool used by an admin during a change window is normal. The same tool launched from a workstation account at night is not.
- Alert on tools that are rarely used and powerful, such as remote execution utilities and credential dumping utilities.
- Watch for known watermarks and default configuration values from commercial offensive frameworks, using published indicators.
- Pay attention to cracked or unlicensed software on managed hosts.
- Log process creation with command lines, so that tool use leaves a trace you can search.
How to reduce the risk
MITRE lists Pre-compromise as the mitigation. You cannot stop adversaries from buying or cracking tools. You can limit the tools they use inside your network.
- Remove or restrict administrative tools from systems where they are not needed.
- Use application control to allow only approved tools, by publisher and by path.
- Restrict who can run remote execution and remote management utilities.
- Segment the network so that a tool on one host cannot reach every other host.
- Use separate admin accounts and workstations for administrative work, so that admin tool use stands out.
- Protect your own licensed security tools. A stolen license for a red team product turns your investment into someone else's capability.
- Keep logs of process creation and command lines on endpoints.
A good test of your readiness is a small exercise. Pick one dual-use tool that your administrators use, for example a remote execution utility. Ask three questions. Who is allowed to run it? From which hosts? What would your logs show if someone else ran it tonight?
If you cannot answer all three, you have found the gap. Close it in order: restrict the tool to the hosts that need it, limit the accounts that can run it, and make sure process creation events with command lines flow to your log store. Then run the tool once from an approved host and once from a test workstation, and check that you can tell the two apart in the logs.
The exercise generalizes. Repeat it for scripting hosts, archive tools and credential management utilities. Each time you shrink the set of places where a powerful tool can run, you make an adversary's purchased or stolen copy less useful.
Finally, remember that red team tools are used by your own testers too. Agree with them in advance on the hosts, accounts and time windows they will use, and ask them to share the artifacts they plan to drop. That way their activity is easy to separate from the real thing, and your detections get tested on realistic behavior.
Check your own environment
- List the remote administration tools installed on servers. Which ones are still needed?
- Windows, PowerShell, read-only:
Get-CimInstance Win32_Product | Select Name,Versionlists installed MSI products. It can be slow, and it does not list everything. - Windows, read-only: confirm process creation auditing is on with
auditpol /get /subcategory:"Process Creation". - Do you know which accounts are allowed to run remote execution tools, and from which hosts?
- Linux, read-only:
dpkg -l(Debian family) orrpm -qa(Red Hat family) lists installed packages.
Quick check
How is a tool different from malware in MITRE's definition?
A tool was not intended for malicious use, though an adversary can use it that way. PsExec is MITRE's example.
Name two ways adversaries obtain commercial tools.
Buying licenses, and stealing or cracking them. Free downloads are also listed.
What is a good defense against dual-use tool abuse?
Restrict where administrative tools run, baseline normal use and log process creation with command lines.
