performing-privilege-escalation-assessment

name	performing-privilege-escalation-assessment
description	Performs privilege escalation assessments on compromised Linux and Windows systems to identify paths from low-privilege access to root or SYSTEM-level control. The tester enumerates misconfigurations, vulnerable services, kernel exploits, SUID binaries, unquoted service paths, and credential stores to demonstrate the full impact of an initial compromise. Activates for requests involving privilege escalation testing, local exploitation, post-compromise escalation, or OS-level security assessment.
domain	cybersecurity
subdomain	penetration-testing
tags	["privilege-escalation","post-exploitation","Linux-privesc","Windows-privesc","local-exploitation"]
version	1.0.0
author	mahipal
license	Apache-2.0
d3fend_techniques	["Executable Denylisting","Execution Isolation","File Metadata Consistency Validation","Restore Access","Password Authentication"]
nist_csf	["ID.RA-01","ID.RA-06","GV.OV-02","DE.AE-07"]

Performing Privilege Escalation Assessment

When to Use

• After gaining initial low-privilege access during a penetration test to demonstrate full system compromise
• Assessing the security hardening of Linux and Windows servers against local privilege escalation attacks
• Evaluating whether endpoint detection and response (EDR) tools detect common privilege escalation techniques
• Testing the effectiveness of least-privilege policies and application whitelisting on endpoints
• Validating that container breakout and VM escape controls are properly configured

Do not use without written authorization, against production systems where exploitation could cause downtime, or for deploying kernel exploits on systems without prior approval and rollback capability.

Most Often Missed & How to Confirm

• Run the automated enumeration AND read it — linPEAS/winPEAS output is long; testers skim and miss the one writable service path or sudo entry. Pair it with manual checks (sudo -l, getcap -r /, whoami /priv).
• Token privileges on Windows — SeImpersonatePrivilege/SeDebugPrivilege (common on service/IIS accounts) give SYSTEM via PrintSpoofer/GodPotato and are routinely overlooked in favor of hunting kernel CVEs.
• Non-kernel Linux vectors first — sudo/GTFOBins, SUID/SGID, Linux capabilities (cap_setuid), writable cron scripts, and PATH hijacking are safer and more reliable than kernel exploits (which risk panics). Save kernel exploits for last.
• Stored credentials everywhere — cmdkey/AutoLogon/unattend.xml/web.config/PowerShell history on Windows; .env, config files, history, and SSH keys on Linux. Credentials beat exploits.
• Container/cloud escape — check for /var/run/docker.sock, --privileged, SYS_ADMIN, K8s service-account tokens, and the cloud metadata endpoint (169.254.169.254) for IAM creds. Apparent "root" may just be inside a container.
• How to confirm: prove escalation with a post-exploitation artifact — id showing uid=0 / whoami showing NT AUTHORITY\SYSTEM, plus reading a root-only file (/etc/shadow) or SYSTEM-only resource. Don't conclude a host is hardened until you've checked sudo, SUID, capabilities, cron, token privileges, stored creds, and container/metadata; don't fire a kernel exploit to "prove" privesc when a safer misconfig path exists and is already demonstrable.