Challenge the Keemaker! How to bypass antiviruses and inject shellcode into KeePass memory

This paper discusses D/Invoke, a wonderful third-party mechanism for C#. D/Invoke makes it possible to interact with the Windows API bypassing the antivirus protection. As a bonus, you will learn how to rewrite KeeThief so that it becomes undetectable by the great and terrible Kaspersky AV.

Background

Imagine my situation: I’m already inside, the admin domain has been captured and raized, but the stubborn KeePass database doesn’t want to be brute-forced with hashcat and keepass2john.py. As you are likely aware, KeePass contains info required to access critical infrastructure resources that determine the outcome of my attack; so, I must crack it. The workstation running this database is monitored by Kaspersky Endpoint Security (KES). And the question is: how can I get the much-desired master password without using social engineering?

First of all, I must admit that the cornerstone of my success was cool malware called KeeThief from the GhostPack collection; its authors are the notorious @harmj0y and @tifkin_. The core of this program is a custom shellcode that calls RtlDecryptMemory to decrypt the encrypted virtual memory area in KeePass.exe and extract the master password from there. But if there’s a shellcode, you also need a loader for it, which becomes a problem if the host is monitored by EDR…

So, what are my options?

Disable AV

The simplest (and most stupid) way is to disable Kaspersky AV for a few seconds. “This isn’t a red team engagement; so, I can do this!” – I decided. Since I have domain administrator privileges, I also have access to the KES administration server and the KlScSvc account (in that case, a local account was used) whose credits are stored in plain text among other LSA secrets.

My plan is simple. First, I dump LSA with secretsdump.py.

Then I download the KES Administration Console from the official website, specify KSC as the hostname, and log in.

Then I pause Kaspersky AV and do my dirty job.

Success! I have the master password. But after finishing the project, I decided to explore other ways to solve this problem.

C2 session

Many C2 frameworks can bring along a CLR (Common Language Runtime) DLL and inject it reflectively in accordance with the RDI (Reflective DLL Injection) principle to run malware from the memory. In theory, this can affect the detection of the managed code executed using such a trick.

If Kaspersky Antivirus is active, it’s extremely difficult to get a fully functional Meterpreter session due to numerous artifacts in the network traffic. Therefore, I don’t even try its execute-assembly module. By contrast, the Cobalt Strike execute-assembly module brings the desired results – provided that the beacon session was established correctly (all subsequent screenshots were taken on a PC running KIS (the home edition of KES), but the techniques described below are effective against KES as well).

However, this method is far from perfection, too. To smoothly get a beacon session, you need an external server with a valid certificate to encrypt SSL traffic. Infecting the target PC from the customer’s internal perimeter is a mauvais ton.

Redesigning tools

The most exciting (and concurrently labor-consuming) way is to rewrite the shellcode injection logic so that EDR cannot detect it at the time of execution. This is how I am going to do this, but first, some theory is required.

Note

The point is to evade heuristic analysis. If you hide the malware signature using an undetectable packer, access to memory will still be denied due to the injection failure.

Classical shellcode injection

Let’s examine the classical technique used to inject third-party code into a remote process. For this purpose, our ancestors used the ‘sacred’ trio of Win32 APIs:

• VirtualAllocEx – allocate space in virtual memory of the remote process for your shellcode;
• WriteProcessMemory – write shellcode bytes to the allocated memory area; and 
• CreateRemoteThread – run a new thread in the remote process that starts the newly-written shellcode.

Let’s write a simple PoC in C# to demonstrate the classical shellcode injection procedure.

I compile and run the injector. Using Process Hacker, I can see how a new thread starts in the explorer.exe process and opens an MSF dialog box.

If you simply put such a binary on a disk with enabled antivirus protection, its reaction will be instantaneous regardless of the buf array contents (i.e. your shellcode). This is because it contains a combination of potentially dangerous Win32 API calls that are used in numerous malicious programs. For demonstration purposes, I recompile the injector with an empty buf array and upload the result to VirusTotal. Its reaction speaks for itself.

How does antivirus software detect an injector, even without dynamic analysis? In fact, very simply: a bunch of DllImport attributes representing half of the source code clearly indicate the danger. Using this magical PowerShell code, I can view, for instance, all imports in the .NET binary.

As you understand, dynamic analysis of this stuff is even simpler: since all EDRs have a habit of hooking userland interfaces, calls to suspicious APIs will immediately raise alarms. See the research by @ShitSecure for more information; in the laboratory environment, hooking can be effectively demonstrated using the API Monitor.

So, what can I do in this situation?

Introduction to D/Invoke

In 2020, researchers @TheWover and @FuzzySecurity introduced a new API for invoking unmanaged code from .NET: D/Invoke (Dynamic Invocation, similar to P/Invoke). This method uses a powerful delegates-based mechanism in C#. Initially, it was available as part of SharpSploit, a framework used to develop post-exploitation tools, but later migrated to a separate repository and even appeared as a ready-made package on NuGet.

Using delegates, a developer can declare a reference to a function that has to be called with all its parameters and type of return value (similar to imports using the DllImport attribute). The difference is as follows: when you import functions using DllImport, the runtime searches for addresses of the imported functions; while when you use delegates, you have to localize the unmanaged code you need (dynamically, during the program execution) and associate it with the declared pointer. After that, you can access the pointer as the required function without having to ‘shout’ that you are going to use it.

D/Invoke allows to dynamically import unmanaged code in different ways, including:

1. DynamicAPIInvoke – parses the DLL structure (either loads it from disk or accesses an instance already loaded to the memory of the current process) containing the required function and computes its export address; or 
2. GetSyscallStub – loads the ntdll.dll library to memory and parses its structure in the same way to get a pointer to the export address of the system call that, in fact, acts as the last frontier before entering the land of the dead kernel mode (system calls will be addressed in more detail a bit later).

For better understanding, let’s start with a simple example: it’s similar to the first approach, but doesn’t use D/Invoke.

DynamicAPIInvoke without D/Invoke

I like an example provided in the article by xpn (the second code listing in the section “A Quick History Lesson”): the author uses less than 50 strings to demonstrate the full power of delegates combined with a manual search of the export address of an unmanaged function.

I rename the StartShellcodeViaDelegate function into Main, add the required structures (signatures are taken from pinvoke.net), and get another PoC demonstrating dynamic shellcode injection.

For simplicity purposes, the above example uses the so-called self-injection: you don’t target a remote process, but write the shellcode into the virtual memory of the injector process (by the way, this is another effective AV bypass tactics).

Now I am going to use my impromptu static analysis script to check for any suspicious imports.

No imports found, which is fine. But what will API Monitor say when the injector is launched?

No alarms. Let’s check the KIS reaction to this binary.

I didn’t even launch it… But I’m definitely moving in the right direction!

Bonus

In this particular case, Kaspersky AV detects hardcoded strings (e.g. "VirtualAlloc") and names of variables. If you obfuscate or encrypt them as I do here, EDR won’t notice anything suspicious.

However, if your injector has a more complex structure (e.g. a thread is launched in a remote process), heuristic analysis will detect it. Therefore, the above method isn’t suitable for this task.

DynamicAPIInvoke with D/Invoke

Let’s find out how to perform an injection into a remote process using D/Invoke and DynamicAPIInvoke. For this purpose, I create a new Visual Studio project and separately clone the D/Invoke repository. For ‘combat’ operations, I don’t want to use a ready-made NuGet package – instead, I will include D/Invoke source code in my project to avoid potential IOCs and the need to merge the assemblies together.

The result should look like shown below.

The PoC is as follows:

Let’s briefly discuss what happened. The WriteProcessMemory API call will be used as an example. In case of a static P/Invoke import, this API was used as follows:

To use DynamicAPIInvoke from D/Invoke, I create a wrapper function called WriteProcessMemory; it takes the same arguments as specified in the delegate’s signature and passes the control to the D/Invoke logic.

This operation was performed to simplify the use of the target function: the syntax used to call WriteProcessMemory remains the same in both cases:

Important: if you decide to use the D/Invoke project, note that under no circumstance your binary cannot be copied to the disk (this would trigger alerts). But this isn’t critical since you are dealing with C# and can always load the bytes of the assembled injector directly into the memory using System.Reflection.Assembly (remember that, similar to the Main function, the class containing the program entry point must be declared as public).

Too bad, Kaspersky detects such a behavior during the execution. I was prepared for this, so let’s move on to the heavy artillery: system calls in D/Invoke.

Why system calls?

So, what are system calls in the context of this topic and how can they help?

Windows has two API types: Win32 API and Native API.

1. Win32 API (kernel32.dll, user32.dll, advapi32.dll etc.) – a well-documented and comprehensible API that remains intact for years to avoid breaking the existent programs and forcing developers to reinvent the wheel when they have to implement basic things. Roughly speaking, functions used in the Win32 API are wrapper functions that internally communicate with the Native API (similar to the DynamicAPIInvoke example above); and 
2. Native API (ntdll.dll) – an undocumented and incomprehensible API whose implementation may vary in different versions of Windows. Native API functions are, in turn, wrappers for system calls.

For us, attackers pentesters, it’s imperative to take advantage of every OS feature because at the beginning of a project we always start in an uncharted area and know nothing about the target PC aside from its listed features. While the defenders are equipped with multimillion-dollar SIEMs and EDRs, we only have a bunch of hand-made scripts from GitHub and the friendly community (and licensed Cobalt, of course).

This means that in some situations, it’s preferable to use the Native API, not the Win32 API, to stay as close to the kernel mode (Ring 0) as possible because the AV/EDR laws – so effective in the user mode (Ring 3) – aren’t applicable there.

As you understand, the above exercises with DllImport (P/Invoke) and DynamicAPIInvoke (D/Invoke) are nothing more than attempts to use the Win32 API. Let’s try to perform the same operations with system calls.

GetSyscallStub with D/Invoke

Generally speaking, Native API functions represent the last frontier before entering the kernel mode. They live in the ntdll.dll library, and one of the ways to reach them without being detected is to parse the PE structure of this library and get addresses of the required exports. And D/Invoke will assist in this.

Let’s examine the code below.

In this PoC, all functions involved in the shellcode injection have been replaced by Native API calls, namely

• OpenProcess → NtOpenProcess;
• VirtualAllocEx → NtAllocateVirtualMemory;
• WriteProcessMemory → NtWriteVirtualMemory;
• CreateRemoteThread → NtCreateThreadEx.

The first question that comes to mind is: how do I know that these Native API functions correspond to the above-mentioned Win32 API calls? Well, the most righteous way to find this out is to disassemble kernel32.dll yourself… But since I’m all fingers and thumbs (and don’t have IDA Pro), I took a different approach and reviewed the ReactOS source code whose authors have already stolen everything done this job.

For instance, the implementation of the CreateRemoteThread function directly hints at the NtCreateThread call, which, in turn, refers you to the NtCreateThreadEx signature.

So, let’s review again the differences between a static import in P/Invoke and a D/Invoke system call for the WriteProcessMemory function.

It used to be as follows:

Now it is:

Let’s execute this code.

It works! Now let’s try it with Kaspersky AV enabled.

$Voila!$ Your favorite antivirus keeps silence.

Modifying KeeThief

Now you possess knowledge required to rewrite the KeeThief logic for D/Invoke system calls. Instead of copying/pasting all the changes that I made, I will focus in this article on the function used to read the decrypted memory area containing the master password. The rest of the changes can be found on my GitHub.

Preparations

First, I fork the KeeThief and DInvoke projects. Next, I create a separate keethief branch in the DInvoke fork where I will get rid of all features that I don’t need, thus, reducing the amount of suspicious code.

Then I add modified DInvoke as a git submodule for KeeThief.

Now I can create the syscalls branch, open KeeTheft.sln in Visual Studio, and add the DInvoke folder to the project.

Upgrading the ReadProcessMemory function

In fact, only functions declared in Win32.cs are of interest for my purposes; so, let’s use the above-mentioned ReadProcessMemory function as an example (it’s called here).

Similar to the example described above, to use ReadProcessMemory in KeeThief, an ordinary P/Invoke import with DllImport is performed.

I am going to create separate classes Delegates.cs and Syscalls.cs for delegates and system call implementations, respectively. To localize the NtReadVirtualMemory function, I use the above-mentioned method taken from the ReactOS source code.

Now I have to make changes in the logic of the Main class Program.cs. Initially, it was as follows.

Here, the already decrypted memory area in the remote process is read after the shellcode execution. The ReadProcessMemory function was selected as an example on purpose: its porting requires plenty of fiddling with types of parameters passed.

Below is what I got.

As you can see, the main difference is that the Native API has no idea about .NET managed arrays; so, you have to alter the logic for work with unmanaged memory.

The rest of the Win32 API calls can be easily found in Program.cs using Ctrl-F; you have to perform for them the same operations as for ReadProcessMemory. The result is available in my fork.

Testing

I am going to compile the modified assembly and create a test KeeThief database with the password Passw0rd!. In my tests, I used the latest KeePass version available at the time of writing (2.50).

Loading the assembly to the memory and calling its entry point while the KeePass database is open.

Conclusions

Viruses have been employing system calls for a long time. In such situations, antivirus software detects malicious behavior by monitoring ntdll.dll parsing operations and launches of suspicious processes or threads that use potentially dangerous calls (e.g. NtCreateThreadEx, NtQueueApcThread, etc.).

Now you know how to bypass Kaspersky AV and compromise credentials in KeePass. As a homework, you can create an elegant download cradle to execute the program from memory in PowerShell in one click (hint: review a few articles about System.Reflection.Assembly). Good luck!