EPI

EPI (Entry Point Injection) is a tool that leverages a new threadless process injection technique that relies on hijacking loaded dll’s entry points. To achieve this goal, EPI patches the target process’ PEB such that one of the already loaded dll’s entry points are redirected to an injected shellcode (which by default is the Loader previously converted to sRDI). Once a new thread is naturally spawned by the process or whenever a running thread exits, all loaded modules’ entry points will be called which includes our injected shellcode.

Since we want the target process to continue its execution smoothly, generally speaking, it is a bad idea to run our payload directly on the thread that is calling the hijacked entry point. For example, the direct execution of a C2 becon would completely hijack the thread which would surely lead to the program crash in case the application is expecting the thread to perform a certain task. To deal with this situation, EPI by default does not directly inject the desired payload but a custom Loader, which is a regular dll converted to sRDI. The Loader has embedded the encrypted final payload (for example, the previously commented C2 beacon), and its main task is to decrypt, allocate and run this payload in a stable way. To achieve the execution keeping the “threadless” nature of the technique, the Loader will use the process’ thread pool to run the payload by calling QueueUserWorkItem. The use of QueueUserWorkItem ensures that even in the case that a new thread is spawned (it depends on the thread pool availability), the start routine’s address will never point to our payload avoiding that particular IOC.

Before exiting, the Loader restores the PEB and other modified structures to their previous state, preventing the multiple executions of our payload and allowing the process to continue its normal execution.

By default, this tool hijacks kernelbase.dll entry points. Feel free to target a different dll, but make sure that the dll is loaded in both processes involved in this activity.

The provided shellcode embedded in the Loader spawns a new cmd.exe /k msg “hello from kudaes” process.

The advantages of this technique are the following:

• Both threadless or threaded execution, at will.
• No hooking (i.e. no RX memory regions are patched).
• No generation of private memory regions on well-known dll’s RX memory pages.
• No RWX memory permissions are required.
• The targeted process can continue its regular execution.
• No new threads with a start address pointing to our shellcode.

Install & Use

Copyright (c) 2013, Matthew Graeber