Windows Privilege Escalation — Initial Enumeration

On gaining a low-privileged shell on a Windows host (domain-joined or not), the goal is privilege escalation to further our access. Fully compromising the host may grant access to sensitive files/shares, the ability to capture traffic for more credentials, or credentials that escalate directly to Domain Admin in an Active Directory environment. Depending on system configuration and the data encountered, we may escalate to:

• NT AUTHORITY\SYSTEM (or LocalSystem) — more privileged than local administrator; used to run most Windows services.
• The built-in local administrator account — sometimes disabled, but often reused across multiple systems in a client environment.
• Another local account in the local Administrators group — same privileges as the built-in administrator.
• A standard domain user in the local Administrators group.
• A domain admin that is a member of the local Administrators group — highly privileged in the AD environment.

Enumeration is the key to privilege escalation. On gaining initial shell access, it’s vital to gain situational awareness: OS version, patch level, installed software, current privileges, group memberships, and more. The automated enumeration scripts/tools cover all of this (and much more), but it’s essential to understand how to perform these tasks manually — especially where tooling can’t be loaded due to network restrictions, lack of internet access, or active protections.

A solid Windows commands reference (e.g. ss64.com/nt) is handy to keep on hand for manual enumeration tasks.

Key Data Points

• OS name — workstation vs. server, and version/level (Windows 7/10, Server 2008/2012/2016/2019). Indicates what tooling is available (e.g., PowerShell version) and whether public exploits exist for that OS version.
• Version — as with OS version, specific builds may have public exploits. Windows exploits can cause instability or a full crash — understand the exploit and its ramifications before running it against any production system.
• Running services — especially those running as NT AUTHORITY\SYSTEM or an administrator-level account. A misconfigured or vulnerable service running under a privileged account can be an easy privesc win.

System Information

Tasklist

tasklist /svc lists running processes and the services hosted inside each. Get familiar with standard Windows processes/services so non-standard processes jump out quickly — e.g., spotting a FileZilla Server.exe worth version-checking for public vulnerabilities or misconfigurations (anonymous FTP access, etc.). Processes like MsMpEng.exe (Windows Defender) reveal what protections are in place that may need to be evaded/bypassed.

C:\htb> tasklist /svc

Standard processes worth recognizing on sight:

• smss.exe — Session Manager Subsystem. Launched first by the kernel during boot; starts csrss.exe and winlogon.exe, copies boot-time renamed files (pendmoves/pendfilerename), and sets system environment variables. A copy of smss.exe persists per interactive session, but the master instance exits after launching the first session — so any smss.exe still running as a child of something other than System is suspicious.
• csrss.exe — Client/Server Runtime Subsystem. User-mode side of the Win32 subsystem; handles console windows, process/thread creation and deletion, and some 16-bit virtual DOS machine support. Always runs as SYSTEM — a csrss.exe process with an unusual parent or command line is a red flag.
• winlogon.exe — Windows Logon Process. Manages secure attention sequences (Ctrl+Alt+Del), loads the user profile on logon, and launches LogonUI.exe for credential prompts. Historically abused via “Winlogon Notify” DLL registration and Userinit/Shell registry key hijacking for persistence.
• lsass.exe — Local Security Authority Subsystem Service. Enforces the local security policy, handles logon authentication (verifying against SAM or AD), and generates access tokens. Caches credential material in memory, making it the primary target for tools like Mimikatz (sekurlsa::logonpasswords) to dump plaintext passwords/hashes/Kerberos tickets — protect it with Credential Guard/LSA Protection (RunAsPPL) where possible.
• svchost.exe — Service Host. Generic host process for Windows services implemented as DLLs rather than standalone EXEs; many instances run simultaneously, each hosting one or more services grouped by tasklist /svc. Because it’s such a common/trusted binary name, it is a frequent malware masquerade target — always verify the binary path (C:\Windows\System32\svchost.exe) and parent process (should be services.exe) rather than trusting the name alone.
• ssms.exe — SQL Server Management Studio. Not a core OS process, but worth recognizing when seen in a tasklist on a database host: its presence alongside a running SQL Server instance suggests an admin workstation/jump box and a good target for credential hunting (saved SSMS connection strings, .sql scripts with embedded credentials). Its name is easily confused with smss.exe at a glance — don’t mistake one for the other when scanning process lists.

Environment Variables

C:\htb> set

PATH is one of the most overlooked variables. It’s not uncommon for administrators/applications to modify it (e.g., adding Python or Java, enabling execution of .py/.jar files). If a folder placed in PATH is writable by the current user, DLL injection against other applications using that path may be possible. Windows resolves a program from the CWD first, then PATH left to right — a custom path entry placed before C:\Windows\System32 is far more dangerous than one placed after.

HOMEDRIVE/USERPROFILE point at enterprise file shares used for roaming profiles. Browsing the share may reveal other accessible directories (e.g., an “IT Directory” with a password-laden inventory spreadsheet). Because roaming profiles follow the user across machines, a file dropped in USERPROFILE\AppData\Microsoft\Windows\Start Menu\Programs\Startup executes automatically whenever that user logs into any machine.

systeminfo

C:\htb> systeminfo

Shows OS version/build, hardware, and installed hotfixes (HotFixIDs under Hotfix(s)) — cross-reference the KBs against known CVEs. Hotfix information can be hidden from non-admins, so absence isn’t conclusive. System Boot Time + OS Version help gauge patch cadence — an uptime of 6+ months suggests the box isn’t being patched regularly. Network Information can indicate a dual-homed machine, though in most enterprises multi-network access is granted via firewall rule rather than a second physical NIC.

Patches and Updates (WMI)

If systeminfo doesn’t show hotfixes, query WMI’s QFE (Quick Fix Engineering) class directly:

C:\htb> wmic qfe

PS C:\htb> Get-HotFix | ft -AutoSize

Installed Programs

WMI can enumerate installed software — useful for spotting hard-to-find exploit targets. If FileZilla/PuTTY/etc. is installed, LaZagne is worth running to check for stored credentials. A program may also be installed and running as a vulnerable service.

C:\htb> wmic product get name

PS C:\htb> Get-WmiObject -Class Win32_Product | select Name, Version

Running Processes / Network Connections

netstat shows active TCP/UDP connections — services listening locally vs. externally accessible. A vulnerable service bound only to localhost may still be exploitable once logged on to the host.

PS C:\htb> netstat -ano

User & Group Information

Users are often the weakest link even on a well-patched, well-configured system. Understanding users/groups, group memberships granting admin-level access, current privileges, password policy, and logged-on users can turn up easy wins — e.g., a browsable home directory for a local-admin-group member containing logins.xlsx.

Logged-In Users

C:\htb> query user

Determine whether users are idle or active, and (where feasible) what they’re working on. On an evasive engagement, tread carefully around hosts with other active users to avoid detection.

Current User

C:\htb> echo %USERNAME%

Always check the current user context first — it may already be SYSTEM or equivalent. A service account context may carry SeImpersonatePrivilege, commonly abusable via a tool such as Juicy Potato.

Current User Privileges

C:\htb> whoami /priv

Current User Group Membership

C:\htb> whoami /groups

Check whether the user inherits rights through group membership, and whether those rights extend into the AD domain (enabling further lateral movement).

All Users

C:\htb> net user

Worth checking for naming patterns — e.g., credentials captured for bob plus a bob_adm account in local Administrators suggests credential reuse is worth testing. Also check accessible user profile directories (Desktop/Documents/Downloads) for scripts with embedded passwords or SSH keys.

All Groups

C:\htb> net localgroup

Non-standard groups can hint at the host’s purpose, usage level, or a misconfiguration (e.g., Domain Users added to Remote Desktop Users or local Administrators).

Group Details

C:\htb> net localgroup administrators

Check descriptions on non-standard groups for stray credentials, and cross-reference membership lists for non-admin users whose credentials, if obtained, would grant escalation.

Password Policy & Account Info

C:\htb> net accounts

Key Takeaways

• Enumerate before acting: OS/version, patch level (hotfixes), installed software, running services/processes, and current privileges/group membership all shape the available privesc paths.
• PATH and other environment variables can reveal writable-directory DLL injection opportunities and roaming-profile file share access.
• Hotfix/KB enumeration (systeminfo, wmic qfe, Get-HotFix) plus boot time is the fastest way to gauge whether a kernel/OS exploit is likely to land.
• whoami /priv and whoami /groups identify token privileges (e.g., SeImpersonatePrivilege → Juicy Potato) and inherited group rights before searching for exploits.
• User/group enumeration (net user, net localgroup, net localgroup administrators) surfaces credential-reuse opportunities and accessible home directories/shares that may contain plaintext secrets.