Memory Injection Flashcards

Running malicious code inside a legitimate process's address space to evade detection and inherit the process's identity, trust, and privileges. The process name still appears legitimate in task manager; the malicious code is hidden within it. Foundation of most advanced fileless attack techniques.

Writing a malicious DLL file path into the target process's memory (VirtualAllocEx + WriteProcessMemory), then triggering LoadLibrary via CreateRemoteThread to load the DLL into the target process. The DLL file exists on disk (detection artifact) but executes within the trusted host process. Uses the Windows API injection triad.

A DLL with its own custom in-memory loader that maps itself from memory without using Windows' LoadLibrary and without touching disk. No file artifact, no entry in the Windows loaded-module list, no LoadLibrary call in API logs. Used by Metasploit Meterpreter and CobaltStrike Beacon. Detected by memory scanning for PE headers in non-module-backed regions.

Create a legitimate process in suspended state (CREATE_SUSPENDED) → unmap its code from memory (NtUnmapViewOfSection) → write malicious code into the empty memory space (WriteProcessMemory) → update instruction pointer → resume. Process name, PID, and on-disk file remain legitimate; only the in-memory code is replaced. Detection: compare in-memory code sections to on-disk file hash — mismatch reveals the hollow.

Suspend a running thread in a target process (OpenThread + SuspendThread), redirect its instruction pointer register (RIP/EIP) to attacker shellcode via SetThreadContext, then resume the thread with ResumeThread. The shellcode executes inside an existing legitimate thread. No new thread created — harder to detect than CreateRemoteThread-based injection. Code runs inside the legitimate thread context.

Malware that executes entirely in process memory — no executable file written to disk. Evades file-based AV, file integrity monitoring, and hash-based detection. Typically arrives via phishing macro or exploit that immediately loads code into memory. Detected by behavioral EDR (anomalous process behavior, API sequences), memory scanning, and process anomaly detection. Artifacts may still include event logs and network connections.

Self-contained, position-independent machine code payload designed for direct injection into process memory. Has no import table — instead dynamically resolves its own API addresses at runtime by scanning loaded module memory. Can execute from any memory address. Typically small (bytes to kilobytes). Injected directly into memory without a DLL or PE file structure. Often the first-stage payload that loads a larger implant.

The Local Security Authority Subsystem Service — the Windows process that manages authentication. Holds credential material in memory: NTLM hashes, Kerberos tickets, and (historically with WDigest) cleartext passwords for all users who have authenticated on the machine. Primary target of credential-harvesting attacks. Protected by PPL (prevents unauthorized process access) and Credential Guard (moves credentials to a VBS-isolated VM).

Open-source credential extraction tool that reads NTLM hashes and Kerberos tickets from LSASS memory (sekurlsa::logonpasswords). Requires SYSTEM privileges or SeDebugPrivilege. Historically extracted cleartext passwords via WDigest (disabled by default since Win 8.1). Drove Microsoft to create Credential Guard, PPL for LSASS, and modern LSASS access controls. Used in penetration testing and by real-world attackers including Carbanak and NotPetya.

Windows feature using Virtualization-Based Security (VBS) to isolate LSASS credential storage in a VSM (Virtual Secure Mode) enclave at VTL1 — a higher privilege level than the normal OS. Even with SYSTEM privileges or a kernel exploit in VTL0, credential material in VTL1 is inaccessible. Mimikatz cannot extract credentials from a system with Credential Guard enabled. Requires Windows 10/11 Enterprise, UEFI Secure Boot, hardware virtualization.

CPU and OS feature marking memory as either writable (data) or executable (code), but not both — enforced by the CPU's NX (No-Execute) bit. Shellcode injected into stack or heap memory cannot execute because those regions are non-executable. Defeated by ROP (Return-Oriented Programming) chains that reuse existing executable code gadgets without injecting new code. Most effective combined with ASLR, which randomizes gadget addresses and defeats ROP.

Address Space Layout Randomization — randomizes the base addresses of loaded DLLs, the stack, and the heap at each boot. Forces attackers to discover actual addresses dynamically rather than hardcoding them. Defeats classic buffer overflows and ROP chains that depend on fixed gadget addresses. Defeated by information-leak vulnerabilities that expose current memory layouts. High-Entropy ASLR (64-bit) makes brute-force guessing impractical. Most effective combined with DEP.

Microsoft compiler and OS security feature that validates indirect function call targets at runtime. A bitmap of valid call targets is computed at compile time. Every indirect call is checked against this bitmap before executing. Prevents function pointer hijacking, vtable corruption, and callback overwriting — any redirect of control flow through an indirect call to an attacker address. Requires compiler support (/guard:cf) and OS support (Windows 8.1+).

The Windows API sequence at the core of classic DLL injection: VirtualAllocEx allocates memory in a remote process, WriteProcessMemory writes the DLL path or shellcode into that memory, and CreateRemoteThread creates a new execution thread in the remote process pointing to LoadLibrary or shellcode. Legitimate uses: debuggers, security tools. Behavioral EDR flags any non-approved process executing this sequence against another process.

Using built-in, legitimate OS tools (PowerShell, WMI, certutil, mshta, regsvr32, rundll32) to execute attacker code rather than custom malware binaries. No new executables written to disk; the payload is arguments and scripts. Bypasses application whitelisting (tools are whitelisted) and hash-based detection (binaries are legitimate). Detected by command-line argument monitoring, behavioral analysis of what legitimate tools are doing, and anomaly detection for admin tools in non-admin contexts.

A historical injection technique (documented 2016) that abuses the Windows atom table — a legitimate IPC mechanism for storing small strings shared between processes — to store shellcode via GlobalAddAtom. APC (Asynchronous Procedure Call) queues are then used to trick a legitimate process into reading and executing the shellcode from the atom table. Avoids VirtualAllocEx and WriteProcessMemory (which behavioral tools monitored), using entirely different Windows mechanisms to achieve injection. Largely mitigated by modern behavioral EDR and Windows security updates.