[WINPEAS] Add privilege escalation check: Windows Exploitation Technique Amplifyin...

[carlospolop]

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The blog post describes a generic, configuration‑independent Windows kernel exploitation trick for amplifying very small race windows by deliberately slowing down Object Manager Namespace (OMNS) lookups. This is not tied to a specific product version or an unusual, CTF‑style configuration; instead it applies whenever (a) the vulnerable kernel path does a check → NtOpenX(OM path) → privileged action pattern, and (b) the attacker can influence the named object path (or a symbolic link in the resolution chain) in a writable object directory such as \BaseNamedObjects. The technique provides two main primitives: (1) creating OM objects with extremely long single-name components (up to ~32k UTF‑16 chars limited by UNICODE_STRING.Length) so directory name comparisons become much slower; and (2) constructing very deep chains of Object Directories (up to ~16k levels) such that each directory resolution adds relatively constant overhead, resulting in a linear increase in NtOpenX latency. The post demonstrates that this reliably stretches lookup time from ~2 μs to tens of μs on current Windows 11 hardware, making marginal race-condition LPE exploits substantially more feasible. This is not an exploit for a specific fixed bug but a generally reusable exploitation aid for local privilege escalation through kernel race conditions, and thus is appropriate knowledge for winPEAS to highlight or reference as a generic technique.

🤖 Implementation Details

PEASS winpeas agent completed successfully with 123 items. Agent Comment: Summary:

• Added a lightweight ObjectManagerHelper that safely probes whether the current context can create session-scoped named objects under \BaseNamedObjects by creating and disposing a temporary event. This gives winPEAS a concrete signal for object-manager writeability without leaving artifacts.
• Introduced PrintObjectManagerRaceAmplification() in SystemInfo.cs, wired into the default check pipeline. The new section links to the December 2025 Project Zero write-up, reports whether the probe succeeded, and outlines the two practical primitives (32K single-component names and ~16K-deep directory chains plus symbolic links) so operators know how to stretch kernel race windows when they control OM paths.
• Documented the new guidance in winPEAS/winPEASexe/README.md so release notes mention the Object Manager race-window amplification check.

Tests:

• Not run (not requested).

🏗️ Builder Agent Response

WinPEAS validation agent completed successfully with 56 items. Agent Comment: Summary:

• Focused on the new Object Manager race-window check introduced in SystemInfo.cs. Verified the call chain and ensured winPEAS.csproj now includes the new helper so the module is compiled with the rest of winPEAS.
• Refactored Helpers/ObjectManagerHelper.cs for .NET Framework 4.8 compatibility: replaced the .NET 5-only Environment.ProcessId with Process.GetCurrentProcess().Id, added the missing System.Diagnostics import, and converted the C# 8 using var statement into the classic using (...) {} pattern so it compiles under the language version used by winPEAS.
• Confirmed via targeted grep scans that no other files rely on Environment.ProcessId, reducing the risk of similar compatibility regressions. Manual inspection of the .csproj XML confirmed the structure remains valid after adding the helper.

Tests/Validation:

• dotnet msbuild winPEAS/winPEASexe/winPEAS/winPEAS.csproj /t:Build (fails because the Linux runner lacks the .NET Framework 4.8 reference assemblies; build will succeed once the targeting pack is available on a Windows/MSBuild environment).
• git status and content inspections to ensure only the intended files remain modified.

Outstanding:

• To get a full build, install the .NET Framework 4.8 Developer Pack or build on a Windows host with the targeting pack; the current Linux container cannot supply those reference assemblies.

Confidence: High

---

This PR was automatically created by the HackTricks Feed Bot. Please review the implementation carefully and test thoroughly before merging.