Privilege Escalation is the process of obtaining higher permissions than those initially granted.
In many cases, compromising a system does not immediately provide administrative access. Instead, operators often begin with a low-privileged user account and must identify a weakness that allows them to elevate their privileges.
For example:
User
↓
Administrator
↓
SYSTEM
A useful way to think about Privilege Escalation is that it is simply a special form of exploitation in which the objective is increased permissions.
In our previous example, the low-privileged user was able to overwrite a DLL that was subsequently loaded by a service running with higher privileges. As a result, the attacker's code would execute within the security context of that service, effectively elevating the attacker's privileges.
Common privilege escalation vectors include:
- Weak file permissions
- Weak service permissions
- Vulnerable software
- Misconfigurations
- Credential exposure
- Scheduled tasks
- Kernel vulnerabilities
- Incorrect trust relationships
Privilege Escalation Example
You may have already realized we are going to build upon the last example from "Exploitation".
We left off with a binary on which we successfully established control.
As you can see, even as an unprivileged user I still have enough rights to at least query the service and find out it is running as "LocalSystem". Notice that I am not currently in the Administrators group. This distinction is important. Exploitation and Privilege Escalation are often closely related, but they are not the same thing. In the previous section we established code execution. In this section we are leveraging that code execution to obtain higher permissions.
Obviously, jacking the log file does not provide much value beyond proving control. Since our code is now executing within the context of a service running as LocalSystem, we effectively control a LocalSystem process.
For demonstration purposes, I modified the payload to add my low-privileged user to the local Administrators group:
#include <cstdlib>
extern "C" __declspec(dllexport)
void LibraryFunction()
{
system("net localgroup Administrators lowpriv /add");
}
You're not really constrained to doing the same - at this point you have SYSTEM-level access and any command/binary/script you execute will inherit those privileges. This is just for demonstration's sake.
Once the substitution was complete, all that is left was to acquire a new token with the new privileges. We will explore Windows access tokens in much greater depth later in the course. For now, it is sufficient to understand that Windows assigns an access token when a user authenticates. That token contains information about the user's identity, group memberships and privileges. Existing processes continue using their current token, so after being added to the Administrators group I needed to start a new logon session in order to receive a token containing the new membership.
To simulate a new session with a user (with known credentials), you can use:
runas.exe /user:lowpriv powershell.exe
<on password prompt> lowpriv
