Security teams can detect Obtain Capabilities by looking for privilege assignment, token changes, API calls, or configuration changes that increase what a process or account can do. Focus on sudden elevation, newly enabled features, and abuse of trusted services. Attackers seek these capabilities to bypass controls, persist, or expand access.
What teams should watch for in capability-gaining activity
“obtain capabilities” is best treated as a detection problem, not a single indicator. Security teams are looking for events that expand what an account, process, service, or agent can do: privilege grants, new roles, token scope changes, feature enablement, policy edits, and trust-path changes that make previously blocked actions possible.
The useful pattern is a change in effective authority, especially when it appears suddenly or outside normal change windows. That can mean an identity receiving broader permissions, a service gaining access to new APIs, or a configuration update that turns on a powerful function that was previously disabled. The MITRE ATT&CK Enterprise Matrix is a practical reference for mapping that authority growth to known adversary behaviour, including privilege escalation and credential abuse.
Detection gets stronger when teams correlate capability changes with the system context around them. A harmless-seeming configuration change can become suspicious if it coincides with new token issuance, unusual API use, or a trusted service suddenly performing actions it never performed before. For defenders, the question is not only “did access change?” but “did the reachable set of actions expand in a way that materially increases risk?”
How to distinguish normal administration from suspicious capability gain
Start with baseline behaviour for each account, service, and workload. Normal privilege growth is usually tied to a ticket, approved rollout, or lifecycle event, while hostile capability gain often shows up as an unexpected elevation, a newly added role, a scope increase on a token, or a change that quietly bypasses a prior control.
Look closely at changes that enable persistence or bypass guardrails: API keys with broader scopes, tokens with longer lifetimes, newly trusted integrations, disabled approval steps, or settings that allow automation to act with less oversight. The key signal is not just “more access,” but “more access plus a change in trust or control boundaries.”
Teams should also separate direct privilege changes from indirect ones. Sometimes an attacker does not grant a new role at all, but alters configuration so that an existing identity can do more, such as enabling a service endpoint, widening network reach, or turning on an integration that was previously restricted. That is still capability gain if the practical effect is expanded authority.
For readers building threat-informed detection, NHIMG’s MITRE ATT&CK Guide for Defenders is useful for turning those observations into technique mapping and detection strategy.
Signals that matter most in logs, policy, and configuration history
The strongest signals are usually changes that alter what a process can successfully authenticate to, invoke, or modify. That includes token minting, credential replacement, scope expansion, role assignment, policy edits, added trust relationships, and configuration drift that changes enforcement behaviour. If the log shows a capability increase and the follow-on actions immediately use that new power, treat the sequence as highly relevant.
Configuration history is especially valuable because capability gain is often implemented by quiet control-plane changes rather than obvious user activity. A new permission may appear inside an IAM-like policy, an API gateway rule, a CI/CD secret, or a cloud service setting. The defender’s task is to catch the control change before it is converted into access, lateral movement, or data exposure.
Where environments rely on automation, compare the change against the job’s expected function. A build job, deployment bot, or integration service suddenly able to create users, export data, or call privileged endpoints deserves investigation even if the underlying identity has existed for a long time. The capability may be new even when the principal is not.
The NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control vocabulary for tracking access changes, auditability, and configuration integrity, which is exactly where this kind of detection lives.
Risk and Threat Considerations
Capability-gaining activity matters because it often marks the point where an attacker converts limited access into durable control. A small privilege change can be enough to bypass safeguards, impersonate trusted services, or reach data and functions that were previously out of scope.
Failure mechanism: Attackers abuse legitimate change paths, token issuance, role assignment, or configuration updates to expand what an account or process can do, then use the newly gained capability to persist, move laterally, or evade control checks.
Impact: The immediate effect is expanded blast radius, followed by higher odds of unauthorized action, broader data access, and harder-to-detect compromise because the activity can look like approved administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Capability gain often appears as account or permission changes that enable persistence or expanded access. |
| Recommendation — Map privilege changes to T1098 and hunt for unauthorized role or policy edits. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Account and role changes are the core evidence for unexpected capability expansion. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on reviewing logs for token, role, and configuration changes that increase authority. | |
| CM-3 — Configuration Change Control | Capability gain often comes from control-plane or policy changes that alter what a service can do. | |
| Recommendation — Review account changes promptly and remove unjustified access. Correlate audit records for privilege or token changes and escalate anomalies. Gate privileged configuration changes through formal approval and review. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The subject is about detecting when non-human identities gain excessive capability. |
| Recommendation — Audit machine and service identities for privilege growth beyond job need. | ||
Practitioner Guidance
What to verify: Confirm whether the capability increase was tied to an approved ticket, change window, or lifecycle event, and whether the resulting access matches the minimum needed for the job. If you cannot connect the change to a valid business reason, treat it as suspicious until proven otherwise.
Decision rule: If the change increases the ability to authenticate, authorize, or invoke privileged actions, prioritise investigation of the resulting blast radius before spending time on the original entry point. The practical question is how far the new capability can reach, not only how it was obtained.
Practitioner takeaway: Detecting Obtain Capabilities is about spotting authority expansion early, then proving whether it is expected, bounded, and reversible before that extra power is used.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org