[WINPEAS] Add privilege escalation check: The Windows Registry Adventure, Part 8 E...

[carlospolop]

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The blog post describes registry-based primitives that enable reliable local privilege escalation on modern Windows 11 systems, and several of these are configuration/ACL issues that are broadly relevant and not tied to an extremely custom CTF-style setup or a single obscure, legacy product.

Key elements suitable for WinPEAS:

1. Misconfigured writable descendants in privileged hives (HKLM / HKU)

   • The post explains that Windows enforces access control only on the final key in the path. As a result, deeply nested keys under HKLM and HKU can be writable by low-privileged users even when parents are locked down.
   • The author notes that SYSTEM-level enumeration finds over a thousand such writable keys in HKLM on Windows 11, highlighting that this is not a rare or CTF-only misconfiguration. Some of these are long-standing locations like HKLM\SOFTWARE\Microsoft\DRM and several keys under HKLM\SYSTEM and HKLM\SOFTWARE.
   • These misconfigurations are not the vulnerability by themselves, but they are the entry points that allow unprivileged users to interact with privileged hives in ways that make exploitation of hive-based memory corruption bugs feasible. Whether the specific CVEs mentioned are present or not, the misconfigured ACL pattern is a real-world hardening issue that WinPEAS can and should detect.

2. Cross-user writable key: HKCU\Software\Microsoft\Input\TypingInsights

   • The post highlights that this key exists in all user hives and is readable/writable by any user, enabling one user to write into other users’ hives.
   • This is explicitly called out as a cross-user/lateral exploitation primitive that can be used for DoS (hive space exhaustion), lateral movement, or as a staging point when hive-based memory corruption bugs are present.
   • The key path and its permissive ACL are part of standard Windows installations, not a custom CTF configuration.

3. Class-level exploit primitives dependent on vulnerabilities (not suitable for WinPEAS)

   • Other content in the post describes how to turn hive-cell corruption into kernel pool overflows, inter-hive corruption, and arbitrary kernel R/W by abusing the internal _CM_BIG_DATA and _CM_KEY_VALUE structures and CmpGetValueData behavior.
   • These require the presence of specific hive memory-corruption vulnerabilities (e.g., CVE-2023-23420, CVE-2023-23423, and others). Automatically checking for each such CVE in WinPEAS would not be scalable or generally desirable.
   • However, the configuration side (writable privileged keys, cross-user writable keys) is generic and can be checked safely.

Given the above, the suitable takeaway for WinPEAS is to add detections for dangerous registry ACL patterns in system and user hives, and specifically to flag known-problematic paths like HKLM\\SOFTWARE\\Microsoft\\DRM and HKCU\\Software\\Microsoft\\Input\\TypingInsights. These checks do not depend on fixed, obscure third‑party software, but on Windows’ own registry structure and common ACL misconfigurations, and they directly support registry-based privilege escalation techniques such as those described in the article.

🤖 Implementation Details

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

• Added a dedicated registry ACL scanner (RegistryAclScanner) plus an info container so winPEAS can safely inspect registry DACLs for well-known low-privileged principals without requiring the current user to have write access.
• Introduced the new registryinfo system check which reports the cross-user TypingInsights key, a curated list of Project Zero highlighted HKLM keys, and a depth/volume-limited heuristic scan (depth ≤3, max 25 results) for other HKLM locations writable by Users/Authenticated Users/Everyone to spotlight hive exploitation primitives.
• Documented the feature in the winPEAS exe README so operators know about the new registry-focused enumeration capability.

Testing:

• dotnet build winPEAS.csproj -c Release (fails: .NETFramework v4.8 reference assemblies are not installed in the runner image, so MSBuild cannot complete — no code issues indicated)

🏗️ Builder Agent Response

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

• Reviewed repo changes (new registry-focused check, helper, and updated project references) via git status/git diff and inspected the new C# files for syntax, namespace, and WinPEAS-integration issues.
• Verified winPEAS.csproj XML structure with Python’s xml.etree.ElementTree parser and ensured the new helper/check are included.
• Integrated the new registryinfo module into the CLI usage banner (winPEAS/Helpers/Beaprint.cs) so users can discover/run the check, addressing the pending WinPEAS-specific integration gap.

Validation & Checks:

• Manual code inspection of RegistryInfo.cs and RegistryAclScanner.cs for syntax problems, namespace mismatches, disposal issues, and convention adherence (no problems found).
• Pattern/greps to confirm new helper references and ensure no duplicate/undefined symbols remain.
• XML validation: python - <<'PY' ... ET.parse('winPEAS.csproj').
• Build attempt: dotnet build (fails because .NET Framework 4.8 reference assemblies are unavailable in this Linux runner, which is expected for this project).

Outstanding Issues:

• dotnet build cannot succeed here due to missing .NET Framework 4.8 targeting pack; building will require those reference assemblies on a Windows/.NET Framework environment.

Confidence: High

---

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