T1068: Exploitation for Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions.
When initially gaining access to a system, an adversary may be operating within a lower privileged process which will prevent them from accessing certain resources on the system. Vulnerabilities may exist, usually in operating system components and software commonly running at higher permissions, that can be exploited to gain higher levels of access on the system. This could enable someone to move from unprivileged or user level permissions to SYSTEM or root permissions depending on the component that is vulnerable. This could also enable an adversary to move from a virtualized environment, such as within a virtual machine or container, onto the underlying host. This may be a necessary step for an adversary compromising an endpoint system that has been properly configured and limits other privilege escalation methods.
Adversaries may bring a signed vulnerable driver onto a compromised machine so that they can exploit the vulnerability to execute code in kernel mode. This process is sometimes referred to as Bring Your Own Vulnerable Driver (BYOVD).CitationESET InvisiMole June 2020CitationUnit42 AcidBox June 2020 Adversaries may include the vulnerable driver with files delivered during Initial Access or download it to a compromised system via Ingress Tool Transfer or Lateral Tool Transfer.
Security context for executives and security teams
Privilege escalation through exploitation matters because it can turn an initial low-privilege foothold into SYSTEM, root, kernel-level, or host-level access from a container or virtualized environment. For leaders, the key issue is not only whether vulnerabilities exist, but whether patching, exploit prevention, execution control, isolation, and SOC visibility are strong enough to stop or quickly confirm escalation after compromise.
Executive priority
Prioritize this technique where business-critical Windows, Linux, macOS, and container workloads depend on strong separation of privilege. It is a decision point for vulnerability management, endpoint hardening, container isolation, incident response severity, and audit evidence: can the organization prove that high-risk OS, application, driver, firmware, and container escape paths are patched or mitigated, and can responders see attempts to load vulnerable drivers or execute exploit code?
Technical view
ATT&CK provides no official detection text for T1068, but relationship context includes DET0514 as a detection strategy and mitigations for threat intelligence, execution prevention, application isolation/sandboxing, exploit protection, and software updates. SOC and IR teams should validate visibility across endpoint and container platforms for privilege boundary changes, exploit-like process behavior, kernel/driver activity, new or suspicious signed drivers consistent with BYOVD risk, and post-exploitation movement from user-level context to elevated service, root, SYSTEM, kernel, or host context. Treat alerts in context with vulnerability exposure, recent patch state, asset criticality, and whether the affected component normally runs with high privileges.
Likely telemetry
- Endpoint process creation and parent/child process lineage around privilege changes
- OS security logs for elevation, service creation, privileged token/use, and administrative context changes
- Kernel, driver load, and code-signing related events, especially for newly introduced signed drivers
- Vulnerability and patch inventory for operating systems, applications, drivers, firmware, and container hosts
- Container and virtualization telemetry showing host access attempts or escape indicators
Detection direction
- Confirm whether DET0514 or equivalent local analytics exist; ATT&CK does not provide the detection logic in the supplied object.
- Correlate privilege escalation signals with known vulnerable software, missing patches, driver inventory, and exploit-protection events rather than relying on single events.
- Tune for BYOVD patterns: unexpected driver introduction, driver load from unusual paths, and signed-but-vulnerable driver usage, while accounting for legitimate administrative and hardware-management activity.
- Validate container and virtualized workload coverage; host escape risk is specifically relevant to this technique and is often missed when endpoint and cloud/container telemetry are managed separately.
- During IR, treat sudden elevation from a low-privilege process to root/SYSTEM/kernel or host-level access as a high-priority pivot point for containment scoping.
Mitigation priorities
- First, maintain timely software updates for operating systems, applications, drivers, and firmware, prioritizing internet-facing, privileged, and business-critical assets.
- Use exploit protection capabilities to reduce the chance that vulnerable components can be successfully abused.
- Apply execution prevention and application control so unauthorized exploit code, tools, and unapproved drivers are harder to run.
- Use application isolation, sandboxing, and container hardening to limit the blast radius if exploitation occurs.
- Maintain a threat intelligence program that maps relevant vulnerabilities, campaigns, and group tradecraft to the organization’s actual platforms and exposure.
Additional notes and limits
Relationship context shows this technique is used by multiple ATT&CK groups and campaigns and is mitigated by M1019, M1038, M1048, M1050, and M1051. The supplied description specifically highlights vulnerable high-privilege components, OS/kernel exploitation, container or VM escape, and Bring Your Own Vulnerable Driver behavior. Glexia would use this object to drive cross-functional validation between vulnerability management, endpoint engineering, container/cloud operations, SOC detection engineering, and incident response.
The official ATT&CK object does not include a detection section, and the related DET0514 details are not supplied beyond its name. This take therefore identifies evidence classes and validation priorities rather than a guaranteed detection method. Local asset inventory, patch state, EDR coverage, container architecture, and approved driver/software baselines are required to determine real exposure and coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Exploitation for Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions.
When initially gaining access to a system, an adversary may be operating within a lower privileged process which will prevent them from accessing certain resources on the system. Vulnerabilities may exist, usually in operating system components and software commonly running at higher permissions, that can be exploited to gain higher levels of access on the system. This could enable someone to move from unprivileged or user level permissions to SYSTEM or root permissions depending on the component that is vulnerable. This could also enable an adversary to move from a virtualized environment, such as within a virtual machine or container, onto the underlying host. This may be a necessary step for an adversary compromising an endpoint system that has been properly configured and limits other privilege escalation methods.
Adversaries may bring a signed vulnerable driver onto a compromised machine so that they can exploit the vulnerability to execute code in kernel mode. This process is sometimes referred to as Bring Your Own Vulnerable Driver (BYOVD).CitationESET InvisiMole June 2020CitationUnit42 AcidBox June 2020 Adversaries may include the vulnerable driver with files delivered during Initial Access or download it to a compromised system via Ingress Tool Transfer or Lateral Tool Transfer.
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.
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.
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.