Local Privilege Escalation
Escalate privileges on a local computer to become a more powerful user
After the Local Enumeration phase, you might have found some interesting things. This section explains how you exploit some findings to reach the Administrator on the current (local) computer.
Once this is successful, you should have enough permissions to do anything on the machine. The main goal is often using Post-Exploitation: Mimikatz to read cached credentials from a memory dump of the LSASS.exe
process.
Credentials
Many times the enumeration efforts result in some new credentials being found. SeeSpray passwords for tools that can spray credentials over systems quickly, to find which computer or user they belong to.
You can also start a local process as another user from CMD/PowerShell using the runas
command. This will start a new window as that user after filling in the correct password:
The above only works in an RDP setting where you interactively type the password. For shells instead, you can use PowerShell to create a new process with your credentials:
Privileges
Windows uses 'privileges' to determine what you can and can't do. There are some uninteresting default privileges, but also some that give a lot of power. Check them with the whoami
command:
From these the SeShutdownPrivilege
is a little interesting, as it allows you to reboot the machine. Some exploits only trigger at the startup of a service for example, and a reboot can trigger this at will.
Local administrators will have all the permissions that exist, so they can do anything on the computer. Sometimes a middle ground is chosen to give low-privilege users some extra privilege, but this can backfire if they are powerful ones that can be abused.
SeImpersonatePrivilege
This privilege allows you to impersonate other users like nt authority\system
. This user can do anything, like dumping LSASS memory with Mimikatz. Exploits exist that abuse this to get a shell:
https://github.com/itm4n/PrintSpoofer/releases/download/v1.0/PrintSpoofer64.exe
It's possible that this exploit above does not work, but some alternatives might work in these scenarios. First, there is GodPotato which you can download pre-compiled from the Releases, and execute:
Lastly, there is also SharpEfsPotato which needs to be compiled by hand using Visual Studio:
Other Se...Privilege
'Disabled' privileges
In rare cases, privileges might be Disabled which doesn't let you abuse them. Luckily for the attacker, this is only a setting that you can easily Enable for any privilege. The EnableAllTokenPrivs.ps1 script can be used to enable all these privileges:
UAC Bypass
Using whoami /groups
you can find if your user is in the BUILTIN\Administrators
group, and if they are, you should be able to reach the Mandatory Label\High
, which might be at Mandatory Label\Medium
right now.
An Administrator should be able to start a Mandatory Label\High
process, but this usually involves a user pressing "Yes" on a GUI prompt, this is the User Account Control (UAC) at work.
This feature is however bypassable without a GUI using AutoElevate programs. To check if a binary has the AutoElevate property, we can use sigcheck:
Many different built-in programs have this property set, but not all are secure. Microsoft seems to not classify UAC bypasses as an issue, so this repository collects dozens of working methods:
To build the tool, open the Source folder in Visual Studio. This should open the "Akagi" project which you can build in Release mode for x64 architecture:
When building is done, you should find the compiled binary in "Source\Akagi\output\x64\Release\Akagi64.exe".
This can now be executed on the target by choosing a technique, and a program to start in a new window with the elevated privileges:
DLL Hijacking
Programs in Windows have assembled code that they execute, but also often load libraries and call their code to prevent having every program include some basic functionality. Which libraries to load can be completely decided by the program, and they can even make their own custom libraries (DLLs). When the program is started, directories are searched for the library names in the following order:
Directory containing the
.exe
that startedC:\Windows\System32
C:\Windows\System
C:\Windows
Current working directory
Any directories in the system
$env:path
environment variableAny directories in the user
$env:path
environment variable
While 2-5 are often pretty locked, the 6 and 7 variables might contain some interesting directories that you may write in. Check their paths in PowerShell like so:
Perhaps the most interesting of all of these is 1, the directory containing the executable. If we as the attacker can write in this directory, and the executable is run in a higher-privileged context, we can overwrite an existing DLL to run whatever we want. Check permissions using icacls
or just try writing there with a simple echo a > a
.
When having confirmed that a writable searched directory exists, we need to find what DLLs are loaded by the executable. A very unscientific way of doing this is simply searching for .dll
names in the program binary after transferring it over to your Linux machine:
Any of these will probably work, but MyLibrary.dll
seems custom and most likely, so we'll focus on that. To find out what libraries are actually loaded we can dynamically analyze it by running it locally and attaching Process Monitor, then looking for CreateFile events with .dll
extensions:
Now that we have found a potential place and name for a DLL that we can overwrite, we have to create a malicious DLL that runs what we want, like a reverse shell also stored on the system. We just need to define the special DllMain()
function and handle the different cases:
Then we can compile this code locally from a Linux machine by using the mingw
compiler, to create a .dll
shared library. This can be moved over to the vulnerable location on the target.
Post-Exploitation: Mimikatz
When having taken over a computer to full Administrator privileges, and the High
Integrity Level, tools like mimikatz.exe
can use these privileges to do a lot of nasty stuff. The tool is a big collection of commands that should be run on the target itself as an executable. Its most common use case is extracting in-memory credentials from the computer to use in further attacks, like cracking or passing them.
Some commands require privilege::debug
or even token::elevate
to be run before, to activate the required privileges. Make sure to try these first when you encounter errors.
The sekurlsa::logonpasswords
, lsadump::lsa
and lsadump::sam
commands go hand-in-hand, finding different plaintext credentials, NTLM hashes, or Kerberos tickets from logged-on users in memory for the first, and by asking the LSA server for the latter. These are incredibly useful for starting Lateral Movement.
sekurlsa::tickets
is another such tool that finds active Kerberos tickets to export and import.
The sekurlsa::pth
command stands for "Pass The Hash", allowing you to spawn a process as another user only knowing their NTLM hash.
Remote alternatives
There are some tools that run the techniques Mimikatz uses from a remote perspective, which may be quicker to use. Here are a few of them:
Remotely dump all kinds of secrets on the target computer, from NTLM hashes to SAM and LSA. While this finds and dumps a lot, it won't find everything (read more in this article).
LaZagne
Last updated