Exploitation for Privilege Escalation (MITRE ATT&CK T1068) turns a foothold as an ordinary user, service account or container process into SYSTEM, root, cluster admin or application admin by abusing a software flaw rather than a misconfiguration. It is one of the most used techniques in ATT&CK v20 and it is the step that unlocks everything an attacker wants next: credential stores, machine identities, cloud role credentials and the ability to switch off defences. This page is written for detection engineers, vulnerability managers and platform teams. It goes beyond the MITRE entry with concrete log sources, detection logic, the cloud and non-human identity angle, and incidents where the technique decided the outcome. It is defensive only: there are no exploit details.
Key takeaways
- The flaw is the entry, the identity is the prize. Once a process runs as SYSTEM or root it can read service account secrets, instance role credentials and Kubernetes tokens, so treat every confirmed escalation as a credential incident.
- Local privilege escalation bugs are exploited constantly. In the CISA Known Exploited Vulnerabilities (KEV) catalogue version 2026.10.21, roughly 389 of 1,754 entries describe privilege escalation, and about 90 of those are marked as used in ransomware campaigns.
- Detection works on the side effects, not the exploit. Look for a low-privilege parent spawning a SYSTEM or root child, unexpected driver loads, sensitive privileges assigned to unusual accounts and containers touching host namespaces.
- Kernel driver abuse is the Windows favourite. Bring Your Own Vulnerable Driver (BYOVD) is part of T1068, and the Microsoft vulnerable driver blocklist plus memory integrity (HVCI) removes much of that path.
- Patch speed beats everything else. Prioritise KEV-listed local escalation flaws on servers, build agents and multi-tenant hosts, because those are where a low-privilege foothold is most likely to exist.
How the attack works
MITRE describes T1068 as exploiting a programming error in a program, service, the operating system or the kernel to run attacker-controlled code with higher permissions. The attacker already has code execution somewhere (a phished workstation, a web shell, a compromised CI job, a container) but that context is limited. The exploit breaks the boundary between the low and high privilege contexts. Typical boundaries crossed are:
- User to SYSTEM or root: kernel or driver flaws such as the Windows Common Log File System (CLFS) driver bugs CVE-2023-28252 and CVE-2025-29824, or the Linux nf_tables flaw CVE-2024-1086. All three are KEV-listed with known ransomware use.
- User to kernel through a signed driver: BYOVD, where the attacker brings a legitimately signed but vulnerable driver. Scattered Spider deployed a malicious kernel driver by exploiting CVE-2015-2291 in the Intel Ethernet diagnostics driver (iqvw64.sys), according to the ATT&CK procedure record.
- Container or VM to host: ATT&CK lists Siloscape (Windows container escape) and Hildegard (CVE-2019-5736 in runc) under T1068, overlapping with T1611 Escape to Host.
- Application user to application admin: LAPSUS$ exploited unpatched internal JIRA, GitLab and Confluence servers to escalate, and BlackByte used CVE-2024-37085 in VMware ESXi for authentication bypass and escalation.
T1068 is distinct from abusing a control that works as designed, such as UAC bypass or sudo misuse, which is T1548 Abuse Elevation Control Mechanism, and from simply using stolen admin credentials (T1078 Valid Accounts). In investigations the three are often chained. See the Windows Privilege Escalation Techniques Guide and the Linux Privilege Escalation Techniques Guide for the misconfiguration families.
Where it shows up
| Environment | Typical vulnerable component | What the attacker gains | Identity exposed after escalation |
|---|---|---|---|
| Windows endpoints and servers | Kernel, CLFS and win32k drivers, third-party signed drivers | SYSTEM, kernel code execution, ability to kill EDR | LSASS secrets, machine account, cached service credentials, DPAPI keys |
| Linux servers and build agents | Kernel subsystems (netfilter, io_uring), setuid helpers such as polkit pkexec (CVE-2021-4034) | root | SSH keys, CI runner tokens, cloud CLI credential files, instance role via metadata service |
| Containers and Kubernetes nodes | Container runtime (runc), kernel, privileged pods | Node root, then other pods on the node | Projected service account tokens of every pod on the node, kubelet credentials |
| Hypervisors | ESXi, VMware Tools (CVE-2023-20867 used by UNC3886) | Host or guest admin across many VMs | Every guest workload, backup and vCenter service accounts |
| Internal applications and platforms | Collaboration tools, artifact repositories, AI compute frameworks | Application admin | Admin API tokens, integration secrets, stored cloud keys |
The last row is the one most often missed by endpoint-focused programmes. In the OpenAI and Hugging Face breach, AI agents exploited a token-refresh flaw in an internal Artifactory to gain administrator access, then harvested Kubernetes service account tokens and EC2 instance role credentials further along the chain. No kernel was involved, but the effect was the same: a low-privilege context became an admin one through a bug.
Impact
- Credential access at scale: SYSTEM or root on a server exposes every secret that server uses. On a Kubernetes node it exposes every pod's token. On a CI runner it exposes deployment credentials for production.
- Defence impairment: kernel-level access is what EDR killers need. That follow-on behaviour maps to T1685 Disable or Modify Tools under the v20 Defense Impairment tactic. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.
- Persistence below the radar: kernel code can hide processes and files (T1014 Rootkit) or install services (T1543.003 Windows Service).
- Blast radius across tenants: on shared compute (build farms, AI clusters, hypervisors) one exploit can cross from one customer or team into another.
Detection
ATT&CK v20 detection strategy DET0514 defines four analytics for T1068, one per platform. The table below lists their log sources and the logic we suggest building on top of them.
| Platform | Log source | Detection logic | Tuning notes |
|---|---|---|---|
| Windows | Sysmon Event ID 1 (process create) | Child process with IntegrityLevel System or user NT AUTHORITY\SYSTEM whose parent runs at Medium integrity under a normal user, excluding known installers and updaters | Baseline by parent image and signer; this is the highest-value single rule |
| Windows | Sysmon Event ID 6 (driver loaded) | Driver load where the hash or signer appears on the Microsoft vulnerable driver blocklist or an open driver list, or the driver path is a user-writable folder (Temp, Downloads, ProgramData) | Driver loads are rare; alert on any first-seen driver on servers |
| Windows | Security Event ID 4672 (special privileges assigned) | SeDebugPrivilege, SeTcbPrivilege or SeLoadDriverPrivilege assigned to an account that is not SYSTEM, LOCAL SERVICE, NETWORK SERVICE or an expected admin; correlate SubjectLogonId with 4624 | Requires the Audit Special Logon subcategory; SYSTEM logons are very noisy and must be filtered |
| Windows | Microsoft-Windows-CodeIntegrity/Operational | Driver blocked or audited by the blocklist policy; event 3099 confirms the policy loaded | An audit hit on a production host is an incident lead, not just a compatibility note |
| Linux | auditd SYSCALL (execve), plus file access rules | execve where uid is non-zero and euid becomes 0 without sudo or su in the ancestry; reads of /proc/kallsyms by non-root processes; unexpected kernel module loads | See the Linux Logging and auditd for Defenders Guide for rule syntax and volume control |
| macOS | Endpoint Security ES_EVENT_TYPE_NOTIFY_KEXTLOAD, unified log | Kernel extension loads and setuid process execution from unusual paths | Few organisations run kexts legitimately on modern macOS, so first-seen is a strong signal |
| Containers | auditd capset or setns, container runtime events | A container process gaining capabilities, joining host namespaces or writing outside its overlay filesystem; a shell spawned by the runtime on the node | Kubernetes audit logs add who created privileged pods; see the Kubernetes Audit Log Detection Guide |
| Applications | Application audit log, API gateway logs | A non-admin principal suddenly calling admin APIs, issuing new admin tokens or changing roles | Map admin endpoints first; most products log role changes but not failed escalation attempts |
Follow-on signals: escalation is usually silent, but what comes next is not. Correlate any of the rules above with access to LSASS, reads of /var/run/secrets/kubernetes.io/serviceaccount/ from outside the owning pod, calls to the cloud metadata endpoint from processes that never used it before, and security tool service stops. A process that escalates and then touches credentials within minutes is a high-confidence incident.
Where identity fits: treat the escalated host as having leaked every non-human identity it holds. The response is to rotate machine credentials, revoke tokens and review cloud API calls made with the host's role, not only to reimage. See the Cloud Instance Metadata Services Compared Guide and the Kubernetes Service Account Token Guide.
Metrics that show the controls work
- Median days to patch KEV-listed privilege escalation CVEs, split by servers, build agents and endpoints.
- Percentage of Windows devices with memory integrity (HVCI) on and the driver blocklist enforced.
- Percentage of Kubernetes namespaces enforcing Pod Security Standards Restricted or Baseline.
- Coverage: percentage of servers sending Sysmon Event ID 1 and 6, or auditd execve, to the SIEM.
- Time from an escalation alert to rotation of the host's machine credentials.
Prevention and hardening
| Control | ATT&CK mitigation | Concrete setting or action |
|---|---|---|
| Patch exploited local escalation flaws first | M1051 Update Software | Feed KEV into prioritisation; treat kernel and driver CVEs with known ransomware use as emergency changes. See the Vulnerability Prioritisation Guide. |
| Block vulnerable drivers | M1038 Execution Prevention | Microsoft vulnerable driver blocklist (on by default since the Windows 11 2022 update, enforced with HVCI, Smart App Control or S mode); deploy the downloadable App Control policy in audit mode first, as running drivers only stop after reboot |
| Exploit mitigations | M1050 Exploit Protection | Memory integrity (HVCI), control flow protections, Exploit Protection settings. See the Exploit Mitigations Guide. |
| Isolate workloads | M1048 Application Isolation and Sandboxing | Kubernetes Pod Security Standards Restricted: privileged unset or false, no hostPID or hostNetwork, allowPrivilegeEscalation false, runAsNonRoot true, seccompProfile.type RuntimeDefault; label namespaces pod-security.kubernetes.io/enforce |
| Reduce what escalation yields | M1026 Privileged Account Management | No long-lived admin secrets on hosts; IMDSv2 required with hop limit 1 so pods cannot reach node role credentials; short-lived tokens for CI runners |
| Know the threat | M1019 Threat Intelligence Program | Track which escalation CVEs your sector's actors use; ATT&CK links T1068 to groups including Volt Typhoon, APT28 and HAFNIUM |
Rollout order
- Inventory exposure: list hosts where untrusted code can already run as a low-privilege user: multi-user servers, CI runners, shared notebooks and AI compute, container nodes.
- Close the KEV backlog for those hosts, starting with entries marked known ransomware use. Use the Emergency Out-of-Band Patching Playbook for out-of-band changes.
- Turn on telemetry: Sysmon Event ID 1 and 6, Audit Special Logon, auditd execve and module rules. Validate that events reach the SIEM before writing rules.
- Driver blocklist in audit mode on a pilot ring for two weeks, review CodeIntegrity events, then enforce. Roll back by removing the policy and rebooting.
- Pod Security Standards in warn and audit mode per namespace, fix workloads, then enforce. Exempt only named system namespaces.
- Shrink credential yield: move host secrets to short-lived, workload-bound credentials so a future escalation captures less.
Decision guidance: small organisations get most value from fast patching plus default Windows protections (memory integrity, blocklist) and a managed EDR. Larger estates with build farms, Kubernetes and internal platforms should add the container and application-layer rules, because that is where shared compute makes one escalation affect many teams. If you cannot patch a kernel quickly (appliances, OT, long-lived hypervisors), compensate with isolation and by removing credentials from the host; see the Virtual Patching and Compensating Controls Guide.
Lessons from incidents
- Shared AI compute running as root: in ShadowRay, attackers' code on exposed Ray clusters often ran as root, which gave them cloud keys, AI API tokens, SSH keys and Kubernetes access without any separate escalation. ATT&CK records a privilege escalation payload in the same campaign (C0045). Running workloads as non-root would have forced the attacker to need T1068 at all.
- Application-layer escalation in internal platforms: the OpenAI and Hugging Face breach shows an artifact repository token-refresh flaw giving administrator access, followed by harvesting of instance role credentials and service account tokens. Internal tools need the same patch urgency and admin-API monitoring as internet-facing ones.
- Signed does not mean safe: Scattered Spider's use of the old iqvw64.sys driver and Embargo's use of a driver with a revoked certificate both relied on Windows loading signed vulnerable drivers. See the Scattered Spider Threat Actor Profile.
- Internal servers are not low risk: LAPSUS$ escalated through unpatched JIRA, GitLab and Confluence. See the Lapsus$ Threat Actor Profile.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | TA0004 Privilege Escalation, T1068; related T1611, T1548, T1078 | Technique and neighbours to chain in hunts |
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation, RA-5 Vulnerability Monitoring and Scanning, SI-16 Memory Protection, AC-6 Least Privilege, CM-7 Least Functionality, SI-4 System Monitoring, AU-12 Audit Record Generation | Patch, harden, monitor |
| NIST CSF 2.0 | ID.RA-01, PR.PS-02, DE.CM-09 | Identify vulnerabilities, maintain software, monitor runtime |
Practitioner checklist
- Pull KEV privilege escalation entries into patch SLAs and report median time to patch monthly.
- Enable memory integrity and enforce the vulnerable driver blocklist after an audit-mode pilot.
- Collect Sysmon Event ID 1 and 6 and Audit Special Logon (4672) from all servers.
- Deploy the medium-integrity-parent to SYSTEM-child rule and the first-seen driver rule.
- Add auditd rules for euid changes without sudo or su and for kernel module loads on Linux.
- Enforce Pod Security Standards Restricted on application namespaces.
- Require IMDSv2 with hop limit 1 on container nodes.
- Write the response step: on confirmed escalation, rotate every machine credential the host held.
- Include internal platforms (repositories, wikis, AI compute) in patch and admin-API monitoring scope.
Standards and references
- MITRE ATT&CK: Exploitation for Privilege Escalation (T1068)
- CISA: Known Exploited Vulnerabilities Catalog
- Microsoft Learn: Microsoft recommended driver block rules
- Microsoft Learn: Event 4672, special privileges assigned to new logon
- Kubernetes: Pod Security Standards
- AWS: Use the Instance Metadata Service to access instance metadata
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Windows Privilege Escalation Techniques Guide · Linux Privilege Escalation Techniques Guide · Bring Your Own Vulnerable Driver and EDR Killers Guide · CISA KEV Catalogue Guide · Sysmon Guide