Skip to content

Conversation

@carlospolop
Copy link
Collaborator

🔧 Automated Privilege Escalation Check Addition

🤔 Privilege Escalation Reasoning

The blog describes several Windows privilege escalation paths that are generic, reusable, and not tied to CTF‑style custom configs or obscure software:

  1. Web RCE → Local SYSTEM via Potato exploits (e.g., PrintNotifyPotato)

    • After gaining RCE in the IIS/SharePoint worker process (w3wp.exe), Ink Dragon runs a Potato‑family exploit like PrintNotifyPotato to escalate from the low‑privilege web context to SYSTEM.
    • Potato techniques abuse misconfigured/abusable Windows services (print/notification/etc.) that run as SYSTEM but accept influence from low privilege accounts.
    • While the exploit binary itself is not detailed, the technique is a well‑known privilege escalation pattern on Windows servers and is sufficiently generic for winpeas to check for: presence of vulnerable services/configurations, OS/patch levels known to be affected by Potato variants, and potentially the presence of commonly used Potato tools.
  2. Abuse of idle/high‑privilege RDP sessions + LSASS access (SYSTEM → Domain escalation)

    • The actors enumerate RDP/console sessions and specifically abuse disconnected but not logged‑off Domain Admin RDP sessions.
    • Once they obtain SYSTEM, they dump LSASS (with custom tooling like LalsDumper) to harvest Domain Admin logon tokens/NTLMv2 credentials and then reuse them for SMB/WinRM to domain controllers, leading to NTDS.dit and hive theft (effective domain‑level privilege escalation).
    • This is a general, widely applicable technique: any Windows server where high‑privilege RDP sessions remain disconnected and LSASS is accessible from SYSTEM is vulnerable.
    • winpeas can already dump some authentication data, but this post highlights a specific, checkable condition: existence of disconnected RDP sessions belonging to high‑privilege users combined with LSASS accessibility from current context.
  3. SYSTEM via scheduled tasks and services (post‑exploitation persistence)

    • The blog shows the use of scheduled tasks and services that run as SYSTEM to maintain and re‑obtain high privileges (e.g., tasks like SYSCHECK or services like WindowsTempUpdate executing malware as SYSTEM).
    • While task/service creation itself is more persistence than escalation, winpeas can leverage the pattern by flagging misconfigured or attacker‑like tasks/services that give SYSTEM to non‑admin users. Detection of writable binaries or arguments in SYSTEM tasks/services can represent privesc opportunities in other environments.
  4. General LSASS/hive dumping from SYSTEM for privilege expansion

    • LSASS dumping (LalsDumper) and SYSTEM/SAM hive export are described as a standard step once SYSTEM is achieved, enabling password/hash extraction and Kerberos secret recovery.
    • That is a generic domain escalation pattern when you already have SYSTEM; winpeas already focuses on credential material, but the specific points (e.g., persistence of CredSSP/NTLMv2 material from disconnected RDP sessions) are additional context for improved checks.

These techniques are: (a) Windows‑specific, (b) common enough in real environments (IIS/SharePoint servers, RDP admin usage, Potato‑family escalation), and (c) not dependent on rare software or highly custom scripts. They fit winpeas’ goal of identifying misconfigurations and OS‑level weaknesses that enable or strengthen privilege escalation chains.

🤖 Implementation Details

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

  • Added a reusable IsHighPrivilegeAccount helper in Info/UserInfo/UserInfoHelper.cs that caches group lookups and tags accounts belonging to powerful groups (Administrators, Domain Admins, etc.). This classification is leveraged to spot accounts whose idle RDP sessions, like the Ink Dragon technique, leave valuable tokens inside LSASS.
  • Enhanced Checks/UserInfo.cs::PrintRdpSessions() to annotate every session with a new “HighPriv” column, surface a HackTricks reference, and emit explicit warnings whenever disconnected high-privilege sessions are found, guiding operators to dump LSASS/tokens just as Ink Dragon did.
  • Documented the feature in winPEAS/winPEASexe/README.md so users know winPEAS now highlights disconnected high-privilege RDP sessions for potential token/credential theft.

Tests:

  • dotnet build winPEAS/winPEASexe/winPEAS.sln -c Release (fails: .NET Framework 4.8 reference assemblies are missing in this runner, so the solution cannot be built here).

🏗️ Builder Agent Response

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

  • Reviewed the three modified files (README.md, Checks/UserInfo.cs, Info/UserInfo/UserInfoHelper.cs) from the current branch and verified the new “high-privilege RDP session” feature is syntactically and logically sound. The helper now caches privilege lookups, gracefully handles null inputs, and the RDP check prints enriched, colorized output plus remediation guidance.
  • Confirmed the broader WinPEAS project layout (winPEASexe, tests, binaries, helpers, etc.) to ensure the new helper code integrates with existing namespaces and conventions.
  • Performed pattern searches (grep) around the new HighPriv artifacts to ensure there are no orphan references and that helper methods are only used where expected.

Validation details:

  1. Git diff inspection showed only the intended files are touched. No additional local changes were introduced during validation (git status -sb clean apart from the 3 tracked edits).
  2. Structural review: enumerated key directories under winPEAS/ to reconfirm where checks, helpers, and info modules live, ensuring the new helper sits alongside related user-info helpers.
  3. Manual code analysis:
    • Read UserInfo.cs to verify formatting strings, dictionary usage, and null-guards inside the new RDP loop.
    • Reviewed UserInfoHelper.cs to ensure the cache dictionary, group indicator list, and new helper methods observe WinPEAS patterns (static helpers, Beaprint for warnings, Checks.Checks state).
    • Verified no missing using directives are required for the new APIs employed (StringComparer, StringComparison already covered by using System;).
    • Used grep to confirm only the intended call sites reference IsHighPrivilegeAccount.
  4. Project file validation: xmllint is unavailable in the runner, so I parsed winPEAS/winPEASexe/winPEAS/winPEAS.csproj via Python’s xml.etree.ElementTree to confirm the XML is well-formed.
  5. Build attempt: Ran dotnet msbuild winPEAS/winPEASexe/winPEAS/winPEAS.csproj /t:Rebuild /p:Configuration=Release. The build fails because the Linux runner lacks the .NET Framework 4.8 reference assemblies (MSB3644). This is an environment limitation; no code errors were reported before the failure.

Outstanding items / recommendations:

  • To fully compile WinPEAS, install the .NET Framework 4.8 Developer Pack (or build on a Windows host where those targeting packs exist). Until then, Linux-based builds will continue to stop at MSB3644.

Confidence level: High.


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

…aling the Relay Network and Inner Workings of a Stealthy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants