Analyzing injected code is one of the most important steps in memory forensics because many modern attacks depend on running malicious payloads directly inside legitimate processes. This technique allows malware to avoid writing files to disk, bypass antivirus tools, and blend into normal system activity. Memory forensics exposes these injected segments, helping investigators identify malicious behavior that would otherwise stay completely hidden.

This chapter explains how injected code appears in RAM, the techniques attackers use, how forensic tools detect injections, and what indicators reveal the presence of memory-resident payloads.

What Is Code Injection?

Code injection occurs when an attacker inserts malicious instructions into the memory space of a legitimate process. This allows malware to:

Run under the identity of trusted system processes
Hide from security tools
Bypass permissions
Maintain stealth persistence
Execute fileless payloads

Injected code often appears as unbacked memory regions, RWX pages, or memory segments without associated files.

Common Code Injection Techniques

Attackers use multiple injection methods, each leaving distinct signatures in memory.

1. Classic DLL Injection

Malware forces a process to load a malicious DLL.

Methods include:

CreateRemoteThread
LoadLibrary()
AppInit DLLs
Registry-based autoloading

2. Reflective DLL Injection

Loads DLLs directly from memory without writing to disk.

Indicators:

PE headers in memory
No corresponding file path
Suspicious VAD regions

Used heavily by:

Cobalt Strike
Meterpreter
Brute Ratel
Sliver

3. Process Hollowing

Replaces a legitimate process’s memory with malicious code.

Workflow:

Launch normal process (e.g., svchost.exe)
Unmap its memory
Replace with malicious payload
Resume execution

Indicators:

Process image name doesn’t match memory contents
Missing standard DLLs
VAD regions inconsistent with executable

4. Thread Injection

Malware injects shellcode via remote threads.

Techniques:

CreateRemoteThread
APC injection
Thread hijacking

Indicators:

Threads running from suspicious memory regions
No legitimate module associated

5. Shellcode Injection

Small payloads injected directly into memory.

Often used for:

Reverse shells
Stagers
Beacon loaders

Indicators:

RWX memory pages
High entropy (packed/encoded shellcode)
Missing PE headers

How Injected Code Appears in Memory

Memory forensics tools examine:

VAD (Virtual Address Descriptors)
Page permissions
Allocation flags
Loaded modules
Code regions

Suspicious characteristics:

Memory pages with RWX permissions
Memory regions not associated with any executable
High-entropy data (encrypted/packed)
Hidden memory segments
PE headers in memory without backing files
Unlinked modules

These clues usually lead investigators directly to injected malicious code.

Detecting Injected Code with Volatility

Volatility’s malfind plugin is the primary tool for identifying injected code.

Run malfind

volatility3 -f mem.raw windows.malfind

This reveals:

Virtual memory pages with executable permissions
Disassembled shellcode
Process ID
Hex dumps of suspicious pages

Step-by-Step Indicators in malfind Output

Page protection: PAGE_EXECUTE_READWRITE
Almost always suspicious.
No file mapped to the memory region
Indicates reflective injection.
PE header in memory
Suggests DLL or EXE loaded secretly.
Suspicious assembly instructions
Examples:
- mov eax, ...
- jmp rax
- Shellcode patterns (EB, E8 opcodes)
High entropy values
Packed or encrypted payloads.

Additional Volatility Commands for Injection Analysis

List loaded DLLs

windows.dlllist

Scan for hidden modules

windows.modscan

Check process memory regions

windows.vadinfo

Dump suspicious memory regions

windows.vad_dump

Analyze process tree anomalies

windows.pstree

Strings analysis

Dump process memory and extract:

strings -a dumpfile | grep http

Useful for finding:

C2 beacons
URLs
Encryption keys
Commands

Analyzing Injected Code in Linux Memory

Use plugins like:

linux.vmas
linux.proc_maps
linux.psscan

Look for:

Deleted ELF binaries (“(deleted)”)
RWX or W+X memory pages
Processes with unknown executable paths
Shellcode in memory regions

Analyzing Injected Code in macOS Memory

macOS indicators include:

Suspicious Mach-O images
Code injected into Finder, Safari, or Chrome
Memory pages with execute permissions but no file backing
Abnormal Objective-C runtime allocations

Volatility plugins:

mac.malfind
mac.vadinfo
mac.pslist

Behavioral Indicators of Injected Code

1. CPU spikes from normally idle processes

(e.g., lsass.exe spiking under malware load)

2. Abnormal thread creation

Threads pointing to non-module memory ranges.

3. Inconsistent memory layout

DLLs missing, replaced, or out of order.

4. IOCs inside injected code

Hardcoded IPs
API keys
Domain names
Shellcode instructions

5. Suspicious process ancestry

PowerShell → Rundll32 → Chrome

Intel Dump

Injected code is one of the primary signs of modern malware, enabling stealthy fileless execution.
Techniques like reflective DLL injection, process hollowing, shellcode injection, and thread hijacking leave detectable traces in RAM.
Volatility’s malfind, psscan, dlllist, and vadinfo plugins reveal suspicious memory pages, injected modules, RWX regions, and hidden code.
Indicators include memory regions without backing files, executable memory pages, high entropy, PE headers in RAM, and mismatched process images.
Linux and macOS also exhibit clear signs of code injection through abnormal memory maps, deleted binaries, Mach-O injections, and unauthorized execute permissions.
Memory forensics remains the strongest method to expose injected malware that leaves no disk footprints.