Memory Injection — Real-World Examples

What happened: A regional bank's finance department received a spear-phishing email with a malicious Word document. A finance analyst opened the document and enabled macros. The macro spawned a PowerShell process with an encoded command — a download cradle that fetched a CobaltStrike Beacon payload over HTTPS and loaded it into memory using reflective DLL injection, injecting into explorer.exe. The Beacon communicated with a command-and-control server via HTTPS on port 443 using a domain-fronting technique that made the traffic appear destined for a legitimate CDN.

The credential harvest: Via the C2 channel, the attacker pushed a Mimikatz-like credential-harvesting module and injected it into a SYSTEM-privileged process. NTLM hashes for twelve domain accounts — including two service accounts — were extracted from LSASS. The attacker used pass-the-hash to authenticate as those service accounts and pivot to additional workstations and servers.

The numbers: 47 endpoints compromised. 19 days of undetected access. $0 in malware files found on disk at the time of discovery. The attacker's entire toolkit existed only in memory.

How it was caught: EDR behavioral alert: explorer.exe making sustained outbound HTTPS connections to an unfamiliar IP, combined with an alert on a process accessing LSASS with a handle that included PROCESS_VM_READ permissions — a flag that the EDR had been configured to log for non-approved processes.

Key lesson: Fileless attacks are not undetectable — they are detected by behavioral anomalies (a process making unusual network connections, unusual LSASS access) rather than file signatures. Behavioral EDR with tuned rules is the primary detection mechanism.

Background: Benjamin Delpy released Mimikatz in 2011 to demonstrate a fundamental weakness in Windows credential storage — that Windows cached authentication credentials in LSASS memory in a way that allowed them to be extracted by anyone with sufficient privilege. The research was intended to drive Microsoft to fix the underlying issues; instead, Mimikatz became one of the most widely deployed tools in offensive security and real-world attacks.

Core function: sekurlsa::logonpasswords — reads the LSASS process memory to extract credentials for all users who have authenticated on the machine. Historically, this included cleartext passwords stored for the WDigest authentication protocol (WDigest kept a cleartext copy of the password in memory for compatibility with HTTP digest authentication). Microsoft disabled WDigest by default in Windows 8.1 / Server 2012 R2 in response to Mimikatz exposure.

Current capabilities: Even on modern Windows with WDigest disabled, Mimikatz can still extract NTLM hashes and Kerberos tickets from LSASS. NTLM hashes can be used directly for pass-the-hash attacks (authenticating as the user without knowing their actual password). Kerberos tickets can be used for pass-the-ticket and Golden Ticket attacks.

The defensive response: Windows Credential Guard (Windows 10 Enterprise, 2016) isolates credential material in VBS/VSM — Mimikatz cannot reach it. PPL (Protected Process Light) requires any process opening LSASS to be a protected process with a Microsoft-signed certificate — Mimikatz cannot satisfy this without a signed kernel driver. Modern EDR rules flag any process acquiring a LSASS handle with VM_READ permissions unless that process is on an approved list.

Key lesson: Mimikatz drove an entire generation of Windows security improvements. Understanding what it does — and why each defensive control specifically stops it — is essential for the exam and for real-world security work.

What happened: NotPetya, attributed to the Russian military intelligence agency GRU, was deployed in June 2017 initially targeting Ukraine via a compromised accounting software update mechanism. It spread globally within hours, causing an estimated $10 billion in damage — the most destructive cyberattack in history at the time.

The injection component: NotPetya included a Mimikatz-like credential extraction module that injected into legitimate Windows processes to harvest NTLM credentials from LSASS memory. Combined with the EternalBlue SMB exploit (stolen NSA tooling leaked by Shadow Brokers), it had two propagation methods: exploiting unpatched SMB (MS17-010) directly, or using harvested credentials to authenticate to other machines via PsExec and WMIC — both legitimate Windows administration tools.

Why process injection was critical to the attack: By running its credential harvesting inside legitimate process memory rather than as a standalone executable, NotPetya could harvest credentials even from networks where endpoint protection might have blocked a standalone malicious binary. The injected credential-harvesting code running inside a Windows service process looked like normal Windows activity to many security tools of the era.

The lateral movement cascade: On networks where even one machine had domain admin credentials cached in LSASS, NotPetya extracted those credentials and used them to authenticate to and infect every other machine in the domain — turning a single foothold into complete domain compromise within minutes. Organizations without Credential Guard and with domain admin credentials cached on multiple machines had no defense once the first machine was compromised.

Key lesson: Credential harvesting via memory injection, combined with legitimate admin tools for lateral movement, enabled catastrophic damage without requiring any novel exploits on most of the compromised machines. Credential hygiene (no domain admin logged into workstations, tiered admin model) would have significantly contained the spread.

What happened: The Carbanak APT group (also tracked as FIN7) targeted financial institutions globally between approximately 2013 and 2018, stealing an estimated $1 billion from banks in over 30 countries. Initial access was via spear-phishing emails with malicious Word and Excel attachments targeting bank employees — particularly those in finance and IT operations roles.

The process hollowing component: After initial access via macro, Carbanak used process hollowing as its primary persistence and evasion technique: legitimate Windows processes (including svchost.exe and other common system services) were hollowed and replaced with the Carbanak banking malware. All malicious activity ran inside processes that appeared completely legitimate — the right name, the right file path on disk, the right parent process, the right integrity level.

Why it succeeded for so long: Banks had file-based antivirus and perimeter controls but minimal behavioral EDR capable of comparing in-memory process images to on-disk executables. The malicious code running inside hollowed svchost processes was effectively invisible to the security tooling of the era. Attackers were inside bank networks for an average of several months before detection, methodically learning bank-specific internal processes, monitoring employee workstations, and observing exactly how internal fund transfers worked.

The ultimate goal: Rather than stealing customer data or credentials for external use, Carbanak used its deep access to learn banks' internal systems and then use those systems legitimately — initiating fraudulent wire transfers through the banks' own internal processes, manipulating ATM networks to dispense cash at predetermined times and locations, and modifying account balances. The attacks used the banks' own trusted systems; no external money-movement systems were hacked.

Key lesson: Process hollowing makes digital forensics extremely difficult — there is no malicious executable file to find. Incident response requires memory forensics (comparing in-memory code to on-disk images) rather than file-based investigation. The absence of malware files does not mean the absence of an attacker.

The concept: "Living off the land" (LotL) attacks use built-in Windows tools — PowerShell, WMI, certutil, mshta, regsvr32, rundll32, cscript — to execute attacker code rather than deploying custom malware binaries. The attacker's payload runs through a legitimate, Microsoft-signed Windows utility. No new binaries are written to disk; the attacker's code is arguments and scripts, not standalone executables.

WMI subscriptions (persistence without files): Windows Management Instrumentation has an event subscription mechanism that allows code to execute in response to system events — process creation, user logon, system startup, schedule triggers. An attacker can create a WMI event subscription that fires PowerShell with a specific encoded payload whenever the machine starts up. The subscription is stored in the WMI repository (a Windows database), not as an executable file. Standard file-system searches find nothing suspicious. The persistence survives reboots and OS updates. Detected by: monitoring WMI subscription creation events (Windows Event ID 5861), or auditing the WMI repository directly.

certutil.exe -decode: certutil is a legitimate Windows certificate management tool that has a -decode flag for decoding base64-encoded certificate files. Attackers use it to decode their payloads: certutil.exe -decode encoded_payload.txt payload.exe — the encoded file looks like certificate data; certutil decodes it and writes the executable. Used to bypass controls that watch for direct executable downloads. Detected by: command-line argument monitoring; any certutil.exe invocation with -decode outside of legitimate PKI operations should be flagged.

mshta.exe / regsvr32 / rundll32: Each of these legitimate signed utilities can be directed to execute attacker-supplied code (HTA files, COM objects, DLLs) from the internet or local filesystem. Because they are Microsoft-signed binaries, application whitelisting that allows them to run provides no protection when these binaries are redirected to malicious content.

Key lesson: LotL attacks cannot be blocked by binary whitelisting alone (all the tools are whitelisted by default). Detection requires command-line argument monitoring, behavioral analysis of what these tools are doing (network connections, file writes, child processes), and anomaly detection when administrative tools are invoked in non-administrative contexts. Hash-based detection is entirely useless — the binaries are legitimate and unmodified.

Scenario 1 — The Clean Disk

Situation: "Forensic analysts respond to a compromised workstation. A full antivirus scan returns clean. No recently created executable files are found. No new entries appear in installed programs. However, memory analysis using Volatility reveals injected code running inside svchost.exe's address space, with a PE header at an address not registered with the Windows loader. What type of attack occurred, and what investigation steps are required?"

Answer: Fileless malware via reflective DLL injection (or process hollowing). The clean disk is not evidence of no attack — it is evidence of a memory-only attack. The PE header at an unregistered address is the signature of reflective DLL injection: a DLL image loaded into memory by a custom loader, not by the Windows loader, and therefore not appearing in the normal module list.

Investigation steps: (1) Acquire a full RAM image before rebooting — rebooting destroys the evidence. (2) Analyze with Volatility: malfind plugin to identify injected memory regions; dlllist to identify modules loaded outside normal load points; netscan to correlate the injected process's network connections. (3) Dump the injected memory region and analyze the PE structure to identify the payload. (4) Review parent process relationships and process creation times. (5) Pull PowerShell ScriptBlock logs and Windows Event ID 4688 (process creation with command line) to trace the initial injection chain.

Scenario 2 — The Legitimate-Looking Process

Situation: "An attacker creates a new svchost.exe process in suspended state, unmaps its executable code from memory, writes malicious code into the empty process memory space, updates the instruction pointer to the malicious code's entry point, and resumes the process. Task manager shows a legitimate-looking svchost.exe with a normal PID and file path."

Answer: Process hollowing (also called process replacement). The process name, PID, file path, and parent process listing all appear legitimate because they are legitimate — the svchost.exe binary on disk is the real, unmodified file. Only the in-memory code sections have been replaced. File integrity checks pass; the malicious code is only visible through memory analysis that compares the running process's code sections to the on-disk executable.

Scenario 3 — Stopping Stack Shellcode

Situation: "A defender wants to prevent malicious shellcode that has been injected into a process's stack memory from executing. Which single defense mechanism addresses this most directly?"

Answer: DEP (Data Execution Prevention) — enforced by the CPU's NX (No-Execute) bit. DEP marks the stack as non-executable. When the CPU attempts to execute code from a stack memory page, it raises a hardware exception instead. The shellcode exists in memory but cannot execute because the stack page is marked non-executable. Note: DEP does not prevent the injection itself — it only prevents execution from data regions. An attacker with a ROP chain can bypass DEP, which is why DEP and ASLR are always deployed together.