Memory Injection — Glossary

Technique of running malicious code inside the address space of a legitimate process to evade detection. The injected code inherits the host process's identity, privileges, and network access. Task manager and most security tools see only the legitimate process name; the malicious code is hidden within it. The foundation of most advanced, fileless attack techniques.

A Windows executable module containing shared code and data that multiple programs can use simultaneously. DLLs load into a process's address space and execute in its context. Windows automatically loads core DLLs (kernel32.dll, ntdll.dll, user32.dll) into every process. The standard format for shared code in Windows; abused by attackers who force legitimate processes to load malicious DLLs.

Forcing a legitimate process to load a malicious DLL by writing the DLL file path into the target process's memory (via WriteProcessMemory) and then triggering LoadLibrary via CreateRemoteThread. The DLL file exists on disk — one detection artifact — but executes within the trusted host process. Uses the Windows API triad: VirtualAllocEx, WriteProcessMemory, CreateRemoteThread.

Injecting a DLL that contains its own custom loader, enabling it to map itself into memory from within a process without touching the disk or invoking Windows' LoadLibrary. The DLL image exists entirely in memory; the loader manually resolves imports, applies relocations, and executes the entry point. No file artifact on disk, no entry in the Windows loaded-module list. Used by Metasploit Meterpreter and CobaltStrike Beacon.

Creating a legitimate process in a suspended state (CREATE_SUSPENDED), unmapping its executable code from memory using NtUnmapViewOfSection, writing malicious code into the emptied memory space via WriteProcessMemory, and resuming the process. The process name, PID, and on-disk file remain legitimate; only the in-memory code is replaced. Detection: compare in-memory code sections to the on-disk file hash — a mismatch reveals hollowing. Also called process replacement.

Small, self-contained machine code payload designed for direct injection into process memory. Shellcode is position-independent — it can execute from any memory address. Windows shellcode typically begins by locating kernel32.dll in memory and dynamically resolving API function addresses, making it self-sufficient without an import table. Injected directly into memory without a DLL or PE file structure.

Suspending a legitimate thread in a target process (OpenThread + SuspendThread), modifying the thread's instruction pointer register (RIP/EIP) via SetThreadContext to redirect execution to attacker-supplied shellcode in memory, then resuming the thread with ResumeThread. The shellcode executes inside the legitimate thread context. No new thread is created, making detection harder than CreateRemoteThread-based techniques.

Malware that operates entirely in memory without writing executable files to disk. Typically arrives via a phishing macro or exploit that immediately loads code into memory and executes without touching the filesystem. Evades file-based antivirus, file integrity monitoring, and hash-based detection because no malicious file exists on disk. Detected by behavioral EDR, memory scanning, and process anomaly detection. Artifacts that may still exist: event logs, network connections, memory forensics findings.

A Windows mechanism that queues a function call to be executed in the context of a specific thread, at a safe point when the thread enters an alertable wait state. Legitimate use: I/O completion callbacks. Abuse: attackers queue shellcode as an APC to a thread in a target process (QueueUserAPC), causing the shellcode to execute inside that thread when it next becomes alertable. Used in AtomBombing and other injection techniques as an alternative to CreateRemoteThread.

The Windows process (lsass.exe) responsible for authentication — verifying credentials for logons, managing security policy, and generating access tokens. As a consequence of its authentication role, LSASS holds credential material in memory: NTLM hashes, Kerberos tickets, and (in older configurations) cleartext passwords. The primary target for credential-harvesting attacks. Protected by PPL (Protected Process Light) and Credential Guard in hardened environments.

An open-source credential extraction tool created by Benjamin Delpy that reads NTLM hashes, Kerberos tickets, and (historically) cleartext passwords from LSASS memory. Core function: sekurlsa::logonpasswords. Requires SYSTEM privileges or SeDebugPrivilege. Used in penetration testing and by real-world attackers; drove Microsoft to introduce Credential Guard, PPL for LSASS, and to disable WDigest authentication by default in Windows 8.1+.

A Windows feature using Virtualization-Based Security (VBS) to isolate LSASS credential storage in a protected virtual environment (Virtual Secure Mode / VTL1). The credential-holding component runs in a separate lightweight VM with its own isolated kernel, at a privilege level higher than the normal OS. Even if the OS kernel is compromised (SYSTEM privileges, kernel exploit), it cannot access VTL1 memory — Mimikatz cannot extract credentials. Requires Windows 10 Enterprise, UEFI Secure Boot, and CPU virtualization support.

A CPU and OS feature that marks memory regions as either executable or writable (data), but not both. Enforced by the CPU's NX (No-Execute) bit. Data memory (stack, heap) is writable but non-executable — shellcode injected into these regions cannot execute. Code regions are executable but not writable. Prevents simple shellcode injection attacks. Defeated by ROP (Return-Oriented Programming), which reuses existing executable code fragments rather than injecting new code.

An OS feature that randomizes the base addresses of DLLs, the stack, and the heap every time they are loaded — different on each machine, different at each boot. Forces attackers to discover actual memory addresses dynamically rather than hardcoding them. Defeats classic buffer overflows that jump to hardcoded addresses. Also defeats ROP chains (which rely on known gadget addresses). Defeated by information-leak vulnerabilities that expose current memory layouts. Most effective when combined with DEP.

A Microsoft compiler and OS security feature that validates indirect function call targets at runtime. At compile time, a bitmap of valid indirect call targets is computed. At runtime, every indirect call (through a function pointer, vtable, callback) is checked against this bitmap before executing. If the target address is not in the bitmap — as would happen if an attacker overwrote a function pointer — the process terminates. Defeats function pointer hijacking and vtable corruption. Requires both compiler support (Visual Studio) and OS support (Windows 8.1+).

The Windows API triad at the core of classic DLL injection. VirtualAllocEx allocates memory in a remote process's address space. WriteProcessMemory writes data into that allocated region (the DLL path or shellcode). CreateRemoteThread creates a new execution thread in the remote process, pointing to a function (LoadLibraryA or shellcode) with the written data as its argument. Legitimate use: debuggers, security software. Malicious use: process injection. Behavioral EDR monitors for non-debugger processes invoking this sequence against other processes.