Lab 04 — Windows Privilege Escalation

Welcome to Lab 04 — Windows Privilege Escalation.

In the previous lab, you learned how to assess privilege boundaries on Linux.

Now you will apply the same methodology to a Windows host.

The central question is:

I HAVE A LOW-PRIVILEGED
WINDOWS ACCOUNT.

WHAT SECURITY WEAKNESSES
COULD ALLOW THIS ACCOUNT
TO GAIN MORE AUTHORITY?

A professional Windows privilege escalation assessment should examine:

IDENTITY
   ↓
GROUPS
   ↓
USER RIGHTS
   ↓
LOCAL ADMINISTRATION
   ↓
SERVICES
   ↓
SCHEDULED TASKS
   ↓
FILESYSTEM
   ↓
REGISTRY
   ↓
APPLICATIONS
   ↓
CREDENTIAL EXPOSURE
   ↓
UAC
   ↓
TOKENS
   ↓
SECURITY CONTROLS
   ↓
PRIVILEGE PATH

The objective is not simply to gain Administrator or SYSTEM access.

You should be able to explain:

Why the Boundary Failed

Which Permission Enabled It

Which Privileged Component Trusted It

What the Business Impact Is

How the Organization Should Fix It

Perform every activity only inside the GoHackersCloud lab, a Windows system you own, a purpose-built vulnerable training environment, or another system where you have explicit authorization.

Mission Information

Lab: 04 — Windows Privilege Escalation
Track: OffSec Labs
Difficulty: Intermediate → Advanced
Estimated Time: 3–5 Hours
Environment: Isolated Windows Training VM
Primary Role: Penetration Tester / Security Consultant
Focus: Local Windows Privilege Escalation
Starting Position: Authorized Standard User Session
Target Privilege: Local Administrator / SYSTEM in the training lab
Deliverable: Windows Privilege Escalation Assessment Report

Mission Scenario

During an authorized internal penetration test, your team has obtained a standard Windows account on:

APPWIN01

Example:

Hostname:
APPWIN01

Operating System:
Windows Server / Windows Workstation

Current User:
NOVATECH\analyst

Privilege:
Standard User

The organization wants to know whether a compromised ordinary user could gain additional local privileges through insecure Windows configuration.

Your mission is to assess:

Current Identity

Group Membership

Token Privileges

Local Administrators

Services

Scheduled Tasks

Filesystem Permissions

Registry Permissions

Application Configuration

Stored Credentials

Environment Configuration

UAC

Security Controls

and identify any unintended privilege path.

Lab Architecture

                PENTEST VM
                    |
                    |
                    v
             +-------------+
             |  APPWIN01   |
             |-------------|
             | Windows     |
             | Application |
             | Server      |
             +-------------+
                    |
                    |
             Authorized User
                    |
                    v
             +-------------+
             |   analyst   |
             |-------------|
             | Standard    |
             | User        |
             +-------------+
                    |
                    ?
                    |
                    v
             +-------------+
             | Administrator|
             | / SYSTEM     |
             +-------------+

Your job is to determine whether a legitimate path exists between:

analyst

and:

Administrator / SYSTEM

Learning Objectives

By completing this lab, you should be able to:

Establish the current Windows security context
Review local and domain group membership
Understand Windows access tokens
Identify sensitive token privileges
Review local administrator assignments
Analyze Windows services
Review scheduled tasks
Inspect filesystem permissions
Inspect registry permissions
Review application configuration
Identify credential exposure
Understand UAC
Review environment variables
Identify writable privileged resources
Build a privilege escalation path
Validate findings safely
Recommend remediation
Produce professional evidence

Prerequisites

You should understand:

Windows Users and Groups

NTFS Permissions

Windows Services

Task Scheduler

Registry

PowerShell

Command Prompt

UAC

Processes

Access Tokens

Active Directory Basics

Windows Privilege Escalation Mindset

Avoid:

Run Tool
  ↓
Try Every Exploit
  ↓
Hope for SYSTEM

Instead:

IDENTIFY
   ↓
ENUMERATE
   ↓
UNDERSTAND
   ↓
CORRELATE
   ↓
HYPOTHESIZE
   ↓
VALIDATE
   ↓
DOCUMENT
   ↓
REMEDIATE

Phase 01 — Confirm Authorization

Record:

Assessment:

Target Host:

Authorized Account:

Allowed Techniques:

Restricted Techniques:

Testing Window:

Evidence Location:

Cleanup Requirements:

Example:

Target:
APPWIN01

Starting Identity:
NOVATECH\analyst

Objective:
Assess local Windows privilege boundaries.

Environment:
GoHackersCloud Training Lab

Destructive Testing:
Not Permitted

Phase 02 — Create the Evidence Workspace

From PowerShell:

New-Item -ItemType Directory -Path C:\Temp\WinPrivEscLab -Force

Create a structure:

$folders = @(
    "Identity",
    "Groups",
    "Privileges",
    "Services",
    "Tasks",
    "Filesystem",
    "Registry",
    "Applications",
    "Credentials",
    "Evidence",
    "Report"
)

foreach ($folder in $folders) {
    New-Item -ItemType Directory `
        -Path "C:\Temp\WinPrivEscLab\$folder" `
        -Force | Out-Null
}

Evidence Standard

For every important observation record:

Timestamp:

Current User:

Host:

Resource:

Command / Method:

Observation:

Security Significance:

Potential Privilege:

Evidence:

Recommended Fix:

Phase 03 — Identify the Current User

Run:

whoami

Then:

whoami /all

Review:

User SID

Groups

Privileges

Integrity Level

Authentication Information

Phase 04 — Record the Host

Run:

hostname

Then:

systeminfo

Record:

Hostname

Operating System

Edition

Build

Architecture

Domain / Workgroup

System Role

Phase 05 — Determine Domain Context

Check:

$env:USERDOMAIN

and:

$env:USERDNSDOMAIN

Record whether the host is:

Standalone

Workgroup Joined

Domain Joined

Phase 06 — Build the Starting Context

Your notes should answer:

WHO AM I?

WHICH HOST AM I ON?

WHICH DOMAIN AM I IN?

WHAT GROUPS DO I HAVE?

WHAT TOKEN PRIVILEGES DO I HAVE?

WHAT IS THIS SYSTEM USED FOR?

Phase 07 — Enumerate Local Users

Use:

Get-LocalUser

If unavailable:

net user

Identify:

Administrator Accounts

Service Accounts

Support Accounts

Dormant Accounts

Application Accounts

Phase 08 — Enumerate Local Groups

Use:

Get-LocalGroup

or:

net localgroup

Focus especially on:

Administrators

Remote Desktop Users

Backup Operators

Event Log Readers

Remote Management Users

Custom Application Groups

Phase 09 — Review Current Group Membership

Run:

whoami /groups

Ask:

Am I Already in a Sensitive Group?

Does a Custom Group Grant Access
to a Privileged Resource?

Is the Group Used by a Service?

Does the Group Control an Application?

Phase 10 — Review Local Administrators

Run:

Get-LocalGroupMember Administrators

or:

net localgroup administrators

Document:

Local Accounts

Domain Accounts

Domain Groups

Service Accounts

Phase 11 — Understand Windows Tokens

When Windows authenticates a user, the session receives an access token.

Conceptually:

USER
 ↓
ACCESS TOKEN
 |
 +-- SID
 |
 +-- Groups
 |
 +-- Privileges
 |
 +-- Integrity Level

Windows uses the token during access-control decisions.

Phase 12 — Review Token Privileges

Run:

whoami /priv

You may see privileges such as:

SeChangeNotifyPrivilege

SeShutdownPrivilege

SeBackupPrivilege

SeRestorePrivilege

SeImpersonatePrivilege

SeDebugPrivilege

Do not assume that the presence of a privilege automatically means exploitation is possible.

Analyze:

Is It Enabled?

Why Does the User Have It?

What Security Boundary Does It Affect?

Is It Appropriate for This Role?

Phase 13 — Review Integrity Level

From:

whoami /groups

identify the mandatory integrity level.

Common concepts include:

Low

Medium

High

System

Conceptually:

STANDARD USER
=
MEDIUM INTEGRITY

while elevated administrators commonly operate at:

HIGH INTEGRITY

Phase 14 — Understand UAC

User Account Control separates normal administrative activity from elevated administrative activity.

Conceptually:

ADMIN ACCOUNT
     ↓
STANDARD TOKEN
     ↓
UAC APPROVAL
     ↓
ELEVATED TOKEN

UAC is a security boundary aid but should not replace proper least privilege.

Phase 15 — Check UAC Configuration

In the authorized lab, inspect:

Get-ItemProperty `
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

Review relevant configuration conceptually.

Do not modify UAC during enumeration.

Phase 16 — Enumerate Running Processes

Run:

Get-Process

A useful view:

Get-Process |
Select-Object Name, Id, Path

Access to some information may be restricted for a standard user.

Focus on:

Application Processes

Management Tools

Security Software

Custom Services

Phase 17 — Enumerate Services

Run:

Get-Service

For richer configuration details:

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

Build a table:

Service	Identity	State	Executable
AppService	LocalSystem	Running	C:\Program Files\App\service.exe
BackupAgent	LocalSystem	Running	C:\Tools\backup.exe

Phase 18 — Prioritize Privileged Services

Focus on services running as:

LocalSystem

LocalService

NetworkService

Privileged Domain Service Account

Then ask:

Can My User Influence
the Service?

Executable?

Directory?

Configuration?

Registry?

Arguments?

Dependencies?

Phase 19 — Inspect Service Configuration

For a selected training service:

sc.exe qc <ServiceName>

Review:

BINARY_PATH_NAME

SERVICE_START_NAME

START_TYPE

Phase 20 — Inspect Service Executable Permissions

Suppose the service executes:

C:\Program Files\NovaApp\NovaService.exe

Inspect:

Get-Acl "C:\Program Files\NovaApp\NovaService.exe" |
Format-List

Also inspect the directory:

Get-Acl "C:\Program Files\NovaApp" |
Format-List

Phase 21 — Understand the Service Permission Relationship

A dangerous relationship may look like:

analyst
   ↓
Write Permission
   ↓
Service Executable
   ↓
Service Runs As
   ↓
SYSTEM

The key issue is:

LOW-PRIVILEGE USER
CAN MODIFY
RESOURCE TRUSTED BY
PRIVILEGED SERVICE

Phase 22 — Review Custom Services First

Prioritize:

Company Applications

Backup Agents

Deployment Agents

Monitoring Tools

Custom Scripts

Legacy Software

These are usually more useful to examine than standard operating-system services.

Phase 23 — Inspect Service Directories

For each interesting service:

Get-ChildItem "C:\Path\To\Service" -Force

Review permissions:

Get-Acl "C:\Path\To\Service"

Ask:

Can I Create Files?

Can I Modify Existing Files?

Can I Rename Files?

Who Owns the Directory?

Phase 24 — Review Service Configuration Files

Look for:

*.config

*.xml

*.ini

*.json

*.yaml

*.yml

.env

within the authorized application’s directory.

Ask:

Does the Service Read It?

Does It Run Privileged?

Can I Modify It?

Does It Reference Another Executable?

Phase 25 — Service Finding Example

Finding ID:
WPE-001

Title:
Privileged Service Uses Writable
Application Directory

Starting Identity:
NOVATECH\analyst

Affected Service:
NovaService

Service Identity:
LocalSystem

Observation:
The standard user can modify resources
inside a directory consumed by a
LocalSystem service.

Impact:
A compromised standard user may be able
to influence privileged service behavior.

Recommendation:
Restrict service directories so only
authorized administrators and the
required service identity can modify them.

Phase 26 — Review Scheduled Tasks

Run:

Get-ScheduledTask

For more context:

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

Phase 27 — Inspect an Interesting Task

For a selected authorized task:

Get-ScheduledTask -TaskName "<TaskName>" |
Format-List *

Review:

Principal

Actions

Triggers

Run Level

Phase 28 — Understand Scheduled Task Privilege

A task may conceptually be:

SYSTEM
  ↓
TASK SCHEDULER
  ↓
maintenance.ps1

If:

analyst
   ↓
Can Modify
   ↓
maintenance.ps1

then the relationship becomes:

analyst
   ↓
Writable Script
   ↓
SYSTEM Scheduled Task

Phase 29 — Inspect Task Action Files

If the task references:

C:\Scripts\maintenance.ps1

inspect:

Get-Acl "C:\Scripts\maintenance.ps1"

and:

Get-Acl "C:\Scripts"

Phase 30 — Capture Original State

Before any controlled validation, record:

File Hash

Owner

Permissions

Content

Task Configuration

For example:

Get-FileHash "C:\Scripts\maintenance.ps1"

Phase 31 — Review Filesystem Permissions

Important areas may include:

C:\Program Files

C:\Program Files (x86)

C:\Scripts

C:\Tools

C:\Applications

C:\inetpub

Custom Application Locations

Do not broadly modify anything.

Phase 32 — Use Access Control Lists

Review:

Get-Acl "<PATH>" |
Format-List

Focus on permissions such as:

Write

Modify

FullControl

granted to:

Users

Authenticated Users

Everyone

Custom Low-Privilege Groups

Phase 33 — File Permission Mental Model

A finding may exist when:

STANDARD USER
      ↓
MODIFY
      ↓
SCRIPT / BINARY
      ↓
EXECUTED BY
      ↓
SYSTEM / ADMINISTRATOR

Phase 34 — Review Writable Application Directories

In your training environment:

Get-ChildItem "C:\Program Files" -Directory

Prioritize custom software.

You can inspect known directories with:

Get-Acl "<APP_DIRECTORY>"

Phase 35 — Review Registry Security

The Windows Registry can contain:

Service Configuration

Application Configuration

Startup Settings

Security Policy

Credentials or Secrets

Environment Settings

Phase 36 — Inspect Registry Keys

For an authorized application key:

Get-Item "HKLM:\SOFTWARE\NovaTech"

Review permissions:

Get-Acl "HKLM:\SOFTWARE\NovaTech" |
Format-List

Phase 37 — Registry Privilege Relationship

A dangerous pattern might be:

LOW-PRIVILEGE USER
        ↓
MODIFY REGISTRY CONFIGURATION
        ↓
PRIVILEGED SERVICE READS CONFIGURATION
        ↓
PRIVILEGED BEHAVIOR CHANGES

Again, the key is the trust relationship.

Phase 38 — Review Startup Locations

Applications can be configured to start automatically through several mechanisms.

In the lab, review standard startup configuration using approved Windows tools.

Focus on:

Executable

Owner

Permissions

Execution Context

Phase 39 — Environment Variables

Review:

Get-ChildItem Env:

Pay attention to:

PATH

TEMP

TMP

Application-Specific Variables

Phase 40 — Inspect PATH

Run:

$env:Path -split ';'

Investigate non-standard directories.

Ask:

Can My User Write There?

Does a Privileged Process
Search That Directory?

Does Software Use Relative
Executable Names?

Phase 41 — Review Temporary Locations

Common locations include:

%TEMP%

C:\Windows\Temp

Inspect:

$env:TEMP

and relevant permissions.

Temporary directories are not vulnerabilities by themselves.

The question is:

Does a Privileged Application
Trust User-Controlled Temporary Data?

Phase 42 — Review Installed Applications

Use:

Get-CimInstance Win32_Product

only cautiously because it can be intrusive in some environments.

A safer lab approach is to review:

Installed application directories

Start Menu entries

Known service paths

Application management inventory

Focus on business-relevant custom applications.

Phase 43 — Review Application Configuration

For an authorized application, inspect configuration such as:

XML

JSON

INI

PowerShell Scripts

Batch Files

Service Configuration

Look for:

Service Accounts

File Paths

Database Endpoints

Management Functions

Secrets

Administrative Settings

Phase 44 — Credential Exposure

Windows systems can expose synthetic lab credentials through poor operational practices such as:

Scripts

Configuration Files

Deployment Files

Backups

Documentation

Command History

If discovered:

DO NOT REUSE THEM
OUTSIDE THE LAB

Phase 45 — Review PowerShell History

For the current training account:

(Get-PSReadLineOption).HistorySavePath

If available and authorized:

Get-Content (Get-PSReadLineOption).HistorySavePath

Look for insecure operational behavior, but redact secrets from evidence.

Phase 46 — Review User Profile

Inspect:

Get-ChildItem $env:USERPROFILE -Force

Potentially relevant lab content includes:

Scripts

Configuration

Remote Access Files

Backups

Developer Files

Phase 47 — Review Saved Windows Credentials

Within the authorized lab:

cmdkey /list

This shows whether Windows has stored credential references.

Do not attempt to extract unrelated credentials.

Document only what is necessary to explain exposure.

Phase 48 — Review Network Connections

Run:

netstat -ano

or:

Get-NetTCPConnection

Identify:

Listening Services

Internal Applications

Local Management Interfaces

Application Dependencies

Phase 49 — Map Ports to Processes

For a specific PID:

Get-Process -Id <PID>

Ask:

Which User Runs the Process?

Is It Privileged?

Can My User Influence Its Files?

Phase 50 — Review Local Shares

Run:

net share

Assess only authorized shares.

Look for:

Deployment Shares

Application Shares

Administrative Data

Backup Locations

Remember:

Effective Access
=
Share Permissions
+
NTFS Permissions

Both should be considered when assessing access.

Phase 52 — Understand Windows Service Accounts

Services may run as:

LocalSystem

LocalService

NetworkService

Virtual Account

Local User

Domain User

gMSA

Each has different security implications.

Phase 53 — Service Account Governance

Document:

Account

Purpose

Privilege

Interactive Logon Need

Password Management

Network Access

Application Dependencies

Phase 54 — Review Token Privilege Relationships

Certain service or support roles may have sensitive privileges.

Do not treat privilege names as automatic exploitation instructions.

Instead ask:

Why Does This Account Have It?

Does the Business Role Require It?

Can the Privilege Influence
Higher-Privilege Processes?

Can the Permission Be Removed?

Phase 55 — Review Windows Security Controls

Document:

Microsoft Defender

Firewall

Application Control

Credential Protection

Audit Policy

UAC

Examples:

Get-MpComputerStatus

where available.

Phase 56 — Do Not Disable Security Controls

During this lab:

DO NOT:

Disable Defender

Disable Firewall

Disable Logging

Disable UAC

Disable EDR

Your objective is to assess the environment, not weaken it unnecessarily.

Phase 57 — Review Firewall Profiles

Where authorized:

Get-NetFirewallProfile

Document:

Domain

Private

Public

profiles and their state.

Phase 58 — Review Audit Configuration

You can inspect:

auditpol /get /category:*

Look for coverage around:

Logon

Account Management

Privilege Use

Process Creation

Policy Change

Phase 59 — Manual Enumeration First

Before using automated tools, manually review:

Identity

Groups

Privileges

Local Administrators

Services

Scheduled Tasks

Filesystem

Registry

Applications

Credentials

Environment

Security Controls

This builds understanding.

Phase 60 — Automated Enumeration as Cross-Check

If your training lab provides an approved Windows enumeration utility, use it only after the manual review.

For every generated observation verify:

Does It Exist?

Can My User Reach It?

Does It Cross a Privilege Boundary?

What Is the Root Cause?

What Is the Business Impact?

Phase 61 — Build the Windows Privilege Matrix

Create:

Vector	Observation	User Influence	Privileged Context	Priority
Service	Writable app directory	Yes	SYSTEM	Critical
Scheduled task	Writable script	Yes	SYSTEM	Critical
Registry	Writable service config	Yes	SYSTEM	High
Token	Sensitive privilege	Review	Elevated	High
Credential	Synthetic admin secret exposed	Yes	Admin	High

Use only findings actually present in your training environment.

Phase 62 — Build the Privilege Graph

Example:

NOVATECH\analyst
       |
       | MemberOf
       v
ApplicationSupport
       |
       | Modify
       v
C:\NovaApp\maintenance.ps1
       |
       | Executed By
       v
SYSTEM Scheduled Task

This explains the privilege path clearly.

Phase 63 — Identify the Root Cause

For the previous example:

Root Cause:

A script executed by a SYSTEM-level
scheduled task is writable by a
lower-privileged support group.

Not:

Windows Scheduled Tasks
Are Vulnerable

The problem is:

Incorrect Access Control

Phase 64 — Controlled Validation

Once you identify a valid lab privilege path:

DOCUMENT
   ↓
VERIFY SCOPE
   ↓
CAPTURE ORIGINAL STATE
   ↓
USE MINIMUM-IMPACT VALIDATION
   ↓
CONFIRM PRIVILEGED EXECUTION
   ↓
COLLECT EVIDENCE
   ↓
RESTORE STATE

Phase 65 — Safe Validation Pattern

For example, if a training scheduled task running as SYSTEM consumes a script that your account can modify, use a harmless proof of execution rather than making broad system changes.

Conceptually:

STANDARD USER
      ↓
AUTHORIZED WRITABLE SCRIPT
      ↓
SYSTEM SCHEDULED TASK
      ↓
HARMLESS MARKER
      ↓
VERIFY EXECUTION CONTEXT

Afterward:

Restore Original Script

Remove Marker

Verify Hash

Verify Task State

Phase 66 — Confirm the Privilege Boundary

Your evidence should show:

Starting Context:
NOVATECH\analyst

and:

Controlled Result:
Privileged execution occurred
through the identified trusted resource.

That is enough to demonstrate the finding.

Phase 67 — Finding WPE-001

Finding ID:
WPE-001

Title:
Writable SYSTEM-Executed Scheduled Script

Affected Host:
APPWIN01

Starting Identity:
NOVATECH\analyst

Observation:
The analyst user receives modification
rights to a maintenance script through
the ApplicationSupport group.

The script is executed by a scheduled
task using the SYSTEM identity.

Privilege Path:

analyst
→ ApplicationSupport
→ writable maintenance script
→ SYSTEM scheduled task

Impact:
A compromised standard user could
influence privileged code execution.

Severity:
Critical

Recommendation:
Restrict the script and its parent
directory so only authorized
administrators can modify them.

Phase 68 — Finding WPE-002

Finding ID:
WPE-002

Title:
Privileged Windows Service Uses
Writable Application Resource

Observation:
A LocalSystem service depends on
application files writable by a
non-administrative support group.

Impact:
A lower-privileged account may be able
to influence privileged service behavior.

Recommendation:
Apply least-privilege ACLs to service
executables, directories, configuration,
and dependencies.

Phase 69 — Finding WPE-003

Finding ID:
WPE-003

Title:
Insecure Registry Permissions Affect
Privileged Service Configuration

Observation:
A low-privileged identity can modify
registry configuration consumed by a
privileged service.

Impact:
Unauthorized configuration changes may
alter privileged application behavior.

Recommendation:
Restrict registry modification rights to
authorized administrators and required
service identities.

Phase 70 — Finding WPE-004

Finding ID:
WPE-004

Title:
Sensitive Administrative Credential
Stored in User-Accessible Configuration

Observation:
A synthetic administrative credential is
stored in a configuration file readable
by standard users.

Impact:
Compromise of a standard account could
lead to unintended administrative access.

Recommendation:
Remove plaintext credentials and use
approved secret-management or managed
identity mechanisms.

Phase 71 — Finding WPE-005

Finding ID:
WPE-005

Title:
Excessive Local Administrative Group
Membership

Observation:
A support account or group has local
administrator access beyond documented
business requirements.

Impact:
Compromise of the support identity would
provide unnecessary high privilege.

Recommendation:
Remove unnecessary membership and use
role-specific delegated administration.

Phase 72 — Build the Risk Matrix

Finding	Likelihood	Impact	Severity
Writable SYSTEM task script	High	Critical	Critical
Writable service resources	High	Critical	Critical
Writable privileged registry config	Medium	High	High
Credential exposure	High	High	High
Excessive local admin	High	Critical	Critical

Adjust according to your actual lab results.

Phase 73 — Remediate Services

Apply:

Protected Executable

Protected Service Directory

Protected Configuration

Restricted Registry Keys

Dedicated Service Identity

Least Privilege

The key principle is:

If SYSTEM Executes It,
Standard Users Should
Not Control It.

Phase 74 — Remediate Scheduled Tasks

Review:

Task Principal

Script Ownership

Executable Ownership

Directory Permissions

Arguments

Environment

Triggers

Privileged scheduled-task resources should have tightly restricted modification rights.

Phase 75 — Remediate Filesystem ACLs

Use:

Least Privilege

Correct Ownership

Role-Based Access

Separate Administrative Groups

Periodic ACL Reviews

Avoid granting:

Users

Everyone

Authenticated Users

write access to privileged execution paths unless explicitly required.

Phase 76 — Remediate Registry Permissions

Review:

Service Keys

Application Keys

Startup Configuration

Security-Sensitive Settings

Restrict modification to:

Administrators

SYSTEM

Required Service Identity

Phase 77 — Remediate Credentials

Avoid:

Passwords in Scripts

Passwords in Configuration

Passwords in PowerShell History

Shared Administrative Credentials

Prefer:

Managed Service Accounts

gMSA

Credential Vaults

Secret Management

Rotation

Short-Lived Credentials

Phase 78 — Remediate Administrative Access

Use:

Least Privilege

Dedicated Admin Accounts

Windows LAPS

Administrative Tiering

Privileged Access Management

Access Reviews

Phase 79 — Harden Service Accounts

Prefer:

Least Privilege

Non-Interactive Accounts

Managed Passwords

Restricted Logon Rights

Restricted Network Access

Dedicated Application Identity

Phase 80 — Detection Opportunities

Windows privilege escalation may create evidence in:

Security Event Logs

PowerShell Logs

Service Control Manager Logs

Task Scheduler Logs

File Auditing

Registry Auditing

Endpoint Security Logs

Phase 81 — Important Event Categories

Security teams should pay attention to events around:

Process Creation

Service Installation / Change

Scheduled Task Change

Local Group Membership

Privilege Use

Logon

Account Changes

Phase 82 — Useful Windows Security Events

Examples include:

Event ID	Security Context
4624	Successful logon
4625	Failed logon
4672	Special privileges assigned
4688	Process creation
4697	Service installed
4698	Scheduled task created
4702	Scheduled task updated
4732	Member added to local group
4733	Member removed from local group

Exact telemetry depends on audit policy and Windows version.

Phase 83 — Monitor Service Changes

Changes to:

Service Binary

Service Account

Startup Type

Service Configuration

should be monitored for privileged services.

Phase 84 — Monitor Scheduled Tasks

Watch for:

New Tasks

Modified Tasks

New Task Actions

Changed Principals

Unexpected SYSTEM Tasks

Phase 85 — Monitor Sensitive Files

Consider file-integrity monitoring for:

Privileged Scripts

Service Executables

Application Configuration

Administrative Tools

Phase 86 — Cleanup

After validation:

Restore Modified Scripts

Restore File ACLs

Restore Registry Values

Remove Test Files

Remove Temporary Accounts

Remove Test Tasks If Created

Restore Service Configuration

Terminate Test Processes

Secure Evidence

Cleanup Checklist

Phase 87 — Retest

After remediation:

ORIGINAL PRIVILEGE PATH
       ↓
REPEAT ENUMERATION
       ↓
VERIFY ACL
       ↓
VERIFY SERVICE / TASK
       ↓
VERIFY USER CANNOT MODIFY
       ↓
CONFIRM PATH BROKEN

Example:

Before:

analyst
→ ApplicationSupport
→ writable script
→ SYSTEM task

After:

analyst
→ ApplicationSupport
→ X
→ SYSTEM task

Final Report Structure

Use:

01 Executive Summary

02 Scope

03 Starting Access

04 Environment

05 Methodology

06 Identity Assessment

07 Group Assessment

08 Token Privileges

09 Local Administrator Review

10 Service Assessment

11 Scheduled Task Assessment

12 Filesystem Assessment

13 Registry Assessment

14 Application Assessment

15 Credential Exposure

16 Security Control Review

17 Privilege Paths

18 Findings

19 Risk Ratings

20 Remediation

21 Retest

22 Cleanup

Executive Summary Example

The Windows privilege escalation
assessment identified weaknesses in local
access control that could allow a
compromised standard user to influence
operations executed with elevated
privileges.

The most significant findings involved
privileged services, scheduled tasks,
filesystem permissions, and administrative
access relationships.

The remediation priority is to ensure
that low-privileged identities cannot
modify resources consumed by SYSTEM,
administrative users, or privileged
services.

Windows Privilege Escalation Finding Template

Finding ID:

Title:

Affected Host:

Starting Identity:

Affected Resource:

Privileged Context:

Description:

Privilege Path:

Evidence:

Required Conditions:

Impact:

Likelihood:

Severity:

Root Cause:

Recommendation:

Retest Procedure:

Privilege Path Worksheet

Path ID:

Starting Identity:

Group Membership:

Token Privileges:

Initial Permission:

Affected Resource:

Privileged Consumer:

Execution Identity:

Required Conditions:

Potential Privilege:

Evidence:

Root Cause:

Recommended Path Break:

Student Deliverables

Complete:

Windows Privilege Escalation Checklist

Identity

Users and Groups

Token Privileges

whoami /priv
Sensitive privileges documented
Business requirement reviewed
Privilege state understood

UAC

UAC concept understood
Configuration reviewed
No unnecessary changes made

Services

Scheduled Tasks

Filesystem

Application directories reviewed
Writable privileged files identified
Writable privileged directories identified
Ownership reviewed
ACLs documented

Registry

Application keys reviewed
Service keys reviewed
Writable sensitive keys identified
ACLs documented

Applications

Custom applications identified
Configuration reviewed
Service dependencies reviewed
Administrative functions reviewed

Credentials

Network

Listening services reviewed
Ports mapped to processes
Local-only applications identified
Shares reviewed

Security Controls

Defender state reviewed
Firewall state reviewed
Audit policy reviewed
Security controls left enabled

Validation

40 Windows Privilege Escalation Interview Questions

What is Windows privilege escalation?
What is vertical privilege escalation?
What is horizontal privilege escalation?
What is an access token?
What information is stored in an access token?
What is an integrity level?
What is UAC?
Does UAC replace least privilege?
What does whoami /priv show?
Why are token privileges security-sensitive?
What is LocalSystem?
What is LocalService?
What is NetworkService?
Why are Windows services important during privilege assessment?
What should you inspect in service configuration?
Why is a writable service executable dangerous?
Why is a writable service directory dangerous?
Why are scheduled tasks security-sensitive?
What should you review in a scheduled task?
Why are writable SYSTEM task scripts dangerous?
What are NTFS ACLs?
What is the difference between Modify and Full Control?
Why should custom application directories be reviewed?
Why can writable registry keys create security risk?
What role does the Registry play in Windows configuration?
Why should environment variables be reviewed?
Why can PATH configuration matter?
Why are plaintext credentials dangerous?
What can PowerShell history expose?
What does cmdkey /list provide?
Why is local administrator membership important?
What is privilege creep?
What is Windows LAPS?
What is a gMSA?
Why should privileged service accounts have minimal rights?
Why should EDR or Defender not be disabled during a standard assessment?
Why is automated enumeration not a replacement for manual analysis?
What is controlled privilege validation?
Why should original files and hashes be captured before validation?
How do you verify that remediation actually broke the privilege path?

Final Windows Privilege Escalation Mental Model

Remember:

LOW-PRIVILEGE SESSION
        ↓
CURRENT IDENTITY
        ↓
GROUPS
        ↓
ACCESS TOKEN
        ↓
USER RIGHTS
        ↓
LOCAL ADMINISTRATION
        ↓
UAC
        ↓
SERVICES
        ↓
SCHEDULED TASKS
        ↓
FILESYSTEM
        ↓
REGISTRY
        ↓
APPLICATIONS
        ↓
CREDENTIALS
        ↓
ENVIRONMENT
        ↓
SECURITY CONTROLS
        ↓
CORRELATE
        ↓
BUILD PRIVILEGE PATH
        ↓
CONTROLLED VALIDATION
        ↓
ROOT CAUSE
        ↓
REMEDIATION
        ↓
RETEST

Do not think only:

How Do I Become SYSTEM?

Think:

Which Resource Can
My Current Identity Control
That Is Trusted by
a More Privileged Identity?

For example:

STANDARD USER
       ↓
SUPPORT GROUP
       ↓
MODIFY PERMISSION
       ↓
PRIVILEGED SCRIPT
       ↓
SYSTEM TASK

or:

STANDARD USER
       ↓
WRITABLE APPLICATION FILE
       ↓
PRIVILEGED SERVICE
       ↓
SYSTEM CONTEXT

The most important lesson is:

Windows Privilege Escalation
Is Often a Trust and
Permission Problem

A strong penetration tester should be able to explain:

WHERE THE PATH STARTS

WHICH PERMISSION ENABLES IT

WHICH PRIVILEGED COMPONENT
TRUSTS THE RESOURCE

WHY THE SECURITY BOUNDARY FAILS

WHAT SECURITY IMPACT EXISTS

HOW TO BREAK THE PATH

What’s Next?

➡️ Lab 05 — Web Application Privilege Escalation

In the next lab, you will move from operating-system privilege escalation to application-level privilege and authorization testing.

The workflow will cover:

LOW-PRIVILEGE USER
       ↓
APPLICATION MAPPING
       ↓
AUTHENTICATION
       ↓
ROLES
       ↓
OBJECT OWNERSHIP
       ↓
SERVER-SIDE AUTHORIZATION
       ↓
ADMINISTRATIVE FUNCTIONS
       ↓
API ACCESS CONTROL
       ↓
SESSION CONTEXT
       ↓
PRIVILEGE BOUNDARY
       ↓
CONTROLLED VALIDATION
       ↓
ROOT CAUSE
       ↓
REMEDIATION

The main objective will be to determine whether an ordinary application user can reach functions, data, or administrative capabilities beyond the permissions intended for that role.

Lab 04 — Windows Privilege Escalation

Mission Information

Mission Scenario

Lab Architecture

Learning Objectives

Prerequisites

Windows Privilege Escalation Mindset

Phase 01 — Confirm Authorization

Phase 02 — Create the Evidence Workspace

Evidence Standard

Phase 03 — Identify the Current User

Phase 04 — Record the Host

Phase 05 — Determine Domain Context

Phase 06 — Build the Starting Context

Phase 07 — Enumerate Local Users

Phase 08 — Enumerate Local Groups

Phase 09 — Review Current Group Membership

Phase 10 — Review Local Administrators

Phase 11 — Understand Windows Tokens

Phase 12 — Review Token Privileges

Phase 13 — Review Integrity Level

Phase 14 — Understand UAC

Phase 15 — Check UAC Configuration

Phase 16 — Enumerate Running Processes

Phase 17 — Enumerate Services

Phase 18 — Prioritize Privileged Services

Phase 19 — Inspect Service Configuration

Phase 20 — Inspect Service Executable Permissions

Phase 21 — Understand the Service Permission Relationship

Phase 22 — Review Custom Services First

Phase 23 — Inspect Service Directories

Phase 24 — Review Service Configuration Files

Phase 25 — Service Finding Example

Phase 26 — Review Scheduled Tasks

Phase 27 — Inspect an Interesting Task

Phase 28 — Understand Scheduled Task Privilege

Phase 29 — Inspect Task Action Files

Phase 30 — Capture Original State

Phase 31 — Review Filesystem Permissions

Phase 32 — Use Access Control Lists

Phase 33 — File Permission Mental Model

Phase 34 — Review Writable Application Directories

Phase 35 — Review Registry Security

Phase 36 — Inspect Registry Keys

Phase 37 — Registry Privilege Relationship

Phase 38 — Review Startup Locations

Phase 39 — Environment Variables

Phase 40 — Inspect PATH

Phase 41 — Review Temporary Locations

Phase 42 — Review Installed Applications

Phase 43 — Review Application Configuration

Phase 44 — Credential Exposure

Phase 45 — Review PowerShell History

Phase 46 — Review User Profile

Phase 47 — Review Saved Windows Credentials

Phase 48 — Review Network Connections

Phase 49 — Map Ports to Processes

Phase 50 — Review Local Shares

Phase 51 — Review Share and NTFS Permissions

Phase 52 — Understand Windows Service Accounts

Phase 53 — Service Account Governance

Phase 54 — Review Token Privilege Relationships

Phase 55 — Review Windows Security Controls

Phase 56 — Do Not Disable Security Controls

Phase 57 — Review Firewall Profiles

Phase 58 — Review Audit Configuration

Phase 59 — Manual Enumeration First

Phase 60 — Automated Enumeration as Cross-Check

Phase 61 — Build the Windows Privilege Matrix

Phase 62 — Build the Privilege Graph

Phase 63 — Identify the Root Cause

Phase 64 — Controlled Validation

Phase 65 — Safe Validation Pattern

Phase 66 — Confirm the Privilege Boundary

Phase 67 — Finding WPE-001

Phase 68 — Finding WPE-002

Phase 69 — Finding WPE-003

Phase 70 — Finding WPE-004

Phase 71 — Finding WPE-005

Phase 72 — Build the Risk Matrix