Question 1: An attacker creates a legitimate Windows process in a suspended state, unmaps its executable code from memory, writes malicious code into the emptied process memory space, and resumes the process. Task manager shows a legitimate-looking process name and file path. Which injection technique is this?
Correct answer: C. Process hollowing (also called process replacement). The key indicators are: (1) a legitimate process created in suspended state, (2) unmapping of the legitimate code, (3) writing malicious code in its place, and (4) resuming. The process looks legitimate externally because it IS a legitimate binary — only the in-memory code sections are replaced. DLL injection (A) loads a new DLL without replacing the existing process code. Thread hijacking (B) redirects an existing thread's instruction pointer without creating a new process. Reflective DLL injection (D) loads a self-contained DLL image from memory into an existing running process, without creating a new suspended process.
Question 2: Which of the following injection techniques does NOT leave a malicious executable file on disk as an artifact?
Correct answer: B. Reflective DLL injection is specifically designed to operate entirely in memory — the DLL image exists only in process memory, loaded by a custom in-memory loader that never invokes LoadLibrary and never writes a file. Standard DLL injection (A) requires the malicious DLL file to exist on disk at a path that can be passed to LoadLibrary — a detectable disk artifact. DLL side-loading (C) and DLL search order hijacking (D) both require placing a malicious DLL file on disk in a location where a legitimate application will load it — both produce disk artifacts.
Question 3: An organization wants to protect LSASS credentials even if an attacker gains SYSTEM-level privileges on a Windows 10 Enterprise machine. Which technology achieves this?
Correct answer: C. Credential Guard uses Virtualization-Based Security (VBS) to store credential material in a separate Virtual Secure Mode (VSM) enclave at VTL1 — a privilege level higher than the normal OS kernel (VTL0). Even with SYSTEM privileges in VTL0, the credential material in VTL1 is inaccessible — Mimikatz cannot read it. PPL (A) prevents unauthorized processes from opening a handle to LSASS, which is a useful complementary defense, but PPL can be bypassed by a kernel-level exploit, and a SYSTEM-level attacker with a kernel driver can potentially defeat PPL. Credential Guard's VTL1 isolation is more robust against SYSTEM-level compromise. DEP (B) and ASLR (D) are memory protection mechanisms that defend against code injection and address exploitation — they do not specifically protect LSASS credential material.
Question 4: Which memory protection technique randomizes the base addresses of DLLs and the stack and heap at each boot, defeating hardcoded-address exploits and ROP chains?
Correct answer: C. ASLR (Address Space Layout Randomization) specifically randomizes DLL base addresses, stack location, and heap location at each boot (and optionally at each load). An attacker cannot hardcode the address of a specific function or gadget. ROP chains, which reuse existing executable code gadgets at known addresses, are defeated because those addresses change each boot. DEP (A) marks data memory as non-executable but doesn't randomize addresses. CFG (B) validates indirect call targets but doesn't randomize memory layouts. Credential Guard (D) protects LSASS credential storage using VBS isolation.
Question 5: A threat actor uses a phishing email with a malicious macro to trigger PowerShell, which downloads a CobaltStrike Beacon payload directly into memory and injects it into explorer.exe — never writing any files to disk. This attack is BEST described as:
Correct answer: C. The defining characteristic of fileless malware is that the malicious payload never touches the disk as a file — it executes entirely in memory. The chain here is entirely in-memory: macro → PowerShell download cradle (no file written) → in-memory injection into explorer.exe. DLL injection using a disk-based payload (A) requires a DLL file on disk. Process hollowing (B) involves creating a new suspended process and replacing its code — the scenario describes injection into an existing explorer.exe, not creating a new hollow process. A rootkit (D) modifies operating system kernel structures or boot components — not described here.
Matching: Windows API Roles in DLL Injection
Match each Windows API call to its specific role in the DLL injection sequence.
API CALL
VirtualAllocEx
WriteProcessMemory
CreateRemoteThread
LoadLibraryA
ROLE IN DLL INJECTION
Allocates a memory region in the target process's virtual address space to hold the DLL path
The Windows function called by the injected thread that causes the target process to actually load and execute the DLL
Copies the DLL file path string into the memory region that was allocated in the target process
Spawns a new thread inside the target process, with its start address pointing to LoadLibrary and the DLL path as its argument
Analysis Question
A threat hunter finds that a workstation's svchost.exe is making sustained outbound HTTPS connections to an unfamiliar external IP. The svchost.exe file on disk passes all integrity checks. No new files have been created on the system. No new processes appear in the process list beyond the expected svchost instances. What likely occurred and how would you investigate?
Model Answer:
What likely occurred: Process hollowing or reflective DLL injection — malicious code is running inside svchost.exe while the on-disk file is legitimate and unchanged. The absence of new files and new processes is consistent with a memory-only attack. The anomalous outbound HTTPS connections indicate the injected code is a C2 beacon communicating with an attacker's infrastructure.
Why the disk is clean: Process hollowing replaces the in-memory executable sections without modifying the disk file. Reflective DLL injection loads a DLL entirely from memory with no disk write. Both techniques are specifically designed to pass file-based checks.
Investigation steps:
(1) Memory acquisition first — before any reboot. Use Magnet RAM Capture, DumpIt, or WinPmem to acquire a full physical memory image. Rebooting destroys all evidence. This is the single most important step.
(2) Volatility analysis of the memory image: Run the malfind plugin to identify memory regions with anomalous permission combinations (RWX — read-write-execute) and PE header signatures at non-standard addresses. Run dlllist to identify any DLLs loaded at addresses not matching expected module load points. Run netscan to map network connections to specific processes and verify the svchost instance responsible for the HTTPS connections.
(3) Compare in-memory code to on-disk executable: Extract the code sections from the svchost.exe memory image and compare their hash to the on-disk svchost.exe binary. A mismatch is definitive evidence of process hollowing. Tools: Process Hacker (live), Volatility procdump (from memory image).
(4) Parent process analysis: svchost.exe should always be a child of services.exe. An svchost.exe with any other parent process is suspicious. Check both live (Process Explorer) and in the memory image (Volatility pstree).
(5) Check for injected memory regions with RWX permissions: Injected shellcode and reflective DLLs often exist in memory regions with read-write-execute permissions simultaneously — a combination that is highly unusual for legitimate code.
(6) Analyze the network connection: Extract the external IP from memory or EDR logs, perform passive DNS and threat intelligence lookups, and check if the connection pattern (periodic check-ins, beaconing behavior) is consistent with C2 activity.
(7) Review EDR telemetry: Look for VirtualAllocEx, WriteProcessMemory, or SetThreadContext calls targeting the svchost PID in the time window before the anomalous connections began. The injection event itself may be logged even if its result (the injected code) is memory-only.
What likely occurred: Process hollowing or reflective DLL injection — malicious code is running inside svchost.exe while the on-disk file is legitimate and unchanged. The absence of new files and new processes is consistent with a memory-only attack. The anomalous outbound HTTPS connections indicate the injected code is a C2 beacon communicating with an attacker's infrastructure.
Why the disk is clean: Process hollowing replaces the in-memory executable sections without modifying the disk file. Reflective DLL injection loads a DLL entirely from memory with no disk write. Both techniques are specifically designed to pass file-based checks.
Investigation steps:
(1) Memory acquisition first — before any reboot. Use Magnet RAM Capture, DumpIt, or WinPmem to acquire a full physical memory image. Rebooting destroys all evidence. This is the single most important step.
(2) Volatility analysis of the memory image: Run the malfind plugin to identify memory regions with anomalous permission combinations (RWX — read-write-execute) and PE header signatures at non-standard addresses. Run dlllist to identify any DLLs loaded at addresses not matching expected module load points. Run netscan to map network connections to specific processes and verify the svchost instance responsible for the HTTPS connections.
(3) Compare in-memory code to on-disk executable: Extract the code sections from the svchost.exe memory image and compare their hash to the on-disk svchost.exe binary. A mismatch is definitive evidence of process hollowing. Tools: Process Hacker (live), Volatility procdump (from memory image).
(4) Parent process analysis: svchost.exe should always be a child of services.exe. An svchost.exe with any other parent process is suspicious. Check both live (Process Explorer) and in the memory image (Volatility pstree).
(5) Check for injected memory regions with RWX permissions: Injected shellcode and reflective DLLs often exist in memory regions with read-write-execute permissions simultaneously — a combination that is highly unusual for legitimate code.
(6) Analyze the network connection: Extract the external IP from memory or EDR logs, perform passive DNS and threat intelligence lookups, and check if the connection pattern (periodic check-ins, beaconing behavior) is consistent with C2 activity.
(7) Review EDR telemetry: Look for VirtualAllocEx, WriteProcessMemory, or SetThreadContext calls targeting the svchost PID in the time window before the anomalous connections began. The injection event itself may be logged even if its result (the injected code) is memory-only.
Evaluation Question
"DEP alone is sufficient to prevent memory injection attacks." Evaluate this statement.
Model Answer: FALSE — DEP significantly raises the bar for some attack types but does not prevent memory injection broadly.
What DEP does: DEP marks data memory regions (stack, heap, data segments) as non-executable using the CPU's NX bit. If an attacker injects shellcode into stack or heap memory, the CPU raises an exception when that code is executed, preventing it from running. This defeats the simplest form of shellcode injection: write shellcode to stack → jump to stack → execute shellcode.
Why DEP is insufficient:
(1) ROP (Return-Oriented Programming) bypasses DEP entirely. ROP chains do not inject new executable code — they reuse small "gadget" sequences already present in legitimate, executable DLL memory. The attacker chains these gadgets (each ending in a RET instruction) to achieve arbitrary computation without ever executing code from a data region. DEP provides zero protection against ROP because all the code being executed is already in executable regions that DEP doesn't touch. This is the primary real-world bypass and is used in virtually all modern exploits.
(2) Reflective DLL injection maps the DLL into executable memory. The reflective loader allocates the injected DLL's code sections with EXECUTE permissions — the memory region where the injected code runs IS executable. DEP only blocks code in data regions; it has no relevance to memory that is intentionally allocated as executable. Reflective injection specifically allocates executable memory for this reason.
(3) Process hollowing writes code into a code region. When an attacker hollows a process and writes their payload into the emptied code sections, those sections remain marked executable (because they were originally the process's code). DEP protects data regions, not code regions — which are intentionally executable. The hollowed payload runs in what the OS considers a legitimate executable region.
(4) DLL injection loads a DLL into executable memory. Windows loads DLLs into code memory with execute permissions. Standard DLL injection causes Windows' own LoadLibrary to load the attacker's DLL — into memory that is correctly marked executable. DEP has no role in stopping this.
What is sufficient: Defense requires DEP + ASLR (ASLR randomizes gadget addresses, defeating ROP; together they force attackers toward information leaks and significantly more complex exploitation chains) + CFG (limits indirect control flow hijacking) + behavioral EDR (detects injection API sequences regardless of memory protection state) + Credential Guard (protects the credential targets even if injection succeeds). No single control is sufficient; the combination creates genuine defense in depth.
What DEP does: DEP marks data memory regions (stack, heap, data segments) as non-executable using the CPU's NX bit. If an attacker injects shellcode into stack or heap memory, the CPU raises an exception when that code is executed, preventing it from running. This defeats the simplest form of shellcode injection: write shellcode to stack → jump to stack → execute shellcode.
Why DEP is insufficient:
(1) ROP (Return-Oriented Programming) bypasses DEP entirely. ROP chains do not inject new executable code — they reuse small "gadget" sequences already present in legitimate, executable DLL memory. The attacker chains these gadgets (each ending in a RET instruction) to achieve arbitrary computation without ever executing code from a data region. DEP provides zero protection against ROP because all the code being executed is already in executable regions that DEP doesn't touch. This is the primary real-world bypass and is used in virtually all modern exploits.
(2) Reflective DLL injection maps the DLL into executable memory. The reflective loader allocates the injected DLL's code sections with EXECUTE permissions — the memory region where the injected code runs IS executable. DEP only blocks code in data regions; it has no relevance to memory that is intentionally allocated as executable. Reflective injection specifically allocates executable memory for this reason.
(3) Process hollowing writes code into a code region. When an attacker hollows a process and writes their payload into the emptied code sections, those sections remain marked executable (because they were originally the process's code). DEP protects data regions, not code regions — which are intentionally executable. The hollowed payload runs in what the OS considers a legitimate executable region.
(4) DLL injection loads a DLL into executable memory. Windows loads DLLs into code memory with execute permissions. Standard DLL injection causes Windows' own LoadLibrary to load the attacker's DLL — into memory that is correctly marked executable. DEP has no role in stopping this.
What is sufficient: Defense requires DEP + ASLR (ASLR randomizes gadget addresses, defeating ROP; together they force attackers toward information leaks and significantly more complex exploitation chains) + CFG (limits indirect control flow hijacking) + behavioral EDR (detects injection API sequences regardless of memory protection state) + Credential Guard (protects the credential targets even if injection succeeds). No single control is sufficient; the combination creates genuine defense in depth.