It was two in the morning and I was halfway through a Brother iPrint&Scan service binary, manually walking an undocumented IPC pipe protocol byte by byte, when the pattern clicked. I had done this exact dance maybe forty times across a dozen vendors. The targets changed. The moves did not.
That was the moment I stopped trying to be a tool and started building one.
What hunting a local privilege escalation actually looks like
When you tell people you find Windows zero-days, they picture something cinematic. A green terminal. A clever exploit dropping into a debugger. Confetti.
The reality is forty hours of squinting at disassembly to figure out what an undocumented service binary thinks a valid command looks like, three more days reading service access control lists to figure out who can talk to it plus a coffee budget that would embarrass a roastery.
The hunt for local privilege escalation has three classes that I see over and over:
- Exposed control channels. A privileged Windows service listens on a local interface (a named pipe, a COM endpoint, an LRPC port) and an under-privileged user can reach that interface. Whether the service actually checks who is calling is a separate question that almost never gets asked.
- Untrusted load paths. A SYSTEM process loads code or files from a location a regular user can write to. Phantom DLL loads, writable plugin directories, configuration files that influence which library gets pulled in.
- Privileged operation logic. Trusted file, update or service routines that can be steered into doing something the developer never intended. Update services that fetch over plaintext. File-copy services that follow symlinks. Update payloads that get applied without being verified.
For each class I had a sequence of probes. Enumerate the running services. Filter to the ones running as SYSTEM. For each one, pull the binary, walk the imports, find the IPC endpoints, check the ACLs, watch the runtime behavior, look for the wrong-side authorization pattern. Rinse. Repeat. Find the bug or move on.
I was running the same moves. The targets changed. The moves did not.
The friction nobody talks about
The skillset to do this kind of work is rare. You need to read disassembly fluently. You need to know how Windows handles security descriptors. You need to recognize the undocumented binary protocols that vendors layer on top of named pipes when they want their own IPC. You need patience for the dead ends, because most of what you look at is fine.
That rarity is the problem. Every defender team in the world is staring at their local Windows surface and wondering whether the bundled third-party software ships a SYSTEM service that takes commands from regular users. Almost none of them have the skillset to check.
So the surface stays unchecked. Third-party vendors ship privileged components with surprising frequency and the attack surface they create gets reviewed only when something goes wrong.
What an actual hunt week looks like
A representative research week against a single vendor target follows a five-day cadence. Day one is target selection plus environment setup. Pick a Windows software product deployed widely enough to matter. Install it onto a clean Windows reference virtual machine. Take an initial forensic disk image with Sherlock Disk Imager so the baseline state is preserved for later diff and reproduction work. Capture the running process list, service inventory and registry state.
Day two is enumeration. Run the product through its normal workflows while watching what privileged services it installs and what local interfaces those services expose. Pull the binaries off disk. Compute SHA-256 hashes for chain of custody (free tooling at the Sherlock hash verifier works). Open the binaries in a disassembler. Sketch the rough architecture from imports, exports and string references.
Day three is the deep read. Pick the most promising service binary. Walk the entry point. Find the command dispatch logic. Identify the handlers. For each handler, ask the three class questions. Does it load code from a path a user can influence. Does it perform a trusted file or update operation. Does it accept commands without authorization checks. Most of the time the answers are reassuring. Sometimes one is not.
Day four is the reproduction. Take the candidate. Build a minimal client that talks to the suspect interface. Send the operations the handler accepts. Observe the result against the Windows event log (the Sherlock Universal Events Viewer is built for this triage step). If a regular user account triggers SYSTEM-level action, the finding is real. Confirm on a fresh reference system. Document the reproduction steps for the vendor report.
Day five is disclosure preparation. Write the technical report. Identify the CVE coordinator. Draft the vendor notification. Submit through coordinated disclosure. Start the 90-day clock. Move to the next target. Multiply that cadence by the universe of widely-deployed third-party Windows software in production and the math is depressing: there is more local privilege escalation surface than any researcher or research firm can cover by hand. The skillset gap is not closing.
The economics of the unchecked surface
The reason the surface stays unaudited is economic, not technical. A printer driver suite earns its margin on hardware sales. The team shipping the SYSTEM-level Windows service component is staffed for functionality and compatibility, not security research against their own code. There is no commercial incentive for the vendor to fund a research program against themselves. No regulatory pressure forces it. No customer in the procurement chain asks the right question during the buying cycle. The path of least resistance is to ship the service that works and move on.
The customer who installs that printer driver suite onto a Windows fleet inherits the surface. The customer cannot audit a binary they did not write. The customer's endpoint security product cannot detect the class because it is the vendor's own code running its own code path. The customer's patch management does not address it because there is no patch. Compliance frameworks like SOC 2 and PCI DSS focus on configuration and access controls rather than third-party binary security. The whole stack quietly normalizes the surface as part of the cost of running Windows.
That cost shows up later in the incident timeline. In the breaches the Sherlock Forensics DFIR practice handles, the privilege escalation step is almost always a third-party privileged service that nobody had reviewed. The forensic examiner reconstructs the path from the Windows event logs, the disk image and the registry. The technique that compromised the host was usually available years before the breach. The information gap is the unaudited surface multiplied by time.
The lightbulb
I am not the first researcher to notice that you do the same moves on every target. What changed for me, at two in the morning with Brother iPrint&Scan disassembly on my screen, was the realization that the moves were teachable to software.
Enumerate privileged services. Walk their local interfaces. Check the authorization patterns. Map untrusted load paths. Watch privileged operation logic for the recurring failure modes. That is a workflow. A workflow can be a tool.
The five-step thing I kept doing in my head looked like this:
How the EoP Auditor automates the hunt (5 steps)
This is the workflow Sherlock EoP Auditor runs on every Windows host you point it at. Each step maps to one of the recurring failure classes a manual researcher checks.
- Enumerate the SYSTEM-privileged surface. The Auditor lists every service running with elevated privilege on the host, then catalogs the local interfaces those services expose. Named pipes, COM endpoints, LRPC ports, file system paths. The map is the same map a researcher builds by hand, generated in seconds.
- Check who can reach each interface. For every exposed control channel the Auditor checks the access control descriptor and tells you which users can open and address it. A pipe a standard user can write to is not always a bug, but it is always worth a look.
- Probe authorization patterns. The Auditor checks how privileged services handle caller identity at the authorization layer beyond OS-level access control. The missing authorization class category is one of three the Auditor specifically covers.
- Map untrusted load paths. The Auditor checks the directories and configuration files that influence what a SYSTEM process loads at runtime. Writable plugin directories, search-path quirks, configuration injection. Phantom DLL loads and their siblings live here.
- Surface findings in plain language. Every finding comes with a verdict. What it is. Why it matters. Whether a standard user can really reach it. No wall of raw output. The tool's report reads like a researcher wrote it because the workflow is the workflow a researcher would run.
That last point is the design philosophy. Automate the craft. Keep the judgment.
The first real run
The first time the Auditor ran end to end on a clean target, it found a brand new zero-day on its own.
That finding is now publicly tracked as PARTY LINE. The Labs page hosts the public disclosure for the finding including vendor, product and class category. Article-level content does not add mechanism specifics beyond Labs disclosure during the active embargo window.
That was the moment the tool stopped being a hypothesis. It re-discovered the three SYSTEM-level zero-days I had found by hand in the same research sprint (BIG BROTHER, BLANK CHECK, SILENT NIGHT) and surfaced one I had not yet seen. Four findings in one sprint. None patched at the time of disclosure. All handled under coordinated disclosure.
Why I built it for people who do not read disassembly
If you are reading this and you can fluently walk an IPC pipe, the Auditor is not really for you. You will run it, it will tell you things you already could have found and you might use it as a sanity check.
The Auditor was built for the IT manager who has fifty Windows endpoints with thirty different third-party agents on them and no way to know which of those agents is shipping a SYSTEM service that takes commands from anyone. For the MSP that audits client fleets. For the incident responder who needs to map how a foothold became SYSTEM after the fact.
The promise is simple. Run the tool. Get the local privilege escalation surface of the host in plain language. Make decisions.
The mission, plainly
The Sherlock Forensics lab does coordinated vulnerability disclosure. We will keep finding these bugs by hand because the craft is real and irreplaceable. But the craft is also a teachable workflow that you can teach to software which then goes into the hands of people who need answers without a decade of reverse engineering to spend.
That is what the Sherlock EoP Auditor is. The hunter built a hunter. The hunter found a bug. Now we are putting the hunter in the hands of defenders.
What is next
Sherlock EoP Auditor 1.0.0 is in early access while we wait for vendor coordination on the PARTY LINE disclosure to complete. The product page is live. The early-access notification list is open. When the disclosure window closes and Brother coordination is complete, the binary will ship.
In the meantime, the Sherlock Forensics services practice is open for engagements that cover the same surface manually. If your Windows fleet has not been reviewed for local privilege escalation surface, this is the year to start. Talk to our team.
Want to be first when the EoP Auditor binary ships? Join the early-access list.