How privilege escalation exploits work in Windows

For future students of the course “Pentest. Practice of Penetration Testing” prepared an author’s article from our expert – Alexander Kolesnikov.

We also invite you to sign up for an open webinar on the topic “Windows ad: information gathering, escalation of privileges. Exploits and vulnerabilities of the last 5 years.”

---

The topic of getting unlimited access to the system is very interesting in the context of penetration testing. Accessing the system and launching the team is only half the battle today. The second half is reached only when it is possible to bypass the sandbox subsystems and limitations that are in the operating system.

This article will discuss some of the features of privilege escalation exploits in the Windows operating system.

Privileges in Windows

To understand how privilege escalation works, you need to understand the access control in the Windows operating system. A description of the access control system can be found on the official website… According to the documentation, access control in Windows is based on the following concepts:

• Users

• Groups

Each of the listed objects has its own individual SID. In general, this identifier is used to designate any object with which the operating system works, and it requires access control, but we are primarily interested in using this identifier in the context of users, groups and their rights. The identifier is used to create for the user access token… This token contains information about what rights the user has and the groups he belongs to. The token will be used to confirm or prohibit actions on objects of the operating system, called “Securable Objects”. Access tokens are:

• Primary token – the token that the user gives to the process when the application starts.

• Impersonation token – a token that can work on behalf of any user of the operating system. It can also be used for client-server communication or to start a process thread with different privileges.

From here it becomes clear that the main purpose of any escalation of privileges is to obtain an access token that is created by privileged users. In general, in Windows OS these are standard users called: “Administrator” and “System”. It is their tokens that open the doors to any information that is in the operating system.

From the official documentation, the token consists of separate objects:

The structure is quite complex and it won’t be possible to copy or modify it just like that due to the fact that the token is stored in a place protected from modification (as stated in the documentation). Let’s find out where she is. To do this, start the Windows operating system in debug mode and examine all the structures that are used to run the process. If you go back to the official documentationthen it’s worth starting with the EPROCESS structure.

It turns out that information about the process token is stored in the kernel and therefore in the documentation this is marked as an area that cannot be changed. In theory, this is true: ordinary applications that run in the 3rd ring cannot modify what is stored in the 0th. But if we modify the structure inside the core from the core, then there are no restrictions and contradictions. Let’s turn to the debugger:

The address of the EPROCESS structure is highlighted in bold; in order to study it in more detail, we will call the debugger command:

It seems that you won’t have to search for a long time, the token is found literally right away. On 64-bit operating systems, it is referenced at offset 0x208. To read it, you need to mask the address:

This is the address that needs to be masked completely, except for the last byte:

Above the address of the token, you need to call the command of the same name and we can make sure that indeed, as indicated in the documentation, the token contains the information that was declared:

It can be seen from the figure that all the privileges that the token contains are located in the form of a bit mask and have names that begin with the “Se” prefix. It is these fields that we need to modify so that the operating system allows the process to read anything in the operating system. With the goal in mind, it’s time to talk about privilege-set attacks, vulnerabilities, and exports to them.

LPE or what to do with the token

Changing privileges in a token can be a very trivial task, despite the fact that these very privileges are very complexly structured. The main attack used to escalate privileges is to overwrite the reference to the token contained in the structure EPROCESS… In other words, the token does not change, the address where the token is located changes. Typically, this address is chosen from a system process that may be permanently present in the operating system. The result of such an operation is a process or a separate thread that can do anything in the OS. Below is an example of code that allows you to steal a token:

[BITS 64]
 
start:
    mov rdx, [gs:188h]      ;get _ETHREAD указатель из KPCR
    mov r8, [rdx+70h]       ;_EPROCESS
    mov r9, [r8+188h]       ;ActiveProcessLinks начало списка
 
    mov rcx, [r9]           ;найти первый процесс в списке
find_system_proc:
    mov rdx, [rcx-8]        ;смещение от ActiveProcessLinks до UniqueProcessId
    cmp rdx, 4              ;System процесс
    jz found_it
    mov rcx, [rcx]          ;переходим по _LIST_ENTRY Flink указателю
    cmp rcx, r9            
    jnz find_system_proc
 
found_it:
    mov rax, [rcx+80h]      ;смещение ActiveProcessLinks до токена
    and al, 0f0h            ;очищаем 4 бита _EX_FAST_REF структуры
    mov [r8+208h], rax      ;заменить токен текущего процесса системным
    ret

The above code allows you to copy the token for the current process from the system process ID 4. It is worth noting that the code must be run in the context of the operating system kernel. This means that it must either be executed by the driver or by a shellcode that will be loaded into memory through an operating system vulnerability.

Vulnerabilities and exploits

The Windows operating system, like any other complex system, has millions of lines of code. And, as in any large project, its size does not allow excluding mistakes and shortcomings. The picture below shows the statistics of vulnerabilities found in the OS for the last 5 years. It includes privilege escalation vulnerabilities:

Vulnerability data taken from here… Statistics show that there are enough vulnerabilities to find the one you need to escalate privileges. We will use ready-made exploits for research. Let’s try to restore the sequence of actions that are carried out to achieve the goal of escalating privileges. The list of vulnerabilities will be as follows:

• CVE-2015-2546

• CVE-2016-3309

• CVE-2017-0101

• CVE-2018-8120

• CVE-2019-1458

• CVE-2020-0796

CVE-2015-2546

Vulnerability in Win32k operating system module, memory corruption. Fragment of the exploit responsible for changing the process token:

This seems to be the same code that was presented above. It changes the approach to finding a token, but the basic idea is the same – to get a reference to a token from a process with PID = 4 (System.exe).

CVE-2016-3309

Vulnerability in Win32k, again a memory corruption problem, take a look at the piece of code that is used to replace the token:

In this case, the author used the C programming language, the part of the token address search was also changed, but again the token replacement technique is to rewrite the address from the system process.

CVE-017-0101

Vulnerability in user32 GDI objects and again memory corruption. Token replacement code:

The code was copied from a 2016 exploit, it seems that primitives for escalating privileges have not yet been mitigated in Windows at this time.

CVE-2018-8120

Vulnerability in Win32k component, this time nullpointer is incorrectly handled, token replacement code:

The exploit author is clearly in no hurry to use something different or at least new. Again the code that is looking for System.exe and uses its token.

CVE-2019-1458

Vulnerability in Win32k, memory corruption, token replacement code:

Here are the first changes, the author could no longer use the code that had been helping him for 3 years. Now the token is replaced through the primitives that were used to exploit vulnerabilities in Windows 10 – the Bitmap method. Mechanically, it does the same thing, but it achieves this by using objects from the Win32k subsystem.

CVE-2020-0796

Vulnerability in a driver that handles SMBv3 requests. The problem lurked in an overflow of an integer type, which was responsible for the amount of memory allocated in the kernel. Token replacement code:

This vulnerability is a special case. First of all, because the replacement and rewriting of the token is carried out in 1 pass when receiving an incorrectly formatted request via SMBv3, therefore, no additional calculations and actions with respect to the token take place in the source System.exe and user process.

Instead of a conclusion

In penetration testing, it is often necessary to use one or another public exploit to escalate privileges. However, it is not always possible to find a detailed description of the exploit and bring it into a usable state. Hopefully, this article helped you see the patterns that are used to write exploits, and now it will become a little easier to understand them. In addition, as the description above shows, there are not so many ways to escalate privileges, namely one – changing the reference to the process token. Everything else is just a modification of the way the link can be overwritten.

---

Learn more about the course “Pentest. Practice of Penetration Testing”.

Sign up for an open webinar on the topic “Windows ad: information gathering, escalation of privileges. Exploits and vulnerabilities of the last 5 years.”