How do attackers use Obtain Capabilities?

What attackers are actually trying to obtain

“obtain capabilities” is the stage where an attacker gathers the resources needed to make the next step work. Those resources are usually not the final objective, they are enablers, such as credentials, tokens, certificates, access rights, tools, scripts, or data that unlocks later movement, escalation, or theft. This is why the stage often looks quiet until the acquired capability is used.

In practice, the capability may be stolen, copied, downloaded, purchased, or borrowed from an already-compromised system. That includes living off the land with legitimate utilities, grabbing secrets from files or memory, or collecting access that lets the attacker return later with less friction. The tactic is about expanding what the attacker can do, not just what they can see.

For defenders, the key question is whether an acquisition event fits normal administration or whether it is a precursor to a larger chain. A download, new credential, or newly exposed secret matters most when it changes the attacker’s reach, persistence, or ability to blend in with approved activity.

How the tactic fits into an attack chain

Obtain Capabilities usually sits between initial access and higher-impact actions. Attackers may first gain a foothold, then use that foothold to collect what they need for privilege escalation, lateral movement, persistence, or exfiltration. The important point is that the attacker often does not need to be powerful at entry if they can acquire power after entry.

This makes the tactic especially relevant in environments where access is fragmented across tools, services, and privileged workflows. If one compromised account can retrieve another token, a signing certificate, or a reusable session, the attacker can turn a small compromise into a broader one. The risk is not only theft of the capability itself, but what that capability authorizes next.

The same logic applies when the attacker is not stealing a secret directly. They may obtain capabilities by persuading a system or user to grant access, by abusing weakly governed automation, or by locating forgotten resources that were never retired. In other words, acquisition can be technical, procedural, or both.

What defenders should watch for

Unusual capability acquisition is often more revealing than the final malicious action. Watch for downloads from unusual destinations, collection of credentials or tokens outside normal workflows, new access grants that do not match a change ticket, and retrieval of tools shortly before privilege escalation or data transfer. Correlation matters: the event is more suspicious when it is followed by persistence or exfiltration.

It also helps to distinguish capability acquisition from ordinary administrative activity. A legitimate operator may install tools or request access, but an attacker tends to do it under time pressure, from abnormal hosts, with inconsistent identity context, or in ways that leave little operational trace. That mismatch is often the detection opportunity.

If you can see where the capability came from, you can often infer the attacker’s next likely move. A stolen token suggests immediate use or replay, a dropped utility suggests local execution or credential harvesting, and newly acquired access rights suggest follow-on privilege abuse. The observed acquisition pattern should shape the hunt, not just the alert queue.

Risk and Threat Considerations

Acquire-and-use behavior is dangerous because it turns a single exposed resource into a broader attack path. A small compromise can become durable access if the attacker secures credentials, tokens, certificates, or tools that survive the initial breach and support repeatable access.

Failure mechanism: The attacker exploits weak visibility around resource acquisition, then uses the newly obtained capability to escalate privilege, persist, or move laterally before defenders connect the events.

Impact: The environment can suffer broader compromise than the initial entry point suggests, including continued access, unauthorized actions under valid identity, and accelerated exfiltration or service abuse.

Practitioner Guidance

What to verify: Treat acquisition events as suspect when they are not tied to an approved workflow, especially if the resource acquired can authenticate, authorize, sign, or execute. Verify source host, requesting identity, timing, and whether the same entity should normally be able to obtain that capability.

Decision rule: If the acquired item can open a new trust boundary, rotate or revoke it first, then investigate whether it was used already. If it is only a convenience tool with no standing privilege, focus more on execution telemetry and destination systems.

Practitioner takeaway: The most useful signal is not that something was acquired, but that the acquisition materially widened the attacker’s options. Prioritise events that convert a foothold into repeatable access or greater privilege.

Related resources from NHI Mgmt Group

• Guide: MITRE ATT&CK Guide for Defenders
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?