DLL Injection EDR Evasion 1: Hiding an elephant in the closet

Sometimes the best way to get into a process is to crash the party!

What do these statements have in common?

I forgot how much I hate C++.

This would be so much easier in Rust.

Why’s the linker so bad.

They were all said by a bad C++ programmer.

And, they were all said by me.

Intro

Project code: https://github.com/0xflux/GoSneak

Legal disclaimer applies, by reading on you acknowledge that, see the legal disclaimer here. In short, you must not use the below information for any criminal or unethical purposes, and it should only be used by security professionals, or for those interested in cyber security to deepen your knowledge.

I started this section by intending to ‘open source’ the DLL injector I have written for my red team framework, an injector written in C++, wrapped with Go, with a Go based DLL. I was going to talk about how CGO works, how you can do low level things in C++ and return out to your Go function, but instead this turned into a series of deeper learning of the windows internals and in turn, some upgrades to my injector. All of this is the prelude to my total rewrite in Rust. But more on that in another post.

Whilst there is still a wrapper for this loader in Go contained in the project, for now I am just working on the C++ implementation (mostly from scratch), based on some recent research I have done from other blogs and security content creators. At the end of the post, I’ll introduce the Go wrapper for the DLL injector, and show how it can be used as part of a Go binary.

With this basic iteration of the injector, we will be dealing with an unencrypted payload written to disk. This of course is far from the ideal way of executing some stealthy ops, but that may (will) come later :)

EDR Hooking

EDR Hooking refers to the methods used by Endpoint Detection and Response (EDR) systems to monitor the behavior of software on a computer, particularly for identifying and mitigating potential threats. These systems are designed to detect malicious activities by observing interactions between software processes and the operating system.

There are different ways in which EDR’s will perform hooking, a few of the more common:

Inline Hooking:

The EDR modifies the actual binary code of a function in memory. It typically replaces the first few bytes of the function with a jump to its own monitoring code. When the hooked function is called, execution is diverted to the EDR’s code first, allowing it to monitor or modify the behaviour of the function. Here is a great resource to read more about detecting inline hooking: https://www.ired.team/offensive-security/defense-evasion/detecting-hooked-syscall-functions.

Import Address Table (IAT) Hooking:

IAT hooking involves modifying a program’s import table, which lists the API functions used by the program. This means when the program runs, instead of calling the actual API function, it calls the EDR’s monitoring function.

Unrelated to the topic here of the loader, but taken from ired.team:

I haven’t yet had chance to try this, but this looks really cool, and I want to implement this into my red team framework as a capability.

Back to loaders……

Going down the syscall rabit hole

Now we know what EDR’s are looking for, lets come up with a plan. Well, actually, we dont need to come up with a plan as the security community already has this well documented. Since we know that EDR can hook API calls, researchers such as https://alice.climent-pommeret.red/posts/a-syscall-journey-in-the-windows-kernel/ (and many, many more) have documented the journey of API calls and how we can basically call syscalls and get data into the kernel, in such a way that bypasses EDR hooking.

I’ll provide an example of what this looks like, below are a series of screenshots from x64dbg, in which I find the main function of the program, then look for a VirtualAllocEx() call to the Windows API (which eventually resplves a EDR hooked function). You can see, by following the call operators, we move through kernel32.dll, into kernelbase.dll which gives us the call to NtAllocateVirtualMemory. Inspecting NtAllocateVirtualMemory (part of the undocumented Windows NTAPI), we see in the assembly 18h being moved into eax then making a syscall. 18h on my architecture and Windows version (as explained below) is the syscall number for the kernel performing the actions of NtAllocateVirtualMemory, showing that transition at the low level from user-land to kernel-land.

Here’s a visual representation of this:

Here’s examining the chain in a debugger:

Having followed the rabbit hole this deep, we are now left with the assembly making the syscall. On my particular version of windows (11, I know, it makes me as sick as you are reading that) - you can see the syscall number is 0x18. To learn about syscalls, go check out this excellent blog post: https://alice.climent-pommeret.red/posts/a-syscall-journey-in-the-windows-kernel/

We can then put this into our assembly file like so, remember to publicly export the procedure:

public NtAllocateVirtualMemory
NtAllocateVirtualMemory PROC
  mov r10, rcx
  mov eax, 18h
  syscall
  ret
NtAllocateVirtualMemory ENDP

Remember, assembly requires PROC and ENDP to section off that procedures code.

Then, we can repeat this process over and over until all hooked syscalls are resolved to the syscall number.

This is only half of the story, the next step is defining the undocumented NTAPI functions, and providing an abstraction of these. The best resource I have found for any documentation around the lower level APIs of Windows are from the wininsiders GitHub https://github.com/winsiderss/phnt. For example, searching that for NtVirtualAllocateMemory.

In combining (or linking) assembly with the C++ project, we create a new header file packed with function prototypes, tagging them with the extern “C” keyword.

This bit is crucial to make sure the C++ linker susses out and properly links these functions.

Here’s the thing with C++: function names get a bit of a twist, known as ‘name mangling’, rendering each name unique for the linker, especially key for stuff like function overloading. By flagging these functions with extern “C”, we’re telling the C++ compiler to stick to C-style linkage, thus dodging any name mangling bulls#*%. This guarantees that the function names we’ve defined in our assembly are the image of those the C++ linker is looking for, enabling a smooth integration. Take for example, we declare the prototype for NtAllocateVirtualMemory – an undocumented NTAPI function we found through the wininsiders GitHub – in our header file to ensure it’s in step with its assembly equivalent.

extern "C" {
    NTSTATUS NtAllocateVirtualMemory(
        _In_        HANDLE              ProcessHandle,
        _Inout_ _At_ (*BaseAddress, _Readable_bytes_(*RegionSize) _Writable_bytes_(*RegionSize) _Post_readable_byte_size_(*RegionSize)) PVOID *BaseAddress,
        _In_        ULONG_PTR           ZeroBits,
        _Inout_     PSIZE_T             RegionSize,
        _In_        ULONG               AllocationType,
        _In_        ULONG               Protect
    );
}

Assembly does not support name mangling, hence why extern “C” is important not to overlook.

Let’s quickly talk about why we’re defining these function prototypes.

Normally in C, we declare function prototypes to inform the compiler about the function’s signature - what arguments it takes and what it returns. This is crucial because it tells the compiler how to set up the call to the function, including how to arrange data in memory or in registers. The same logic applies here, but with a twist. We’re defining our functions in assembly, not C. This means that while the C++ part of our code knows what to expect thanks to the prototypes, the actual work – the nitty-gritty of the operations – is done in the assembly code. This becomes particularly important when dealing with system calls. System calls are like special requests to the kernel, and they expect data to be presented in a very specific way. By defining a function prototype in our C++ code, we ensure that when we call this function, the compiler arranges all the necessary data (arguments) in the way that our assembly code – and in turn, the kernel – expects. These function prototypes serve as a bridge between the high-level structure of C++ and the low-level operations of assembly and system calls.

Lets take a breath

Before we move on, lets recap and take a look at whats going on under the hood. What we know so far:

• Defined the structures the kernel requires in order to actually complete the syscall (and for placing data on the stack as expected by the kernel)
• Replaced the Windows API and proxying by replacing uses of the Windows API for those EDR hooked functions with the assembly which is responsible for making the syscalls into the Windows Kernel.
• This circumvents EDR hooks

Lets check what we think is going on, is actually going on. On my version of Windows as we have seen, 0x18 represents the syscall for NtAllocateVirtualMemory (i.e. in Windows API speak: VirtualAllocEx). Looking at the new disassembly (which is easy to find thanks to the call to GetProcAddress) we can see a call to inj.xxxxxxxxxx, hovering over this you can see the popout what this relates to; our assembly!

The linker has correctly assembled our file, incorporating the assembly instructions!

Just for fun, lets replace syscall with the instruction int 2E (for more info on 2E check this link) and rebuild:

Unexpectedly, this doesn’t function as a syscall as I observe no complete DLL injection (and no errors obviously returned). Given the description from codemachine above:

I did expect this to execute into a syscall on x64, but lo, no! I would be interested to debug this on x86 and see it working there.. but that is not a challenge for today.

Automating this

Whilst this is nice, we are depending on knowing the target architecture, build number etc, which isn’t exactly favourable. So, thanks to information in here https://redops.at/en/blog/direct-syscalls-vs-indirect-syscalls (and thanks to cr0w for providing a base function), we can automate the process of finding the SSNs (syscall numbers).

Here is my implementation of automating this:

DWORD getSSN(IN HMODULE dllModule, IN LPCSTR NtFunction) {

    FARPROC NtFunctionAddress = GetProcAddress(dllModule, NtFunction);

    if (NtFunctionAddress == NULL) {
        char logBuffer[256];
        sprintf(logBuffer, "Failed to get the address of %s", NtFunction);
        printError(logBuffer);
        return 0;
    }

    /**
     * 
     * 
     *  public NtOpenProcess
            NtOpenProcess PROC
                mov r10, rcx                ; 3 bytes
                mov eax, wNtOpenProcess     ; mov (1 byte) + 28h (4 bytes) = 5 bytes
                syscall
                ret
            NtOpenProcess ENDP

     * With the below, take the byte pointer of the NT Function, then add 4 bytes to the memory location we are pointing to.
     * Here we will find the SSN (see above math).
     * Cast this location as a pointer to a double word (i.e. 4 bytes)
     * Dereference that pointer, to get the underlying value from where we were pointing.
     * 
    */
    DWORD NtFunctionSSN = *((PDWORD)((PBYTE)NtFunctionAddress + 4));

    return NtFunctionSSN;
}

I have tried to provide an explanation for what is going on with the line:

DWORD NtFunctionSSN = *((PDWORD)((PBYTE)NtFunctionAddress + 4));

So, in case it doesn’t make sense, the assembly instructions for mov r10, rcx are 3 bytes long, the fourth byte is mov eax, and the remaining 4 bytes (DWORD) are for the actual SSN.

By this point. using the dumpbin utility:

dumpbin /imports .\inj.exe

I can see that calls to things such as OpenProcess don’t appear (good) but clearly there is potential room for improvement (if any of these functions cause EDR to get suspicious):

Next steps

Next time, we will be looking at getting even more stealthy in the EDR unhooking. So until then, ciao!