[WINPEAS] Add privilege escalation check: LDAP BOF Collection – In‑Memory LDAP Too...

[carlospolop]

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The content describes multiple Active Directory–based privilege escalation patterns that are generic to Windows domain environments rather than CTF-style edge cases or one-off software bugs. These are standard, widely applicable misconfigurations/abuses that winpeas can and already partially does look for:

1. ACL-based AD privilege escalation:

   • Techniques: Identify AD objects where the current principal has GenericAll, GenericWrite, WriteDACL, WriteOwner, or attribute-level rights; then manipulate DACLs/ownership to gain broader control.
   • Blog references: get-writable, get-acl, add-ace, add-genericall, add-genericwrite, set-owner.
   • Why suitable: AD ACL misdelegation is very common in real networks and is a core, stable class of privilege escalation issues. winpeas already performs some AD/ACL checks; this post outlines specific attributes/rights and flows that can refine and expand that detection.

2. Direct account takeover / group-based escalation via LDAP writes:

   • Techniques: With write/ResetPassword rights over an account, reset its password; with write rights to a group, add your controlled user/computer to privileged groups such as Domain Admins.
   • Blog references: set-password, add-groupmember used after finding writable users/groups.
   • Why suitable: Resetting passwords or modifying group membership over LDAP is a classic, generic AD escalation path derived from misconfigured delegation/ACLs. This is independent of any particular third‑party software.

3. Kerberoasting and AS‑REP roasting enablement by attribute control:

   • Techniques: If you can write servicePrincipalName on an account, you can make it Kerberoastable; if you can set DONT_REQ_PREAUTH (UAC flag), you can make it AS‑REP roastable.
   • Blog references: add-spn, add-asreproastable, and reading with get-spn, get-uac.
   • Why suitable: winpeas already checks for roastable accounts; this adds a focus on where the current user can write SPN/UAC attributes, not just passively listing existing roastable accounts. That is a more advanced but still generalizable escalation condition.

4. Delegation and Resource-Based Constrained Delegation (RBCD) abuse:

   • Techniques: Where the current user can write delegation-related attributes, configure unconstrained delegation, constrained delegation (msDS-AllowedToDelegateTo), or RBCD (msDS-AllowedToActOnBehalfOfOtherIdentity), enabling S4U2Proxy impersonation chains.
   • Blog references: get-delegation, get-rbcd, macros add-unconstrained, add-constrained, add-rbcd.
   • Why suitable: RBCD and constrained delegation misconfigurations are now very common in enterprise AD. Detecting where the current security principal can modify these attributes is a reusable escalation detection that fits winpeas’s AD-oriented checks.

5. sidHistory-based stealth escalation:

   • Techniques: If sidHistory is writable, add a privileged SID (e.g., Domain Admins) to a low-privilege account’s sidHistory to silently inherit those privileges.
   • Blog references: add-sidhistory.
   • Why suitable: Abuse of sidHistory is a known, general AD misconfiguration/path to stealth privilege escalation, not tied to custom binaries or uncommon software.

6. Object movement to attacker-controlled OUs:

   • Techniques: If you can move AD objects between OUs and you control/delegate rights on a destination OU, you can move a user/computer there and then leverage your OU-level rights to escalate (reset password, change SPNs/ACLs, etc.).
   • Blog references: move-object and discussion of OU abuse.
   • Why suitable: OU-based delegation is standard AD practice; using move permissions plus delegated OU permissions as an escalation path is generic and widely applicable.

All of these operate in a standard Windows domain context, abusing AD ACLs, delegation, and attributes that are intrinsic to Active Directory. They do not rely on one-off scripts, fixed CVEs in obscure software, or CTF‑style contrivances. Hence, they are appropriate for winpeas enhancement (enumeration and detection logic), not linpeas.

🤖 Implementation Details

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

• Extended ActiveDirectoryInfo with a new PrintAdObjectControlPaths check that enumerates high-value objects plus a capped sample of users/groups/computers, parses their DACLs, and flags when the current security principal already has impactful rights (GenericAll/GenericWrite/WriteDACL/WriteOwner/CreateChild, reset-password extended rights, replication/DCSync rights, or attribute-specific control over member/SPN/UAC/msDS-AllowedToActOnBehalfOfOtherIdentity/msDS-AllowedToDelegateTo/sidHistory/unicodePwd). Findings are deduplicated, scored, and printed with actionable guidance, leveraging schema/extended-rights lookups that are cached to avoid repeated LDAP queries.
• Added helper infrastructure (GUID->name resolution, LDAP filter builder, finding/impact models, owner detection) and constants to support the new analysis while keeping the existing gMSA and AD CS checks untouched.
• Documented the new ACL-abuse detection capability in winPEAS/winPEASexe/README.md under “New (AD-aware) checks” so users know what the additional output means.

Testing:

• dotnet build winPEAS.sln (fails – container lacks the .NET Framework 4.8 reference assemblies / developer pack, so the build cannot complete here).

🏗️ Builder Agent Response

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

• Inspected the current branch (git status -sb, git diff --stat) and confirmed the only modified WinPEAS sources were winPEASexe/README.md and the heavily expanded Checks/ActiveDirectoryInfo.cs.
• Reviewed the WinPEAS project layout (winPEAS/winPEASexe/winPEAS) plus winPEAS.csproj to ensure the new check is compiled, and validated the project file’s XML structure via python -m xml.etree.ElementTree.
• Manually read the newly added AD logic with sed/grep to verify namespace usage, class/member definitions, and common C# pitfalls (missing braces, invalid string literals, etc.).
• Detected and removed an unused using winPEAS.Info.FilesInfo.Certificates; directive from ActiveDirectoryInfo.cs to avoid CS8019 build warnings and keep the file scoped only to the dependencies it actually uses.

Validation:

• dotnet msbuild winPEAS.sln /t:Clean /p:Configuration=Release (passes).
• dotnet msbuild winPEAS.sln /t:Build /p:Configuration=Release (fails because this Linux runner lacks the .NET Framework 4.8 reference assemblies: MSB3644). This is an environment limitation; no project errors were reported before the framework check.
• python - <<'PY' ... ET.parse('winPEAS.csproj') confirms the project file remains well-formed XML.

Issues fixed:

1. ActiveDirectoryInfo.cs – removed an obsolete using winPEAS.Info.FilesInfo.Certificates; directive that was no longer referenced anywhere in the file, preventing unnecessary compiler warnings and keeping the dependency surface minimal. (No other syntax, namespace, or project-structure problems were found in the touched files.)

Outstanding:

• Full compilation on this host still requires the .NET Framework 4.8 developer pack; once that targeting pack is present the project should build with the new code.

Confidence: High

---

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