Local privilege escalation is the attack surface that almost no defender audits and almost every breach traverses. Standard antivirus does not catch it. Patch management does not address it. The next Windows update will not fix it. It hides in plain sight inside the third-party software your organization installs every day.
What "EoP to SYSTEM" actually means
EoP is short for elevation of privilege. On Windows the highest local privilege tier is SYSTEM. A SYSTEM-level process can read any file, modify any setting, install any driver, dump any memory, disable security tooling and persist across reboots. Anti-tamper protections that work against a regular user fall over against SYSTEM.
Local privilege escalation is the moment an attacker who already has a regular user account on a Windows host moves from "I am a user" to "I am SYSTEM." That moment is the bridge between phishing-the-receptionist and owning-the-domain. Ransomware crews live for it. Insider threats abuse it. Penetration testers chain it into reports.
The frustrating part is that local privilege escalation rarely shows up in headlines. It is not glamorous. There is no zero-day worm spreading across the internet. There is no flashy exploit dropping a shell. It is one user account quietly becoming SYSTEM on one machine. Everything else attackers do is downstream of that moment.
Why the surface is invisible to most defenders
The Windows operating system itself is hardened. Microsoft has spent two decades closing direct kernel escalation paths and the major built-in services have been audited many times. The reason local privilege escalation is still everywhere has very little to do with Windows itself.
It is the third-party software stack.
Every printer driver suite. Every accounting application. Every backup agent. Every endpoint security tool. Every developer toolchain. Every collaboration platform that wants a tray icon. Each one wants to run something with elevated privilege so it can do its job. Each one ships background services that run as SYSTEM. Each one opens local interfaces (named pipes, COM endpoints, file system watchers, update routines) that a non-administrator process can interact with.
Almost none of those third-party privileged components have been audited for the specific question that matters: "If a regular user pokes at this interface, can they make it do something it should not?"
Microsoft cannot audit them. The vendor often will not. The customer cannot, because the customer does not own the source code and does not have the skillset to disassemble the binary. So the surface stays unchecked. Every install adds to it.
The three recurring classes
In the work the Sherlock Forensics lab does on this surface, three classes account for the overwhelming majority of findings. They show up across vendors, across product categories and across decades. They are the patterns a researcher looks for first.
Class 1: Phantom DLL loads. A SYSTEM process loads a library by name without specifying an absolute path. Windows searches a sequence of directories. If a regular user can write to one of those directories before the privileged process reads from it, the user has just placed code that runs as SYSTEM.
This sounds like it should be a solved problem. It is the oldest local privilege escalation class on Windows. It is also still everywhere, because shipping software is a deadline-driven enterprise and "let me think about my search path" is the kind of consideration that gets skipped on the way to release.
Class 2: Trusted file and update operations. A privileged service copies, downloads or applies a file on behalf of the user. The service trusts where the file came from. It trusts what the file is. If an attacker can influence the source, the target or the format, the privileged operation does the attacker's work with SYSTEM privileges.
Auto-update routines are the canonical example. The service fetches an update. If the fetch is not authenticated, if the signature is not checked, if the destination is not protected, the attacker has gained the ability to ship arbitrary code into a SYSTEM process.
Class 3: Unauthenticated local control channels. A widely-discussed class in Windows IPC security literature. The general pattern involves a privileged service exposing a local interface where access control and authorization are two distinct decisions that both need to be made correctly. The Labs page discloses PARTY LINE as belonging to this class category. Per Sherlock Forensics disclosure policy, mechanism specifics stay private during active disclosure windows.
For practitioners researching this surface independently, public security literature covers each of the three classes at conceptual level. The Microsoft Windows security guidance documentation, the SANS Institute reading room, the CERT secure coding standards and academic security research literature all document each class category. The Sherlock Forensics services practice contributes to the public class-level understanding through its coordinated disclosure program while keeping mechanism specifics of active findings private until vendor coordination completes.
Why standard defenses miss this
Antivirus is signature and behavior driven. It looks for malicious code patterns and suspicious runtime behavior. Local privilege escalation through a vendor's own SYSTEM service is, by definition, the vendor's own code running its own code path. Nothing about it looks malicious. AV does not flag it.
EDR is closer to the right primitive but still misses most of this. EDR watches for unusual parent-child process relationships, suspicious command lines and known exploit chains. A standard user account triggering a SYSTEM service to perform an action the service is designed to perform does not look like an exploit chain. It looks like the vendor's product working as designed.
Patching does not help either, because the underlying issue is a design decision in the third-party component. Until the vendor ships a fix, patching never touches it. And many of these third-party components do not have a recent security release at all.
The defender ends up with a surface that nothing in the standard toolkit checks.
What you can actually do about it
The Sherlock Forensics lab spent the last decade building expertise in exactly this surface. The practical answer for defenders breaks into four steps, in order of effort.
- Inventory the privileged third-party software on your fleet. Every endpoint security agent, every printer driver suite, every accounting package, every developer toolchain that runs as SYSTEM. The list is usually longer than IT thinks. Knowing what is there is half the work.
- Map the privileged services to known classes. For each privileged component, ask the three class questions. Does it load code from a path a user can influence? Does it perform trusted file or update operations? Does it expose a local control channel? The answers are usually documented in the vendor's own product documentation if you read for them.
- Audit the local interfaces directly. This is the step that requires the rare skillset. The named pipes the service exposes. The DLL search paths it uses. The update endpoints it talks to. Auditing this manually requires reading disassembly and inspecting service ACLs. The Sherlock EoP Auditor automates this step on Windows hosts.
- Establish a vendor pressure habit. When findings surface, report them. Use coordinated disclosure. Build the muscle inside your IT or security team for vendor security communication, because this surface will not improve until customers ask vendors to improve it.
The credibility loop
This is the surface the Sherlock Forensics lab focuses on. The four findings disclosed in the last sprint (BIG BROTHER, BLANK CHECK, SILENT NIGHT and PARTY LINE on the Labs page) are all living examples of these three classes. Three SYSTEM-level escalations and one unauthenticated local control channel. All four currently 0-patch under coordinated disclosure.
The same lab that finds these zero-days under coordinated disclosure is the lab that runs the Sherlock Forensics DFIR practice. The judgment that reads a service binary is the same judgment that reads an incident timeline. When local privilege escalation shows up in a breach (it almost always does), the forensic examiner who recognizes the class explains the breach faster.
Why incident responders care about this surface specifically
Talk to any digital forensics examiner with a few breach engagements under their belt and the conversation will surface the same pattern. The initial foothold is dramatic and gets the press. The privilege escalation is quiet and gets the actual compromise. The same examiner who walks the incident timeline backward from the ransom note to the first phishing click spends most of the analysis time on the privilege escalation gap, because that gap is where the casework lives. Was the initial-access account already admin (rare). Did the attacker exploit a Windows component vulnerability (less common than vendors hope). Did the attacker leverage a third-party privileged Windows service nobody had reviewed (almost always the answer).
The forensic toolchain for that reconstruction maps to specific surfaces. The Sherlock Universal Events Viewer reads the Windows event logs that contain the service interaction trail. The Sherlock Browser Viewer covers the user-side browser history that led to the initial click. The Sherlock PST Viewer reads the mailbox content for outbound phishing or insider activity post-compromise. The Sherlock Disk Imager captures the forensic image that underpins the whole chain of custody. Together they support the reconstruction the examiner needs to write the breach report.
What the examiner sees in dozens of those reconstructions is the same recurring third-party software pattern. The vendors change. The findings rhyme. The classes are the three Sherlock Forensics Labs publishes against: untrusted load paths, trusted privileged operations and unauthenticated control channels.
This is the feedback loop that makes the Sherlock Forensics services practice work. The casework informs which classes the lab prioritizes for research. The research informs what the casework examiner expects to see in the timeline. A finding in one column shortens the analysis path in the other. A class disclosed on the Labs page in one quarter often shows up in a customer breach timeline the next quarter. The cross-pollination compounds. For an enterprise looking at a digital forensics partner, this is the dimension worth probing: what does the firm do between engagements. Does that work show up in the engagement when it matters.
What we can do for your team
If you run a Windows fleet at any meaningful scale, the local privilege escalation surface deserves a planned look. The Sherlock Forensics services practice covers it as a standalone engagement or as part of a broader penetration test, IR retainer or compliance program. The Sherlock EoP Auditor automates the per-host scan once the binary releases.
For the immediate conversation, talk to our team. For an early-access notification on the EoP Auditor binary release, the notification list is open.
Local Windows privilege escalation lives in your third-party software. Auditing it is the work nobody does. Have Sherlock Forensics review your fleet.