Threadless Injection. Injecting shellcode into third-party processes to circumvent EDR

The standard shellcode injection procedure and subsequent shellcode execution involve the following steps:

1. Get a process handle (OpenProcess and NtOpenProcess);
2. Allocate memory for payload (VirtualAllocEx and NtMapViewOfSection);
3. Write payload to the allocated memory (WriteProcessMemory and Ghost Writing); and 
4. Execute shellcode (CreateRemoteThread and NtQueueApcThread).

Needless to say that this sequence of actions is well-known to EDR tools; if some program implements it, a red flag is immediately raised, and the process is terminated.

Is it possible to write code that performs the same actions but doesn’t directly use the above-listed WinAPI functions? For the first three steps, such a task is feasible, but when it comes to shellcode execution, problems arise. If a program directly calls the CreateRemoteThread/NtQueueApcThread functions, EDR will ring the alarm bell with a 100% guarantee.

So, to fool the defense, this chain of actions has to be broken somehow. For example, you can try to intercept some API calls in a third-party app, in an exported DLL function, and then make this function work for you…

The idea is as follows: you patch network functions of some legitimate software that already interacts with the network and then use these functions to communicate with your network resources. This is the essence of the Threadless Injection technique: you patch exported functions of a dynamic library used by a third-party process so that your code is executed when these functions are called. Its implementation involves the following steps:

1. Find a code cave that can accommodate your shellcode and trampoline;
2. Write the shellcode and trampoline to this memory area;
3. Patch an exported DLL function to make it execute your code; and 
4. Wait for this function to be called, which will trigger shellcode execution.

But dynamic libraries can contain hundreds and thousands of functions, and a randomly selected function might be unsuitable for your purposes. Who can guarantee that it will be called within a reasonable period of time (or will be called at all)?..

To solve this issue, you have to examine the software you are going to use to intercept an exported function. Ideally, you need an app that calls certain DLL functions on a regular basis (e.g. when it accesses its temporary file on the disk and writes intermediate results to it or checks the availability of its servers on the network by calling the respective API at a certain interval). If you find such a function, you can be sure that the required call will occur before long.

On the other hand, this rule shouldn’t be abused: if an app calls some API too often (e.g. several times per second), and you try to intercept such a call, glitches are inevitable.

To conduct such a research, let’s use API Monitor. This program shows in real time how a WinAPI is called and what actions in the test program affect this call. In addition, you can see what DLLs are attached to the process and what APIs do they implement (i.e. you see not just a list of WinAPIs whose origin is unknown). Based on the monitoring data, you can decide which function from the library export is suitable for your purposes and should be intercepted.

Once you examine the test program and identify the required WinAPIs, you can start coding.

Coding

Let’s implement each step required to perform Threadless Injection in code.

First, you have to get a handle of the target process by its name:

Then you load the selected dynamic library whose export contains the API function required for your purposes (e.g. kernelbase.dll).

Next, you get the address of your API in the DLL:

Searching for a code cave (i.e. memory area where you can write your data):

The next step involves manipulations with the trampoline and other arithmetic. To make it clear, let’s denote the trampoline and the payload. I am going to use a standard payload frequently used in PoC demos that starts Calculator. The trampoline balances the stack, saves registers, and restores them after calling the payload:

Reading the beginning of the function exported from the DLL and configuring the trampoline using the obtained data:

Configuring memory and granting it the PAGE_EXECUTE_READWRITE rights to set the hook:

Creating a hook (call) in the function exported by the attacked library and configuring it:

Writing the trampoline and payload and then changing the target memory attributes: first to PAGE_EXECUTE_READWRITE and then back to PAGE_EXECUTE_READ (when the job is done):

Congrats! Now all you have to do is wait for the app to call the patched function. You won’t have to wait for long since the modified API is called on a regular basis (as confirmed by API Monitor).

Conclusions

Now you are familiar with the Threadless Injection technique that can be implemented without explicitly calling thread creation functions. This breaks the standard injection stereotype and enables you to avoid detection and continue doing your job.

Of course, the above code is just a demonstration – a template that requires significant improvements to achieve true invisibility. This technique is neither a panacea nor a silver bullet that completely conceals your code. Remember: to give the Red Team a chance to win, all available techniques (injections, API calls, code obfuscation, etc., etc.) should be used in deadly combinations. Good luck!