Your IT team probably patches Windows. Probably runs an endpoint security product. Probably enforces drive encryption. What your IT team almost certainly does not check is the local privilege escalation surface created by every third-party Windows application your organization installs. That surface is where most ransomware operators turn a foothold into a full domain compromise. Here is the practical checklist for finding and fixing it.
The 7-check Windows endpoint local surface review
This is the checklist the Sherlock Forensics services team runs on every Windows fleet review. The first five checks are free and can be done by anyone with administrative access to the host. The last two require specialized tooling or expert review.
- Inventory every third-party service running as SYSTEM. Run `Get-Service | Where-Object {$_.Status -eq 'Running'}` in PowerShell and filter for services whose binary path is outside `C:\Windows\`. Every entry is a third-party privileged process. The list is usually longer than expected. Each entry is a potential local privilege escalation surface.
- Check the binary path permissions for each privileged service. A SYSTEM service that loads its binary from a directory a regular user can write to is the classic phantom DLL load class. Use `icacls` on the binary's parent directory and look for any non-administrator group with write or modify access. The presence of such an entry is a finding.
- Check the service's named pipe exposure. Run `Get-ChildItem \\.\pipe\` to list every named pipe on the host. For each pipe owned by a third-party privileged service, check the pipe's access control descriptor. A pipe a regular user can open and write to is the missing-authorization class candidate (see The Party Line Problem for the explainer).
- Check writable DLL load paths. For each privileged service binary, run `dumpbin /imports` (or any PE inspection tool) and list the DLLs it imports. For each non-absolute import, the search order applies. Walk the DLL search path. Any writable directory in that search order is a privilege escalation opportunity.
- Check auto-update behavior. Every privileged third-party application that auto-updates is fetching code on a regular schedule. Watch the update behavior with procmon or equivalent. Confirm the update fetch is authenticated (HTTPS with certificate validation). Confirm the downloaded payload is signature-verified before execution. Auto-update routines that skip either check are remote code execution as SYSTEM waiting to happen.
- Run the Sherlock EoP Auditor on the host. The Sherlock Forensics EoP Auditor automates the first five checks and adds detection for the three recurring local privilege escalation classes that researchers find by hand. Currently in early access. Single portable executable. No install. Run as administrator for complete results.
- Have an expert review the findings. The tooling surfaces candidates. A human with reverse engineering experience confirms which candidates are exploitable in your specific environment. The Sherlock Forensics services practice covers this review as a standalone engagement.
Why your endpoint security product does not catch this
Endpoint detection and response is signature and behavior driven. EDR looks for unusual parent-child process relationships, suspicious command lines and known exploit chains. A local privilege escalation through a vendor's own SYSTEM service is, by definition, the vendor's own code running its own code path. It does not look like an attack. It looks like the vendor's product working as designed.
This is not an EDR criticism. EDR is excellent at what it does. The local privilege escalation surface created by third-party SYSTEM services is genuinely outside the EDR detection model. The defender has to address it through inventory, audit and configuration rather than detection.
Where to focus first
If you only have time to audit one category of third-party privileged software on your fleet, the highest-yield categories are these.
Printer driver suites. Brother, HP, Canon, Epson, Xerox. Almost every vendor ships a SYSTEM-level driver service plus a tray application plus a named pipe for status communication. The vendor focus is functionality, not security. The Sherlock Forensics lab has found PARTY LINE and BIG BROTHER in this category (see Labs page).
Accounting and tax preparation software. Intuit QuickBooks, Sage, Xero. These products run privileged services for file integrity, license management and update handling. BLANK CHECK and SILENT NIGHT both live in this category.
Backup agents. Veeam, Acronis, Veritas, Datto. Backup software needs to read every file on the system, which requires SYSTEM-level privilege. The agents run as SYSTEM and expose interfaces for backup orchestration. Audit them.
Developer toolchains. Docker Desktop, VS Code remote, GitHub Desktop, JetBrains IDE installers. These ship privileged components for filesystem operations, system services and update management. They are installed on developer endpoints, which are typically the most privileged endpoints in any organization.
Endpoint security agents themselves. Ironic but real. Antivirus and EDR products run as SYSTEM by necessity. They are not immune to the same classes they detect. The Sherlock Forensics services team has surfaced findings in major endpoint security products that the products themselves ship. Audit them.
How long this takes in practice
For a single Windows endpoint with a typical third-party software stack, the seven checks above take a technically competent administrator about 90 minutes to walk manually. The bottleneck is the binary path permission audit and the named pipe enumeration, both of which require precise tooling and a Windows-internals mental model. The Sherlock EoP Auditor automates the same audit in under a minute per host when it releases.
For a fleet of fifty endpoints with mostly-uniform software inventory, the manual approach scales linearly to about 75 hours of focused administrator time. Sampling is possible (audit 10 representative endpoints, extrapolate findings to the rest), but sampling misses the per-endpoint variations that matter: which version of which vendor agent shipped with which historical update, which configurations the prior IT team set, which exceptions accumulated. Full coverage at scale is where automation justifies itself economically.
For a fleet of five hundred endpoints, the manual approach is no longer feasible. The economics shift entirely to automation or services. The Sherlock Forensics services practice runs the fleet-scale version of this audit as a planned engagement with deliverables documented for the customer's own follow-up patch and remediation workflow. Sample report deliverables include the prioritized finding list per host, per-vendor consolidated remediation guide plus ongoing inventory baseline so the customer can rerun the audit on their own cadence post-engagement.
What forensic examiners look for in incident response
For incident responders walking the timeline of a confirmed compromise on a Windows fleet, the audit checks above run in reverse. Instead of "is this surface vulnerable to be exploited tomorrow," the examiner asks "was this surface the path the attacker took yesterday." The artifacts to look for shift accordingly.
The Sherlock Universal Events Viewer surfaces Windows event log entries documenting service interactions, account elevations and process creation patterns. Anomaly detection in the tool flags suspicious sequences that would take hours to find by manual Event Viewer paging. The Sherlock Disk Imager captures the forensic image that preserves the on-disk state for examination outside the live system. The Sherlock PST Viewer reads the mailbox content for outbound activity post-compromise (lateral phishing, data staging communications). The Sherlock Browser Viewer reads browser history for the original phishing click or initial-access pattern.
The forensic narrative the examiner produces uses all four tools plus the manual audit knowledge. Knowing which third-party privileged services were present on the host, which classes they fall into plus which were exposed during the compromise window narrows the timeline reconstruction significantly. The defender's preventive audit becomes the responder's investigative roadmap. Same data. Different frame.
The reporting move
When the audit finds something, the question is what to do with it. Two answers depending on your role.
If you are an internal IT or security team and the finding is on software your organization purchased, report it to the vendor through their security contact or PSIRT. Many vendors have a HackerOne or Bugcrowd program. Submit through the official channel. Most vendors respond reasonably to credible reports from credible reporters. Document what you found and when you reported it.
If you are an MSP, consultant or external researcher, follow coordinated disclosure. Notify the vendor with full technical detail. Use the standard 90-day window. Hold weaponized detail private until the window closes or the vendor ships a fix. See How We Hunt and How We Disclose for the Sherlock Forensics version of this policy.
What the EoP Auditor finds that manual checks miss
The seven manual checks above catch the obvious patterns. They do not catch the patterns that require seeing the full surface across many endpoints simultaneously. The Sherlock EoP Auditor adds capabilities that scale across a fleet rather than per-host: cross-endpoint correlation (a service that is benign on most endpoints but exposed on a few because of configuration drift), version drift detection (where one host runs an older vulnerable version of a third-party privileged component while the rest are current) plus class-pattern recognition trained on the lab's vulnerability research history.
The class-pattern recognition is the highest-value differentiator. The same researchers who run the Sherlock Forensics Labs disclosure pipeline trained the Auditor's detection logic. Patterns the lab has surfaced in BIG BROTHER, BLANK CHECK, SILENT NIGHT and PARTY LINE inform what the tool looks for. New patterns the lab finds in ongoing research get added to the detection module without customer involvement. Customers get the benefit of continuous research output without paying for the research separately.
For IT teams currently relying on a generic endpoint security product plus a patch management workflow, the Auditor closes the gap nothing else covers. The product page at sherlock-eop-auditor.html describes the three detection modules and the early-access list is open at the form anchor. Customers who sign up early get release notification the moment the binary ships, plus the option to participate in the limited pilot program where Sherlock Forensics services examiners review the customer fleet alongside the tool output for the first deployment cycle.
The Sherlock Forensics services play
If your organization runs at any scale and the seven checks above are not happening systematically, the Sherlock Forensics services practice covers them as a standalone engagement. Typical scope is a fleet inventory, per-vendor surface review, prioritized findings list and remediation recommendations.
Sample engagement deliverables: complete inventory of every privileged third-party service across the fleet, per-service surface assessment, per-finding remediation path, executive summary with risk prioritization, optional integration into your existing patch management workflow for ongoing visibility.
For an engagement conversation, talk to our team. For the EoP Auditor binary early-access notification, the notification list is open.
Your endpoint security product cannot see this. Your patch program does not cover it. Your auditor will not ask about it. But it is where every modern ransomware operator goes after the foothold. Have Sherlock Forensics review your fleet.