Windows Privesc Check PowerShell: An Archived Lesson in Security Tool Evolution

Hook

Sometimes the best contribution a security tool can make is knowing when to step aside. The maintainers of wpc-ps archived their own project and pointed users elsewhere—a rare act of developer honesty worth examining.

Context

Windows privilege escalation checking has a messy history. The original Windows Privesc Check, written in Python, was notorious among penetration testers for its problematic codebase and Unicode handling failures. When you're auditing Windows systems for security misconfigurations—checking service permissions, registry ACLs, and file system rights—the last thing you need is a tool that chokes on non-ASCII characters or requires dependency gymnastics.

SilentSignal's wpc-ps emerged in this frustration zone. The idea was elegant: rewrite the privilege escalation checks in native PowerShell, leveraging the scripting environment that ships with every modern Windows system. No Python installation, no external dependencies, just pure PowerShell accessing Windows APIs directly. It was meant to scan for the classic privilege escalation vectors—writable service binaries, insecure PATH directories, weak registry permissions—using the ACL inspection capabilities built into PowerShell. The project represented a philosophical shift from external tooling to Windows-native security auditing.

Technical Insight

The architecture of wpc-ps centers on PowerShell's Get-Acl cmdlet and .NET Framework access, querying security descriptors without requiring elevated privileges for read operations. The tool systematically enumerates services, checks their binary paths, and inspects the ACLs on those files to identify write permissions that shouldn't exist. Here's the core pattern for service binary checks:

Get-WmiObject Win32_Service | ForEach-Object {
    $servicePath = $_.PathName -replace '"',''
    $servicePath = $servicePath -split ' ' | Select-Object -First 1
    
    if (Test-Path $servicePath) {
        $acl = Get-Acl $servicePath
        $acl.Access | Where-Object {
            $_.FileSystemRights -match 'Write|FullControl' -and
            $_.IdentityReference -notmatch 'BUILTIN\\Administrators|NT AUTHORITY\\SYSTEM'
        } | ForEach-Object {
            Write-Output "[!] Writable service binary: $servicePath by $($_.IdentityReference)"
        }
    }
}

This pattern repeats throughout wpc-ps: enumerate a privilege-relevant resource (services, scheduled tasks, registry keys), extract its security descriptor, and filter for dangerous permissions. The elegance lies in using Windows' own access control model to audit itself.

The tool also checks PATH directories for writable locations that could enable DLL hijacking or binary planting. By iterating through $env:PATH and testing ACLs on each directory, it identifies where an unprivileged user could drop a malicious executable that might be invoked by a privileged process:

$env:PATH -split ';' | ForEach-Object {
    if (Test-Path $_) {
        $acl = Get-Acl $_
        $writeableBy = $acl.Access | Where-Object {
            $_.FileSystemRights -match 'Write|Modify|FullControl' -and
            $_.IdentityReference -match 'Users|Everyone'
        }
        
        if ($writeableBy) {
            Write-Output "[!] Writable PATH directory: $_"
        }
    }
}

The registry checks follow similar logic, targeting keys like AutoRun entries and service configurations where modification could lead to privilege escalation. PowerShell's native registry provider makes this straightforward—no Win32 API marshalling required.

What makes wpc-ps interesting from an architectural perspective is its defensive posture. Unlike offensive tools like PowerUp that attempt to exploit findings, wpc-ps strictly audits and reports. It never modifies permissions, never attempts to spawn elevated processes, and never writes files. This read-only approach makes it suitable for compliance auditing and security hardening without the risk of destabilizing production systems.

The tool's output is plaintext, designed for human consumption rather than machine parsing. Each finding includes the resource path, the problematic permission, and the security principal involved. While this lacks the structured JSON output modern tools provide, it reflects the era and use case: a penetration tester or auditor running manual checks and taking notes.

Gotcha

The elephant in the room: wpc-ps is officially archived and incomplete. The maintainers themselves state it should not be used, recommending itm4n's PrivescCheck instead. The TODO list in the repository reveals significant gaps—no unquoted service path checks, no Group Policy Preferences password extraction, no DLL hijacking detection beyond basic PATH checks. These aren't minor features; they're critical vectors in modern Windows privilege escalation.

The author describes wpc-ps as their first PowerShell project, and it shows in the code structure. There's limited error handling for edge cases like services with malformed paths or registry keys with restricted read access. The tool can throw terminating errors on certain system configurations, particularly with WMI queries against services in unusual states. PowerShell 2.0 compatibility was a goal, but modern security environments have long since moved past that requirement, making the backward compatibility constraints unnecessary technical debt. More fundamentally, the project served as a stepping stone—valuable for its time but superseded by tools built with more comprehensive features and active maintenance. Using wpc-ps today means inheriting bugs that will never be fixed and missing checks that modern privilege escalation techniques exploit.

Verdict

Use if: You're studying the history of PowerShell security tooling, researching how privilege escalation checkers evolved, or need to understand the specific limitations that led to better tools like PrivescCheck. It's also useful for academic purposes—teaching the fundamentals of ACL inspection in PowerShell or demonstrating why read-only auditing differs from exploitation frameworks. Skip if: You need actual security assessment capabilities. The maintainers are explicit: use PrivescCheck (itm4n) for production work. Skip if you're building automation, need reliable output, or require comprehensive coverage of modern Windows privilege escalation vectors. This is archived software with known gaps and no future updates. Respect the maintainers' honest guidance and move to actively maintained alternatives unless you have a specific historical or educational reason to examine wpc-ps.