Detecting and Mitigating Exploitation for Privilege Escalation (T1068)

Exploitation for Privilege Escalation (MITRE ATT&CK T1068) is a Privilege Escalation technique. MITRE lists Containers, Linux, macOS and Windows as platforms.

The idea is simple. An adversary takes advantage of a programming error in a program, a service, or the operating system, including the kernel itself, to run code with more privileges than they started with. Permission levels exist to limit what a process can read and change, so an intruder who lands in a low-privilege process often needs a way around them.

How attackers use it

MITRE describes several paths.

Up the privilege ladder. Flaws usually sit in operating system components and software that run at higher permissions. Exploiting one can move an adversary from user level to SYSTEM or root, depending on the component.

Out of a sandbox. The same approach can move an adversary from a virtualized environment, such as a virtual machine or container, onto the underlying host.

Drivers. MITRE notes that adversaries may bring a signed vulnerable driver onto a compromised machine and exploit it to run code in kernel mode. This is sometimes called Bring Your Own Vulnerable Driver (BYOVD). The driver may arrive with files delivered during initial access, or be downloaded later through Ingress Tool Transfer or Lateral Tool Transfer.

MITRE also says this may be a necessary step when an endpoint is well configured and other privilege escalation methods are closed off. That is a useful way to read the technique: it is often the fallback when configuration is good, which makes patch and driver hygiene the part that remains.

How to detect it

MITRE's detection strategy has four analytics, one per environment:

• Windows: exploitation attempts against vulnerable kernel drivers or OS components, usually followed by unusual process or token behavior.
• Linux: escalation through vulnerable setuid binaries or kernel modules, often chained with unusual access to /proc/kallsyms or /dev/kmem.
• macOS: use of vulnerable kernel extensions, or entitlements abused through setuid or AppleScript injection chains.
• Containers: breakout behavior through exploitation, followed by interaction with the host OS or escalated capability assignment. MITRE gives the DirtyPipe flaw, CVE-2022-0847, as an example of this class.

In practical terms, collect the following:

• Process creation with the user and integrity level, so a normal user process that suddenly runs as SYSTEM or root stands out.
• Driver load events, for example Sysmon Event ID 6 on Windows, so you can see which drivers load and whether they are signed and expected.
• Kernel and audit logs on Linux for crashes, odd module loads and setuid execution.
• Container runtime events, to see a container process touching the host.

No single event proves exploitation. The pattern is a low-privilege process followed by a sudden change in who it is running as, what it can touch, or which driver it loaded.

How to reduce the risk

MITRE lists five mitigations:

1. Update software. Patch internal endpoints and servers on a regular schedule.
2. Exploit protection. Security tools that look for exploitation behavior, such as Windows Defender Exploit Guard, can block some of it. Control flow integrity checking is another way to spot or stop an exploit.
3. Application isolation and sandboxing. Make it harder to advance through unpatched or undiscovered flaws, using sandboxing, other forms of virtualization, and application microsegmentation. MITRE adds that risks from additional flaws in those systems may still exist.
4. Threat intelligence program. Build a capability to understand what types and levels of threat may use exploits and zero-days against your organization.
5. Execution prevention. Consider blocking known vulnerable drivers that adversaries may exploit to run code in kernel mode. Validate the driver block rules in audit mode first to make sure they are stable before moving to production.

Know what you are running

Patching only works if you know which versions are present. A lot of privilege escalation flaws arrive in the libraries and packages your applications ship with, not just in the operating system. You can get a quick inventory of a project's dependencies with the free in-browser scan at gold.safeguard.sh/scan. It needs no login, your file never leaves your machine, and it covers up to 100 dependencies.

Not every finding is equally urgent. Checking whether a flaw is actually reachable and exploitable in your setup helps decide what goes first. The demo below walks through that call.

Try it yourself

Click through it at your own pace, or open it full screen.

Check your own environment

# Windows PowerShell: list loaded kernel drivers with their file paths (read only)
Get-CimInstance Win32_SystemDriver | Where-Object State -eq Running | Select-Object Name, PathName

# Linux: kernel version and loaded modules (read only)
uname -r
lsmod | head -30

# Linux: list setuid binaries on the root filesystem (read only, may take a while)
find / -xdev -perm -4000 -type f 2>/dev/null

Then use this checklist:

• Do you have a patch window for kernel and driver updates, and do you measure it?
• Are driver block rules running in audit mode, with a plan to enforce them?
• Is the list of setuid binaries on your Linux hosts short and explained?
• Are containers running as non-root, with only the capabilities they need?
• Do your logs show the user and integrity level for each process?

Quick check

Sources

• MITRE ATT&CK T1068: Exploitation for Privilege Escalation