Hunting Privilege Escalation: Detecting the Climb to SYSTEM

A foothold on a standard user account is rarely the goal—it’s a starting position. Privilege escalation is the step where an attacker converts limited access into something genuinely useful, and hunting this tactic well means understanding that the climb from user to SYSTEM usually exploits a specific, identifiable gap between what a system was configured to allow and what it should have allowed.

Why Privilege Escalation Findings Are Unusually High-Confidence

Compared to some of the noisier tactics covered elsewhere in this series, confirmed privilege escalation findings tend to be higher confidence once identified, simply because there are fewer legitimate reasons for a standard user process to suddenly be operating with SYSTEM-level privileges. This is one of the more rewarding categories to build hunting capability around, because the signal-to-noise ratio, once you know where to look, is genuinely better than execution or persistence hunting tends to offer.

Exploiting Scheduled Tasks and Services for Escalation, Not Just Persistence

The same mechanisms covered in the persistence pieces—scheduled tasks and services—do double duty as privilege escalation vectors, because both can be configured to run with SYSTEM-level privileges regardless of the privilege level of the account that created them. An attacker with standard user access who can create or modify a scheduled task configured to run as SYSTEM has effectively escalated privileges without needing an exploit at all, purely through a permissions misconfiguration.

A hunt hypothesis worth building: review scheduled task and service creation events specifically for cases where the configured run-as context (SYSTEM, or another privileged account) doesn’t match the privilege level of the account that performed the creation. Say a standard user account creates a scheduled task configured to execute as SYSTEM—that mismatch alone, independent of anything else about the task, is worth flagging immediately, since it suggests either a serious misconfiguration in task creation permissions or active exploitation of one.

Token Manipulation and Impersonation

Windows access tokens, which carry a process’s security context, can be manipulated or stolen by an attacker who’s gained sufficient access to impersonate a more privileged account’s token without needing that account’s actual credentials. This is a more technically involved category to hunt for, typically requiring EDR-level visibility into token manipulation API calls rather than standard Windows event logs alone. If your EDR platform surfaces this telemetry, a hunt hypothesis worth prioritizing: review token manipulation or impersonation API calls made by processes running under lower-privileged accounts, specifically looking for cases where a process subsequently performs actions inconsistent with its originating account’s actual privilege level.

Exploiting Known Vulnerable Drivers and Kernel-Level Escalation

A persistent and genuinely dangerous escalation category involves exploiting vulnerabilities in signed but vulnerable drivers, sometimes called “bring your own vulnerable driver” techniques, where an attacker loads a legitimately signed driver known to have an exploitable vulnerability specifically to gain kernel-level access. This category is harder to hunt purely behaviorally and benefits significantly from maintaining an updated list of known vulnerable driver hashes or names, cross-referenced against driver load events in your environment. A hunt hypothesis worth running periodically: review driver load events for any drivers matching a maintained list of publicly documented vulnerable drivers, regardless of whether the specific driver is one your organization would normally use.

UAC Bypass Techniques: Familiar Ground, Constantly Evolving Specifics

User Account Control bypass techniques remain a common and well-documented escalation category on Windows, and while the specific implementation techniques evolve constantly as Microsoft patches known bypass methods, the general pattern is fairly consistent—a process attempting to launch another process with elevated privileges without the expected UAC prompt actually appearing. This is a genuinely good example of where staying current on specific published techniques (tying back to the OSINT and vendor research habits covered earlier) pays off directly, since new bypass methods get documented regularly and older ones get patched, meaning the specific hunt logic needs periodic refreshing even though the underlying pattern being hunted stays conceptually stable.

Exploiting Misconfigured Permissions Rather Than Software Vulnerabilities

Beyond technical exploits, a significant share of real-world privilege escalation exploits simple permission misconfigurations—a service running as SYSTEM with a binary path that a standard user account has write access to, for instance, letting an attacker replace the binary with something malicious that then executes with the service’s elevated privileges the next time it starts. This category is worth hunting for proactively rather than reactively, since it’s genuinely a configuration audit as much as a behavioral hunt. A hunt hypothesis worth running: identify services configured to run with elevated privileges, then check whether the accounts that would realistically be compromised first (standard user accounts) have write access to those services’ binary paths or configuration.

Treating Confirmed Escalation as an Immediate Priority Signal

Given how few legitimate explanations exist for most confirmed privilege escalation findings, treat a confirmed instance here with more urgency than a comparable finding at an earlier kill chain stage—this tactic sits close enough to serious impact that the response cadence should reflect the genuinely elevated risk a confirmed finding represents, moving quickly toward the incident response handoff covered in the hunting lifecycle piece rather than treating it as routine hunting output.