cThreadHijack: Beacon Object File for remote process injection
cThreadHijack
Remote process injection, for the unfamiliar, is a technique in which an operator can inject code into another process on a machine, under certain circumstances. This is most commonly done with a chain of Windows APIs being called in order to allocate some memory in the other process, write user-defined memory (usually a shellcode of some sort) to that allocation, and kicking off execution by creating a thread within the remote process. The APIs, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread are often popular choices, respectively.
Beacon Object File (BOF) for remote process injection, via thread hijacking, without spawning a remote thread. An accompanying blog can be found here. cThreadHijack works by injecting raw Beacon shellcode, generated via a user-supplied listener argument, into a remote process, defined by the user-supplied PID argument, via VirtualAllocEx and WriteProcessMemory. Then, instead of spawning a new remote thread via CreateRemoteThread or other APIs, cThreadHijack identifies the first enumerated thread in the target process, suspends it, and retrieves the contents of the thread’s CPU state via a CONTEXT structure. Then, the RIP register member of the CONTEXT structure (on 64-bit systems) is manipulated to point to the address of the aforementioned remote Payload. Prior to execution, a routine is added to wrap the Beacon shellcode inside of a call to CreateThread – giving Beacon its own thread to work in, with this thread being locally spawned, versus being spawned remotely. The CreateThread routine is also wrapped in an NtContinue function call routine, allowing restoration of the previously hijacked thread without crashing the remote process. Beacon payloads for cThreadHijack are generated with a ‘thread’ exit function, allowing the process continued after the Beacon has been exited. Beacon listener names, when containing a space, must be placed in quotes.
