Privilege escalation on Windows

Objective 4.3 in this course covers host-based attacks — privilege escalation, process injection and credential dumping. Lesson 27 took Linux; this takes Windows, because half of Domain 4's host material is Windows-specific and reading about tokens is no substitute for having escalated with one. Runs on a Windows VM you built, in the lab from lesson 2.

Why this matters

Windows dominates enterprise desktop and much of enterprise server estate, so a network engagement that cannot escalate on Windows cannot demonstrate most of what an attacker would actually do. The mechanisms differ from Linux enough that they need their own lesson, and the exam tests the Windows-specific ones by name.

The shape is the same as lesson 27 — escalation is mostly enumeration — but the seams are different.

The lesson

Tokens, privileges and what SeImpersonate buys an attacker

Windows attaches an access token to every process, describing who it runs as and which privileges it holds. Escalation on Windows is often about tokens rather than passwords.

The key idea: some accounts hold specific privileges that are equivalent to full control even without being an administrator. The most important is the impersonation privilege held by many service accounts — it lets a process act as another account that connects to it. An attacker running as such a service account can, through a family of well-known techniques, coerce a privileged account to authenticate to them and then impersonate it, reaching full control.

The examinable point: a service account is not a safe place to be. Landing as one — which is exactly what exploiting a web application or a database service gets you — is frequently one step from system, because of the privilege the service account holds, not because of any additional flaw.

Unquoted service paths and weak service permissions

Two classic Windows configuration escalations:

• Unquoted service paths. A service whose executable path contains spaces and is not quoted can cause Windows to look for the executable at an earlier point in the path. If an attacker can write a file at that earlier point, it runs with the service's privileges when the service starts.
• Weak service permissions. A service an unprivileged user can reconfigure — change its executable, or its logon account — is a direct escalation: point it at your own program and restart it, or wait for a reboot.
• Weak permissions on the service's files — if the executable itself is writable, you replace it.

These are configuration findings, and like lesson 22's VLAN mistakes they are worth reporting even where you did not complete the escalation: the misconfigured service is the vulnerability.

Stored credentials and the registry

Windows stashes credentials in more places than administrators track, and enumerating them is a productive escalation and lateral-movement step both.

• The credential store, holding saved credentials for services and scheduled tasks.
• Registry keys with credentials in plaintext — autologon settings are the classic, and installed software frequently stores service credentials there.
• Unattended install files left on disk after deployment, which often contain a local administrator password.
• Scheduled tasks and services configured to run as a privileged account, whose stored credential can sometimes be recovered.
• Configuration files for applications, which hold database and service credentials exactly as on Linux.

Everything recovered is client data under lesson 4, and it feeds lesson 26's replay: a credential found here is used, not merely noted.

Escalating on your own Windows VM

The applied lab for objective 4.3 on the Windows side, on a lab VM from lesson 2.

1. Build and snapshot a Windows VM.
2. Plant one escalation path — an unquoted service path with a writable directory, a service whose permissions you loosen, or an autologon credential in the registry.
3. Land as a standard user.
4. Enumerate, using local checks and the automated tooling, and find the path from the evidence rather than from memory.
5. Escalate, and confirm you have system or administrator.
6. Read the event log, then roll back.

As with Linux, plant a different path and repeat, so the enumeration becomes the skill rather than a single trick. Windows enumeration tooling is mature; read what it checks, and confirm its findings by hand, because a tool's confidence is lesson 18's lead, not a finding.

Hardening that removes each path

Every finding closes with remediation at the cause:

• Impersonation exposure is reduced by keeping services on least privilege, by the platform's newer service-hardening features, and by not running unneeded services as powerful accounts.
• Unquoted paths are fixed by quoting them; it is a one-line change and a common bulk-remediation item.
• Weak service permissions are fixed by correcting the access control on the service, its binary and its directory.
• Stored credentials are removed by not storing them — using managed service accounts that do not expose a reusable secret, and clearing unattended-install files after deployment.
• Detection: service reconfiguration, new services, and a standard user gaining administrative rights are all events worth alerting on, and whether the client would have seen the escalation is part of the report.

The framing for the client is the same as everywhere in this domain: these are configuration and design changes, mostly cheap, and each removes a path that needed no exploit — only a misconfiguration and someone to notice it.

What to take into the exam

• Windows escalation is often about tokens and privileges, not passwords; a service account with impersonation privilege is frequently one step from system.
• Unquoted service paths and weak service permissions are staple configuration escalations, and are findings even when not completed.
• Credentials hide in the credential store, the registry, unattended-install files and application configs — recovered ones feed replay.
• Remediation is mostly configuration: quote paths, fix service permissions, use managed accounts, keep services on least privilege.