Enumerating Windows

You’re In. Now Become SYSTEM.

You landed on a Windows box, but as a nobody. A standard user. You can’t read other users’ files, can’t touch system settings, can’t dump hashes.

Privilege escalation is the climb from that unprivileged foothold up to Administrator or, better, SYSTEM, the all-powerful, kernel-level account that owns the machine.

Here’s the idea that every technique in this module comes back to:

Find something that runs with high privilege, but that you are allowed to change.

A service binary you can overwrite. A DLL a privileged program goes looking for. A scheduled task that runs your file. Each is just a different place to apply that one move.

But you can’t exploit what you haven’t found. So this first note is reconnaissance: understanding how Windows hands out power, then mapping the machine to spot where that power leaks.

How Windows Hands Out Power

Four mechanisms decide who can do what. You need all four to make sense of everything later.

Security Identifiers (SIDs)

Windows doesn’t track you by username. Internally, every user and group is a SID: a unique string that never changes.

The structure looks scary but decodes cleanly:

The RID is the useful bit:

• RID ≥ 1000 = a regular created account. 1001 means the second user made on the box.
• A handful of well-known SIDs name built-in principals: S-1-5-18 is SYSTEM, RID 500 is the built-in Administrator, S-1-1-0 is Everyone.

You rarely type a SID by hand, but knowing Windows identifies principals by SID, not name is the foundation for tokens, which is where power actually lives.

Access Tokens

When you log in, Windows builds you an access token: a bundle describing your security context. It holds your SID, the SIDs of every group you’re in, and your privileges.

Every process you start carries a copy of this token (a primary token), and that copy is what gets checked whenever the process touches anything.

This is why escalation often means getting a process with a better token, not “logging in again.”

Integrity Levels

On top of tokens, Windows ranks everything on a trust ladder called Mandatory Integrity Control.

The rule is one-directional and absolute:

A lower-integrity process cannot modify a higher-integrity object, even if its permissions would otherwise allow it. Your Medium process simply cannot touch a System file.

User Account Control (UAC)

Now the part that trips everyone up.

Being in the Administrators group does not mean you’re running as an administrator.

When an administrator logs in, UAC issues them two tokens:

1. A filtered token, standard-user power, running at Medium integrity. This is the one that’s active by default.
2. A full token, the real admin power, at High integrity. This one sits dormant.

The full token only activates when the user approves a UAC prompt (the “Do you want to allow this app to make changes?” popup). Until then, even an admin’s processes run at Medium and can’t modify system files or the registry.

This gap is the whole reason privilege escalation exists as a distinct step. Reaching the Administrators group isn’t the finish line; reaching High integrity or SYSTEM is.

Situational Awareness

With the model understood, you map the machine. The goal: gather enough that an escalation path becomes obvious.

Always collect:

• Identity: your user, hostname, groups, and privileges
• Other users & groups: especially anything that looks administrative
• The system: OS, version, build, installed patches
• Network: interfaces, routes, active connections (who else is logged in?)
• Software: installed applications and running processes

The core commands:

whoami /priv                    # YOUR privileges (read this carefully)
whoami /groups                  # your group memberships
Get-LocalUser ; Get-LocalGroup  # all users and groups
Get-LocalGroupMember Administrators
systeminfo                      # OS, build, patch level
ipconfig /all ; route print ; netstat -ano
Get-Process                     # what's running

What you’re reading for:

The escalation path is usually invisible until you can see the whole board. Skipping enumeration is the most common way to miss the easy win sitting right in front of you.

Hidden in Plain View

Before any clever technique, check whether someone simply left a password out. They do, constantly. The Post-it under the keyboard is now a text file on the desktop.

Sensitive data hides in:

• Notes and documents (asdf.txt, meeting notes, onboarding docs)
• Configuration files (a database .ini whose password is also a Windows password)
• Password manager databases lying around (.kdbx files)

# sweep the drive for likely files
Get-ChildItem -Path C: -Include *.kdbx,*.txt,*.ini -File -Recurse -ErrorAction SilentlyContinue

When you find a password, one rule dominates everything:

Try every password against every user and every service. Password reuse is rampant, and the password you found in a config file is very often someone else’s login.

This is also why privilege escalation is cyclical, not linear:

Every time you gain a new user, your file permissions change, so the whole search starts over. A file you couldn’t read as alex opens right up as jordan. Foothold becomes user, user becomes another user, and eventually one of them is an administrator. Re-enumerate after every step.

The PowerShell Goldmine

Modern users leak fewer passwords into plain files, but PowerShell logs more than ever, and those logs are a treasure trove.

The Clear-History Trap

The single best place to look, because of a misunderstanding almost everyone shares.

There are two separate histories:

1. PowerShell’s own session history, cleared by Clear-History and read with Get-History
2. The PSReadline history file on disk, which records every command typed, and which Clear-History does not touch

So an admin runs Clear-History, believes their tracks are wiped, and the PSReadline file still holds everything, often including a password they typed inline. Find the file and read it:

(Get-PSReadlineOption).HistorySavePath        # where it lives
type <that path>                               # read it

Transcripts and Script Block Logging

Enterprises often enable deeper PowerShell logging:

• Transcription (“over-the-shoulder” logging) records full sessions to a transcript file
• Script Block Logging records the full text of executed code

Both are defensive features. Both also capture plaintext credentials, for example the cleartext password used to build a PSCredential object that was missing from the history file. Read them when you find them.

Automated Enumeration

Doing all of the above by hand is thorough but slow, and a real engagement has a deadline. Automated tools run every check in minutes.

WinPEAS is the standard (with Seatbelt, PowerUp, and JAWS as alternatives). It scans the whole system and color-codes results, red for “exploitable,” green for “a protection is in place.”

But automation has a catch you must respect:

Tools miss things, and sometimes lie. In a real run, WinPEAS mislabeled the OS version and missed the desktop note, the PowerShell history, and the transcript, the exact files that won the box. The findings that matter most are often the ones a scanner skips.

The discipline: automate to save time, then verify by hand. Use WinPEAS to triage hundreds of files fast, but never let it be your only pass.

Where This Leads

You now understand how Windows hands out power, and you’ve mapped the machine: who’s privileged, what’s installed, who else is logged in, and whatever secrets were left lying around. Often that alone, a reused password in a config file, is enough to climb.

When it isn’t, you turn to misconfigurations: privileged things you’re allowed to change. The first and richest source of those is Windows services, the next note.