EternalBlue Series Part 7: Before the exploitation - Studying exploitation concepts

5. Preparing the exploitation.

Welcome! We almost have all the ingredients for the exploit to start:

• We know how to overflow the NT buffer in the heap.
• We know how to choose the address on which the overflowing buffer is placed on the heap.

It is almost time to exploit the system, and to do that what we need is to overflow the buffer in such a way that we overwrite some critical data which somehow leads us to execute code. We will be combining all the concepts we saw earlier in order to achieve this.

Buf before seeing the actual exploit in action, we need to introduce some final concepts to understand it in its completeness:

5.1 Concept 1 - The HAL’s Heap

One of the first modules loaded when Windows boots up is the Windows Hardware Abstraction Layer (HAL) contained in the module HAL.dll. This module runs in kernel mode and helps Windows to interact with different hardware architectures by calling the exported functions in HAL.dll. HAL needs, as many other processes, a stack and a heap.

The HAL’s Heap is particularly interesting because, differently from the heap of the usual processes, the address at which the HAL’s heap starts is constant, always. Usually, Windows implements what is called Address Space Layout Randomization (ASLR) which in essence consists on randomizing the addresses of functions, stack and heap in an attempt to prevent memory-based corruption attacks (like stack smashing), but in the case of the HAL’s heap the address has been kept always constant (until some Windows 10 update, when unfortunately the address of the HAL’s heap was randomized too).

The peculiarities of the HAL’s heap have turned out to be very useful for any exploitation which happens at the kernel (such as EternalBlue!) because many times the attacker can manage to redirect the execution to the address of the heap (which again, is known as it is always the same) where the malicious payload will be placed beforehand. Also, prior to Windows 8, the HAL’s heap has execution permissions, so we can also use that for our advantage and speed up the process.

In Windows 32-bit (and therefore in our Windows XP machine) the HAL’s heap is at address 0xffd00000, whilst in Windows 64-bit the heap starts at 0xffffffffffd00000.

---

5.2 Concept 2 - MDLs

A Memory Descriptor List is a kernel structure that defines a buffer by a set of physical addresses. Sometimes, large buffers are needed for I/O operations, and although they can spread over a large contiguous section of virtual addresses, it must be partitioned into sets of physical addresses. In these cases, MDLs are used, consisting of a MDL struct which contains an array of data describing the physical addresses to which the buffer is placed.

As one may realize, if we manage to access the MDL of a buffer and overwrite it, we can effectively choose where and what is contained in the buffer.

---

5.3 Concept 3 - SMB buffers

When opening a new connection, SMB will allocate some memory in the heap to store a buffer in which to contain the data being sent by the client. As we mentioned when explaining the concept of transactions, a primary transaction is sent followed by other secondary transactions, but only when the final transaction arrives it is when the server actually processes the data being sent. The place to store that data is in the heap too, but it is not stored in a vanilla buffer, but it actually contains some headers and additional data.

Let’s examine the typical SMB buffer (also called srvnet buffers, since SMB is managed by the srvnet.sys driver module).

As we can see in the figure, a srvnet buffer is in fact a struct srvnet_buffer with three main components:

• A srvnet_wsk_struct, which at the same time contains a function_table pointer, which is a handler function. This handler function is called by the server inside the function SrvNetWskReceiveComplete when the connection is stopped (Same function as the one mentioned at the eternalblue metasploit module which was said to unleash the exploit!).
• An MDL, which points to the physical address in which the buffer is being stored.
• The buffer with the data itself.

Could it be possible to overwrite the handler function so that a function we want is executed when closing the SMB connection? Could we modify the MDL so that what we are sending in the transactions is stored at the location we want? The answer to both questions is yes.

---

5.4 Concept 4 - DoublePulsar

We are almost ready to see how the exploit works, but before that we need to decide what is going to be our payload, what we will execute at the remote machine. As we introduced at the beginning of this research, we are using the exploit EternalBlue+DoublePulsar, but DoublePulsar is not an exploit, but rather a backdoor utility which the NSA used to incorporate to the attacks they performed with EternalBlue. We are explaining the exploit and not the malware itself, but still it is always important to know what is our payload.

DoublePulsar is a very sophisticated multi-architecture payload which resides in the RAM memory of the target system (a reboot removes it) and which runs in kernel mode (full privilege). It opens a backdoor in the infected machine, and by reusing the SMB port lets an attacker load more malware and execute shellcode remotely. Essentially, once we manage to execute the DoublePulsar code in the victim machine through the EternalBlue exploit, we will achieve full control of it.

---

And that is all! We have finally covered all the concepts needed for you to fully understand what is coming in the next part. I’m sorry it took so long but at the same time I promise you it will be worth it.

Without further ado, see you on the final part of this series.

This work is licensed under a Creative Commons Attribution 4.0 International License.