TA0004: Privilege Escalation
The adversary is trying to gain higher-level permissions.
Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives. Common approaches are to take advantage of system weaknesses, misconfigurations, and vulnerabilities. Examples of elevated access include:
* SYSTEM/root level * local administrator * user account with admin-like access * user accounts with access to specific system or perform specific function
These techniques often overlap with Persistence techniques, as OS features that let an adversary persist can execute in an elevated context.
Analyst context for executives and security teams
Privilege Escalation is the point where an intrusion can shift from limited access to control that can change systems, access sensitive functions, or enable follow-on objectives. For leaders, the practical issue is not just whether an attacker gets in, but whether weak configurations, vulnerabilities, or excessive permissions let that initial access become administrative control.
Executive priority
Treat this tactic as a resilience and control-prioritization question: which systems or accounts could turn a low-privilege compromise into administrator, root, SYSTEM, or function-specific privileged access? Executives should ask whether vulnerability management, configuration governance, privileged access controls, and incident response playbooks can prove that escalation paths are minimized and visible.
Technical view
ATT&CK provides this object at the tactic level with no platform-specific detection guidance. SOC, detection engineering, and IR teams should validate coverage around attempts to obtain higher-level permissions on systems or networks, especially abuse of system weaknesses, misconfigurations, vulnerabilities, and OS features that may also support persistence in an elevated context. Because this tactic overlaps with Persistence, investigations should correlate new or modified elevated execution paths with account privilege changes and signs of unauthorized administrative activity.
Likely telemetry
- Authentication and authorization logs showing use of privileged or admin-like accounts
- Account, group, role, or permission change records
- Endpoint process and service execution context showing SYSTEM, root, local administrator, or other elevated execution
- Configuration and vulnerability management evidence for systems with known weaknesses or misconfigurations
- Audit logs for OS features or mechanisms that execute with elevated privileges
Detection direction
- Do not measure coverage only by alert count; validate whether telemetry can distinguish normal privileged administration from unusual elevation after low-privilege access.
- Tune detections around changes in privilege level, newly granted admin-like access, and elevated execution that follows suspicious user or process activity.
- Correlate privilege escalation indicators with Persistence-related behavior because ATT&CK notes overlap where OS features allow elevated execution.
- Account for false positives from legitimate administration, patching, and configuration management by baselining expected privileged activity.
- Identify blind spots where systems lack audit logging for permission changes, elevated process context, or vulnerability/misconfiguration state.
Mitigation priorities
- Prioritize reducing unnecessary privileged access and admin-like permissions.
- Use vulnerability and configuration management to address weaknesses and misconfigurations that could enable higher-level permissions.
- Harden and monitor OS features that can execute in elevated context, especially where they also support persistence.
- Ensure incident response procedures include rapid review of privilege changes and elevated execution after suspected initial access.
- Maintain audit-ready evidence that privileged access, configuration controls, and escalation-relevant vulnerabilities are governed and reviewed.
Analyst notes and limits
This is a broad ATT&CK tactic rather than a specific technique. The supplied object establishes the adversary objective, common escalation categories, and overlap with Persistence, but it does not identify platforms, procedures, tools, groups, or data sources. Local environment architecture and administrative workflows are required to turn this into precise detections.
Official detection content and relationship context were not supplied. Platforms are not specified. This take therefore avoids platform-specific or vendor-specific claims and should be refined with local telemetry, asset criticality, identity model, and vulnerability data.
Privilege Escalation
The adversary is trying to gain higher-level permissions.
Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives. Common approaches are to take advantage of system weaknesses, misconfigurations, and vulnerabilities. Examples of elevated access include:
* SYSTEM/root level * local administrator * user account with admin-like access * user accounts with access to specific system or perform specific function
These techniques often overlap with Persistence techniques, as OS features that let an adversary persist can execute in an elevated context.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | d6e7e86eea69… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack TA0004Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.