Malware Techniques: Thread Hijacking

Learning to identify Indicators of Compromise (IoCs) in malware is always easier when the sample is controlled and home-grown. In this post, I'll be discussing a synthetic malware sample that I personally wrote as part of an ethical red-team learning exercise.

The synthetic malware sample was designed to behave similarly to modern loader-style implants and, during testing inside a controlled lab environment, it successfully bypassed basic detection mechanisms. This makes it a realistic and meaningful case study for malware analysis.

To be clear: I will not be publishing the full source code or anything weaponizable. Instead, I'll walk through the design concepts and then demonstrate how we uncover these behaviors using standard malware-analysis and reverse-engineering techniques.

Think of this as burying treasure ourselves and then learning how to track it using forensic methods.

A High-Level Overview of the Sample

This sample is a malicious Windows DLL designed to demonstrate remote thread hijacking in a safe, controlled manner. The payload ultimately provides a reverse shell back to a designated safe IP on the internal network—ensuring the environment remains secure and isolated.(Why a DLL? We'll discuss this quite a lot in a later part.)

Here are the characteristics of this synthetic malware:

Written in C

C provides low-level control over memory, threads, and process manipulation—ideal for illustrating injection concepts.

Encrypted Payload

The shellcode used for demonstration is:

• Embedded in the DLL as an encrypted blob

• Encrypted using AES-256

• Decrypted only at runtime

This reflects how real-world malware attempts to hide capabilities from static inspection.

Suspended Process Creation

The malware creates a legitimate Windows process (e.g., notepad.exe or calc.exe) in suspended mode.This technique is commonly used to blend in with regular system activity during injection.

Remote Memory Write

After decrypting the payload, the malware writes the shellcode into the suspended process's memory space.

Thread Hijacking

Instead of creating a new remote thread (a common but more detectable approach), some malware families achieve execution by reusing an existing thread’s control flow in a target process. Conceptually, this involves manipulating the thread’s instruction pointer (EIP/RIP) so that when execution continues, it follows attacker-controlled code (specific implementation details intentionally omitted).

This can be a stealthier injection path and is the central theme of this series: remote thread hijacking as an execution technique.

This produces a stealthier injection path and is the central theme of this series:remote thread hijacking as an execution technique.

Reverse Shell Execution

If Windows Defender and behavior-based protection don’t flag the activity, the resumed thread executes the shellcode, resulting in a reverse shell connecting back to the safe internal IP used for demonstration.

Why Malware Is Often Written as DLLs Instead of EXEs

Malware isn't always delivered as a standalone executable. Many advanced samples - especially those involving injection, persistence, or stealth - are implemented as DLLs (Dynamic-Link Libraries).

There are several strategic reasons for this choice.

1. DLLs Are Easier to Inject Into Legitimate Processes

One of the most common malware behaviors is process injection.

DLLs can be:

• Loaded directly into another process’s memory

• Mapped without writing to disk (reflective loading)

• Executed using known OS mechanisms like LoadLibrary

This gives an attacker the advantage of:

• Running code inside a trusted process (e.g., explorer.exe, svchost.exe)

• Evading basic antivirus checks on unknown executables

• Inheriting privileges and network permissions of the host process

EXEs cannot be loaded this way easily - they require full process creation.DLLs are therefore a more flexible execution vehicle.

2. DLLs Support Stealthy Execution via Reflective Loading

Reflective DLL loading allows a DLL to be:

• Loaded from memory

• Without touching disk

• Without using the OS loader

This avoids:

• File-based detection

• PE header scanning

• Signature-based engines

EXEs, by design, rely heavily on the Windows process loader, making full in-memory execution more complex.

3. Persistence Mechanisms Often Expect DLLs

Several legitimate Windows persistence points require DLL paths, such as:

• COM Hijacking

• Shell extensions

• Accessibility feature abuse

• AppInit_DLLs

• Browser helper objects

• Service DLL overwrite attacks

• Print Spooler DLL load points

Using a DLL makes it easier for malware to “plug into” these locations and achieve long-term stealth.

4. DLLs Can Be Loaded by Any Existing Process

A DLL can be executed simply by causing a legitimate process to call:

LoadLibraryA("malicious.dll");

Meaning malware authors don’t need:

• EXE stubs

• PE entrypoints

• New process creation (which is noisy)

This reduces behavioral indicators such as:

• New process chains

• Suspicious parent–child relationships

• Unknown binaries launching unexpectedly

5. DLLs Are Ideal for Thread Hijacking and APC Injection

Techniques such as:

• Thread hijacking

• APC injection

• QueueUserAPC

• Thread context manipulation

Work more cleanly when the payload is stored in a DLL form because:

• The DLL structure contains relocations

• The entrypoint (DllMain) makes initialization predictable

• Attackers can export specific functions for easy loading

DLLs align perfectly with execution-on-existing-thread scenarios.

6. DLLs Allow Modular Attack Architecture

APT groups frequently use a modular malware design:

• Loader (EXE or script)

• Core implant (DLL)

• Plugins/extensions (DLLs)

• Persistence component (registry, service, COM object)

DLLs allow attackers to:

• Swap components without rebuilding the entire malware

• Load modules on demand

• Reduce disk footprint by downloading plugins only when needed

This mirrors legitimate software design - making behavior harder to distinguish.

7. DLLs Can Masquerade as Legitimate System Libraries

Malicious DLLs often impersonate names like:

• version.dll

• wininet.dll

• psapi.dll

When placed near legitimate executables, they take advantage of DLL search order hijacking:

• Windows loads the attacker's DLL first

• The real DLL is forwarded afterward

This is a classic “living-off-the-land” technique.

8. Red Teams and Malware Devs Prefer DLLs for Ethical Reasons

In controlled environments:

• DLL implants are smaller

• Easier to load into analysis tools

• Easier to trigger in sandbox VM tests

• Ideal for reflective loading demonstrations

• Provide more precise execution control

This is why many red-team implants, C2 agents, and academic research malware are distributed as DLLs.

To put this technique into perspective, here are recent examples of well-known APT groups that have used DLL-based malware or DLL side-loading in real-world attacks. This highlights how common DLL abuse is among advanced adversaries.

APT / Threat Actor	What they did (DLL-based) / Technique	Notes
APT41	Abused DLL search-order hijacking / DLL side-loading to run its loader/backdoor named “DUSTTRAP” via a benign code-signed Windows (or third-party) binary. (APT41)	Demonstrates how state-linked actors still rely on DLL abuse for evasion and persistence.
Mustang Panda (aka “Bronze President” / “TA416”)	Used DLL sideloading (e.g. via Adobe Reader or other legitimate trusted apps) to load malicious payloads such as RATs like PlugX. (VMRay)	DLL side-loading helps bypass simple signature-based detection by piggy-backing on trusted executables.
Dark Pink (targeting Southeast Asia / Southeast-Asia-linked campaigns)	Packaged a malicious DLL alongside a decoy executable in a spear-phishing ISO or archive; when the EXE is run, the malicious DLL is loaded via side-loading. (Group-IB)	Classic DLL side-loading: leverages user-executed installer/executable + malicious DLL to gain persistence.
Various (generic “threat actors” / malware campaigns)	Leveraging DLL hijacking / side-loading as a general execution & persistence vector — documented broadly in threat-intel reports. (Unit 42)	Highlights that DLL abuse remains a “go-to” technique for both state-sponsored and crime-ware actors.

If your organization needs advanced malware analysis, reverse engineering, or ethical red-team tooling, our team at PalaviTech can help. Explore our cybersecurity services at https://palavi.tech and strengthen your defensive posture with expert support.