Trick 1: "Fileless malware is completely undetectable because it leaves no artifacts." True or False?
FALSE — fileless malware is significantly harder to detect than file-based malware, but it is not undetectable. Multiple artifact types can survive and reveal the attack.
Artifacts that CAN exist with fileless malware:
(1) Windows Event Logs: Process creation events (Event ID 4688 with command-line logging enabled) capture PowerShell execution with encoded arguments. PowerShell Script Block Logging (Event ID 4104) records every PowerShell script block as it executes — including in-memory download cradles. These logs may be cleared by a thorough attacker, but clearing them is itself a detectable event (Event ID 1102).
(2) Sysmon events: Sysmon Event ID 1 (ProcessCreate), Event ID 3 (NetworkConnect), Event ID 8 (CreateRemoteThread), Event ID 10 (ProcessAccess targeting LSASS), Event ID 11 (FileCreate) all generate logs for memory injection activity even when no malicious file is written to disk. The injection API sequence itself is logged by Sysmon even though no file is involved.
(3) Memory forensics: A full RAM acquisition (Magnet RAM Capture, WinPmem, DumpIt) preserves the injected code in memory. Volatility's malfind plugin identifies injected regions, dumpfiles extracts embedded executables, and netscan maps connections to processes. The malware may exist in memory right up until the machine is rebooted.
(4) Network artifacts: C2 beaconing traffic — periodic outbound connections from unusual processes to external IPs — is visible in network logs, proxy logs, and EDR network telemetry. The beaconing pattern (regular intervals, consistent payload sizes, unusual user-agent strings) is detectable even over HTTPS.
(5) EDR behavioral alerts: The injection API sequence (VirtualAllocEx + WriteProcessMemory + CreateRemoteThread) against another process, unusual LSASS access, RWX memory regions without module backing — all generate alerts in behavioral EDR regardless of whether a file was written.
(6) Prefetch: Windows Prefetch tracks execution metadata for launched programs, including powershell.exe invocations with specific arguments. Even a fileless PowerShell execution may leave a Prefetch entry.
Defense and detection: Enable PowerShell Script Block Logging and Module Logging via Group Policy. Deploy Sysmon with a comprehensive configuration (SwiftOnSecurity template as a baseline). Behavioral EDR with rules tuned for injection API sequences, LSASS access, and anomalous process network behavior. Establish a memory forensics capability before an incident occurs.
Exam tip: "Fileless malware leaves no artifacts" is always FALSE. The correct statement is: fileless malware leaves fewer disk-based artifacts, but leaves behavioral, network, log, and memory artifacts that behavioral tools and memory forensics can detect.
Artifacts that CAN exist with fileless malware:
(1) Windows Event Logs: Process creation events (Event ID 4688 with command-line logging enabled) capture PowerShell execution with encoded arguments. PowerShell Script Block Logging (Event ID 4104) records every PowerShell script block as it executes — including in-memory download cradles. These logs may be cleared by a thorough attacker, but clearing them is itself a detectable event (Event ID 1102).
(2) Sysmon events: Sysmon Event ID 1 (ProcessCreate), Event ID 3 (NetworkConnect), Event ID 8 (CreateRemoteThread), Event ID 10 (ProcessAccess targeting LSASS), Event ID 11 (FileCreate) all generate logs for memory injection activity even when no malicious file is written to disk. The injection API sequence itself is logged by Sysmon even though no file is involved.
(3) Memory forensics: A full RAM acquisition (Magnet RAM Capture, WinPmem, DumpIt) preserves the injected code in memory. Volatility's malfind plugin identifies injected regions, dumpfiles extracts embedded executables, and netscan maps connections to processes. The malware may exist in memory right up until the machine is rebooted.
(4) Network artifacts: C2 beaconing traffic — periodic outbound connections from unusual processes to external IPs — is visible in network logs, proxy logs, and EDR network telemetry. The beaconing pattern (regular intervals, consistent payload sizes, unusual user-agent strings) is detectable even over HTTPS.
(5) EDR behavioral alerts: The injection API sequence (VirtualAllocEx + WriteProcessMemory + CreateRemoteThread) against another process, unusual LSASS access, RWX memory regions without module backing — all generate alerts in behavioral EDR regardless of whether a file was written.
(6) Prefetch: Windows Prefetch tracks execution metadata for launched programs, including powershell.exe invocations with specific arguments. Even a fileless PowerShell execution may leave a Prefetch entry.
Defense and detection: Enable PowerShell Script Block Logging and Module Logging via Group Policy. Deploy Sysmon with a comprehensive configuration (SwiftOnSecurity template as a baseline). Behavioral EDR with rules tuned for injection API sequences, LSASS access, and anomalous process network behavior. Establish a memory forensics capability before an incident occurs.
Exam tip: "Fileless malware leaves no artifacts" is always FALSE. The correct statement is: fileless malware leaves fewer disk-based artifacts, but leaves behavioral, network, log, and memory artifacts that behavioral tools and memory forensics can detect.
Trick 2: "Process hollowing creates a new malicious executable file that replaces the legitimate executable on disk." True or False?
FALSE — process hollowing specifically and intentionally operates ONLY in memory. The on-disk executable is never touched.
This is the defining characteristic and the source of its stealth. Here is precisely what happens to the disk file versus the in-memory process:
On disk: The legitimate executable (e.g., svchost.exe at C:\Windows\System32\svchost.exe) is never modified, never deleted, never replaced. Its file hash before and after the attack is identical. File integrity monitoring (FIM) tools report no change. Antivirus scanning the file returns clean — because the file IS clean.
In memory: After the hollowing sequence (CreateProcess suspended → NtUnmapViewOfSection → WriteProcessMemory → SetThreadContext → ResumeThread), the process's in-memory code sections contain entirely different content from what the disk file contains. The PE headers, text sections, data sections — all replaced with the attacker's payload. But this replacement exists only in the running process's virtual address space, in RAM.
Why this matters for detection: Standard forensic techniques that check "what file is running?" by looking at the process's image path will find the legitimate svchost.exe on disk and conclude nothing is wrong. The compromise is only visible to tools that compare what is in the process's memory to what the on-disk file contains — specifically comparing the in-memory code sections against a hash or byte comparison of the on-disk binary.
Tools that can detect the mismatch: Process Hacker (live analysis — highlights processes where in-memory code doesn't match disk image); Volatility (malfind, procdump, then compare to disk); EDR tools that specifically perform this comparison (a feature of many modern EDRs).
Exam tip: Any answer that says process hollowing modifies the executable file on disk is wrong. Process hollowing is an in-memory-only technique. If the question asks "how is process hollowing detected," the answer involves comparing in-memory code to the on-disk file, not file integrity monitoring or antivirus.
This is the defining characteristic and the source of its stealth. Here is precisely what happens to the disk file versus the in-memory process:
On disk: The legitimate executable (e.g., svchost.exe at C:\Windows\System32\svchost.exe) is never modified, never deleted, never replaced. Its file hash before and after the attack is identical. File integrity monitoring (FIM) tools report no change. Antivirus scanning the file returns clean — because the file IS clean.
In memory: After the hollowing sequence (CreateProcess suspended → NtUnmapViewOfSection → WriteProcessMemory → SetThreadContext → ResumeThread), the process's in-memory code sections contain entirely different content from what the disk file contains. The PE headers, text sections, data sections — all replaced with the attacker's payload. But this replacement exists only in the running process's virtual address space, in RAM.
Why this matters for detection: Standard forensic techniques that check "what file is running?" by looking at the process's image path will find the legitimate svchost.exe on disk and conclude nothing is wrong. The compromise is only visible to tools that compare what is in the process's memory to what the on-disk file contains — specifically comparing the in-memory code sections against a hash or byte comparison of the on-disk binary.
Tools that can detect the mismatch: Process Hacker (live analysis — highlights processes where in-memory code doesn't match disk image); Volatility (malfind, procdump, then compare to disk); EDR tools that specifically perform this comparison (a feature of many modern EDRs).
Exam tip: Any answer that says process hollowing modifies the executable file on disk is wrong. Process hollowing is an in-memory-only technique. If the question asks "how is process hollowing detected," the answer involves comparing in-memory code to the on-disk file, not file integrity monitoring or antivirus.
Trick 3: "Credential Guard prevents all credential theft attacks." True or False?
FALSE — Credential Guard protects a specific subset of credentials stored in LSASS memory. It does not protect credentials in all locations or all attack scenarios.
What Credential Guard DOES protect: NTLM hashes, Kerberos tickets, and other credentials stored in the LSA Isolated process (the VTL1 component of LSASS). An attacker with SYSTEM privileges running Mimikatz against LSASS will fail to extract these credentials because they are in VTL1 memory that VTL0 (the normal OS) cannot read.
What Credential Guard does NOT protect:
(1) Credentials during authentication operations. When a user actively authenticates, credentials must briefly pass through normal OS processes to perform the authentication. There is a brief window where credential material is accessible — this window is very short, but it exists. This is a theoretical attack surface, not a commonly exploited one.
(2) Credentials stored in other locations: The SAM (Security Account Manager) database on disk stores local account hashes — Credential Guard does not protect these. DPAPI (Data Protection API) blobs used to encrypt stored credentials (browser passwords, saved RDP passwords, application credentials) are not protected by Credential Guard. Plaintext credentials stored in scripts, config files, or Group Policy Preferences (a well-known source of credential exposure) are not protected.
(3) Browser-stored passwords. Chrome, Firefox, and Edge store credentials locally in encrypted databases. Credential Guard has no role in protecting these. Attackers targeting browser credential stores use completely different techniques (browser data theft tools, not Mimikatz).
(4) Pass-the-hash with previously stolen hashes. If an attacker obtained NTLM hashes before Credential Guard was deployed, those hashes are still usable for pass-the-hash attacks. Credential Guard protects current credential storage; it doesn't invalidate credentials already compromised.
(5) Kerberoasting and AS-REP roasting. These attacks target service account credentials via Active Directory protocol abuse — they don't touch LSASS at all and are entirely unaffected by Credential Guard.
Exam tip: Credential Guard is one very important layer — it specifically defeats the most common form of LSASS-based credential dumping (Mimikatz sekurlsa::logonpasswords). But a complete credential protection strategy also requires: tiered admin model (no domain admins on workstations), disabling NTLM where possible, enforcing MFA so stolen hashes provide limited value, protecting DPAPI blobs, and monitoring for credential-use anomalies.
What Credential Guard DOES protect: NTLM hashes, Kerberos tickets, and other credentials stored in the LSA Isolated process (the VTL1 component of LSASS). An attacker with SYSTEM privileges running Mimikatz against LSASS will fail to extract these credentials because they are in VTL1 memory that VTL0 (the normal OS) cannot read.
What Credential Guard does NOT protect:
(1) Credentials during authentication operations. When a user actively authenticates, credentials must briefly pass through normal OS processes to perform the authentication. There is a brief window where credential material is accessible — this window is very short, but it exists. This is a theoretical attack surface, not a commonly exploited one.
(2) Credentials stored in other locations: The SAM (Security Account Manager) database on disk stores local account hashes — Credential Guard does not protect these. DPAPI (Data Protection API) blobs used to encrypt stored credentials (browser passwords, saved RDP passwords, application credentials) are not protected by Credential Guard. Plaintext credentials stored in scripts, config files, or Group Policy Preferences (a well-known source of credential exposure) are not protected.
(3) Browser-stored passwords. Chrome, Firefox, and Edge store credentials locally in encrypted databases. Credential Guard has no role in protecting these. Attackers targeting browser credential stores use completely different techniques (browser data theft tools, not Mimikatz).
(4) Pass-the-hash with previously stolen hashes. If an attacker obtained NTLM hashes before Credential Guard was deployed, those hashes are still usable for pass-the-hash attacks. Credential Guard protects current credential storage; it doesn't invalidate credentials already compromised.
(5) Kerberoasting and AS-REP roasting. These attacks target service account credentials via Active Directory protocol abuse — they don't touch LSASS at all and are entirely unaffected by Credential Guard.
Exam tip: Credential Guard is one very important layer — it specifically defeats the most common form of LSASS-based credential dumping (Mimikatz sekurlsa::logonpasswords). But a complete credential protection strategy also requires: tiered admin model (no domain admins on workstations), disabling NTLM where possible, enforcing MFA so stolen hashes provide limited value, protecting DPAPI blobs, and monitoring for credential-use anomalies.
Trick 4: "DLL injection and reflective DLL injection both require a malicious DLL file on disk." True or False?
FALSE — standard DLL injection requires a DLL file on disk; reflective DLL injection specifically solves this limitation and requires no file on disk.
This is one of the most important distinctions in this chapter, and a classic exam trick based on the similar names of the two techniques.
Standard DLL injection — requires DLL on disk: The attacker writes a file path string (e.g., "C:\Users\Public\malicious.dll") into the target process's memory and uses CreateRemoteThread to call LoadLibraryA with that path. Windows' own loader reads the DLL from disk at that path and loads it into the target process. The DLL file must exist on disk for this to work — this is a key detection artifact. EDR and AV can scan the DLL file; file integrity monitoring can detect its creation.
Reflective DLL injection — no file on disk: The attacker does not rely on Windows' LoadLibrary at all. Instead, the shellcode already present in memory contains a complete DLL image (a full PE binary) plus a small bootstrap loader function. This custom loader performs all the work that the Windows loader normally does: it maps the DLL's sections into memory, resolves imports by manually scanning the export tables of already-loaded modules in memory, applies base relocations, and calls the DLL's entry point. Every step happens inside the target process's memory. Nothing is written to disk at any point. LoadLibrary is never called — which means there is no OS-level record of the DLL being loaded, and the DLL does not appear in the Windows loaded-module list for the process.
Why this matters: Reflective injection removes the one significant detection artifact of standard DLL injection (the DLL file). Detection must come from memory analysis (PE headers in non-module-backed memory regions, RWX memory permissions) or behavioral EDR (the allocation and execution pattern), not from file scanning.
Exam tip: Standard DLL injection = disk artifact (the DLL file). Reflective DLL injection = no disk artifact. If a question describes an injection technique where "no DLL file was found on the system," the answer is reflective DLL injection, not standard DLL injection.
This is one of the most important distinctions in this chapter, and a classic exam trick based on the similar names of the two techniques.
Standard DLL injection — requires DLL on disk: The attacker writes a file path string (e.g., "C:\Users\Public\malicious.dll") into the target process's memory and uses CreateRemoteThread to call LoadLibraryA with that path. Windows' own loader reads the DLL from disk at that path and loads it into the target process. The DLL file must exist on disk for this to work — this is a key detection artifact. EDR and AV can scan the DLL file; file integrity monitoring can detect its creation.
Reflective DLL injection — no file on disk: The attacker does not rely on Windows' LoadLibrary at all. Instead, the shellcode already present in memory contains a complete DLL image (a full PE binary) plus a small bootstrap loader function. This custom loader performs all the work that the Windows loader normally does: it maps the DLL's sections into memory, resolves imports by manually scanning the export tables of already-loaded modules in memory, applies base relocations, and calls the DLL's entry point. Every step happens inside the target process's memory. Nothing is written to disk at any point. LoadLibrary is never called — which means there is no OS-level record of the DLL being loaded, and the DLL does not appear in the Windows loaded-module list for the process.
Why this matters: Reflective injection removes the one significant detection artifact of standard DLL injection (the DLL file). Detection must come from memory analysis (PE headers in non-module-backed memory regions, RWX memory permissions) or behavioral EDR (the allocation and execution pattern), not from file scanning.
Exam tip: Standard DLL injection = disk artifact (the DLL file). Reflective DLL injection = no disk artifact. If a question describes an injection technique where "no DLL file was found on the system," the answer is reflective DLL injection, not standard DLL injection.
Trick 5: "ASLR completely prevents DLL injection attacks." True or False?
FALSE — ASLR randomizes memory base addresses but does not prevent DLL injection. These are different attack surfaces that ASLR does not address.
This is a critical concept: understanding what ASLR actually defends against, and what it does not touch.
What ASLR prevents: ASLR randomizes where DLLs, the stack, and the heap load in memory at each boot. An attacker who wants to exploit a buffer overflow by overwriting the return address with a hardcoded jump destination (e.g., "jump to address 0x7c800000 which is the start of kernel32.dll on this version of Windows") cannot do so — the address is different on every machine and every boot. Similarly, ROP chains that use hardcoded gadget addresses fail because those addresses have moved. ASLR defends against: classic buffer overflow exploitation, return-to-libc attacks, hardcoded ROP chains, and exploits that require knowing the address of specific functions or code sequences.
What ASLR does NOT prevent: DLL injection does not rely on hardcoded memory addresses at all. The injection process goes: write DLL path string to target process memory → find LoadLibraryA address at runtime using GetProcAddress → call CreateRemoteThread with the runtime-discovered LoadLibraryA address. The attacker discovers the LoadLibraryA address dynamically at runtime — they call GetProcAddress themselves, which returns the current address regardless of ASLR. ASLR moves the addresses, but the injection process finds them dynamically, so ASLR's randomization is irrelevant to this attack path.
The real relationship: ASLR and DEP together significantly raise the difficulty of exploitation. DEP prevents direct shellcode execution from data regions. ASLR makes ROP (the bypass for DEP) much harder by randomizing gadget addresses. An attacker who wants to bypass both needs an information-leak vulnerability to find current addresses before building the ROP chain. Together they impose a genuine complexity barrier. But this complexity barrier applies to exploitation (taking over control flow via memory corruption bugs) — it is essentially unrelated to DLL injection, which is a different technique that uses legitimate Windows APIs, not memory corruption exploits.
Exam tip: ASLR defends against address-dependent exploits (buffer overflows, ROP). DLL injection uses the Windows API at runtime and doesn't depend on hardcoded addresses. These are different attack categories. Don't confuse "memory security" as a monolithic concept — different controls address different attack paths.
This is a critical concept: understanding what ASLR actually defends against, and what it does not touch.
What ASLR prevents: ASLR randomizes where DLLs, the stack, and the heap load in memory at each boot. An attacker who wants to exploit a buffer overflow by overwriting the return address with a hardcoded jump destination (e.g., "jump to address 0x7c800000 which is the start of kernel32.dll on this version of Windows") cannot do so — the address is different on every machine and every boot. Similarly, ROP chains that use hardcoded gadget addresses fail because those addresses have moved. ASLR defends against: classic buffer overflow exploitation, return-to-libc attacks, hardcoded ROP chains, and exploits that require knowing the address of specific functions or code sequences.
What ASLR does NOT prevent: DLL injection does not rely on hardcoded memory addresses at all. The injection process goes: write DLL path string to target process memory → find LoadLibraryA address at runtime using GetProcAddress → call CreateRemoteThread with the runtime-discovered LoadLibraryA address. The attacker discovers the LoadLibraryA address dynamically at runtime — they call GetProcAddress themselves, which returns the current address regardless of ASLR. ASLR moves the addresses, but the injection process finds them dynamically, so ASLR's randomization is irrelevant to this attack path.
The real relationship: ASLR and DEP together significantly raise the difficulty of exploitation. DEP prevents direct shellcode execution from data regions. ASLR makes ROP (the bypass for DEP) much harder by randomizing gadget addresses. An attacker who wants to bypass both needs an information-leak vulnerability to find current addresses before building the ROP chain. Together they impose a genuine complexity barrier. But this complexity barrier applies to exploitation (taking over control flow via memory corruption bugs) — it is essentially unrelated to DLL injection, which is a different technique that uses legitimate Windows APIs, not memory corruption exploits.
Exam tip: ASLR defends against address-dependent exploits (buffer overflows, ROP). DLL injection uses the Windows API at runtime and doesn't depend on hardcoded addresses. These are different attack categories. Don't confuse "memory security" as a monolithic concept — different controls address different attack paths.
Performance Task: A financial institution runs Windows 10 Enterprise across 2,000 endpoints. Following a Mimikatz-based breach that harvested domain admin credentials via LSASS injection, security leadership wants a comprehensive memory security hardening program. Design it.
Model Answer:
Phase 1 — Credential Protection (highest priority — stops the immediate threat class)
Enable Windows Defender Credential Guard on all Enterprise endpoints. Prerequisites to verify: UEFI Secure Boot enabled, Intel VT-x or AMD-V enabled in BIOS, Windows 10 Enterprise version 1607 or later. Enable via Group Policy (Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security) or via Microsoft Endpoint Manager/Intune for cloud-managed devices. Impact: Mimikatz sekurlsa::logonpasswords fails; NTLM hashes and Kerberos tickets are isolated in VTL1.
Enable LSA Protection (PPL) for LSASS: set registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1. Requires reboot. Impact: prevents non-protected processes from opening a handle to LSASS with VM_READ permissions. Mimikatz requires a signed kernel driver to bypass PPL.
Disable WDigest authentication (should be disabled by default on Win 8.1+ but verify): HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0. Ensures cleartext passwords are never cached in LSASS.
Disable NTLM authentication where Kerberos is available: enforce Kerberos-only for internal domain authentication via Group Policy (Network Security: Restrict NTLM). Eliminating NTLM removes pass-the-hash as a post-exploitation technique even if hashes are somehow obtained.
Enforce MFA for all domain accounts — if stolen NTLM hashes are used for network authentication and modern NTLM, MFA adds a layer that hash-only attacks cannot satisfy. This is a compensating control for environments where NTLM cannot be fully disabled.
Phase 2 — Memory Protections
Confirm system-wide DEP is enforced: run bcdedit /set nx AlwaysOn from an elevated command prompt, or verify via System Properties → Performance → Data Execution Prevention. Should be enabled by default on modern Windows — verify it hasn't been disabled.
Verify High Entropy ASLR is enabled: PowerShell command Set-ProcessMitigation -System -Enable HighEntropyASLR, BottomUp, ForceRelocateImages. Verify via Get-ProcessMitigation -System.
Enable CFG (Control Flow Guard) system-wide: via Windows Security → App & Browser Control → Exploit Protection → System Settings. Enable CFG for system default settings.
Enforce WDAC (Windows Defender Application Control) code integrity policy to restrict which DLLs can load into processes. This prevents unsigned or untrusted DLLs from loading via DLL injection. Create a policy in audit mode first to identify legitimate DLL load patterns, then enforce. Particularly effective against standard DLL injection where the attacker DLL must be loadable.
Phase 3 — Behavioral Detection
Deploy EDR with the following behavioral rules (adapt to your EDR platform's query language):
Rule 1 — Injection API sequence: Alert when any process (not in an approved list of debuggers and security tools) calls VirtualAllocEx or WriteProcessMemory targeting a different process, within 60 seconds of also calling CreateRemoteThread targeting that same process. This is the DLL injection triad.
Rule 2 — LSASS access: Alert when any process not on an approved list (lsass.exe parent, security tools, EDR agent) opens a handle to lsass.exe with PROCESS_VM_READ permissions. Sysmon Event ID 10 with TargetImage=lsass.exe and GrantedAccess values including 0x10 (VM_READ) is the specific artifact.
Rule 3 — Thread context modification: Alert when any process calls SetThreadContext targeting a thread in a different process. Normal use is extremely rare outside of debuggers.
Rule 4 — PowerShell encoded execution: Alert on any PowerShell invocation with -EncodedCommand or -enc arguments. Flag immediately for review. Legitimate use is rare; malicious use is extremely common.
Rule 5 — RWX memory creation: Alert when any non-approved process creates a memory region with simultaneous Read, Write, and Execute permissions (VirtualAlloc or VirtualAllocEx with PAGE_EXECUTE_READWRITE). This is the signature of shellcode injection preparation.
Deploy Sysmon with a comprehensive ruleset covering: CreateRemoteThread (Event ID 8), ProcessAccess to LSASS (Event ID 10), NetworkConnect from unusual processes (Event ID 3), ProcessCreate with full command lines (Event ID 1).
Phase 4 — Visibility and Logging
Enable PowerShell Script Block Logging via Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging = Enabled. This logs every PowerShell script block (including decoded content of encoded commands) to the Windows event log.
Enable PowerShell Module Logging: Logs all pipeline execution details including variable values — more verbose than Script Block Logging.
Enable Windows Event ID 4688 with full command-line logging: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events.
Forward all logs to SIEM: Create correlation rule for LSASS access events (Sysmon Event ID 10, TargetImage=lsass.exe) from non-approved sources. Alert within 5 minutes. This is the highest-priority alert for credential theft attempts.
Phase 5 — Incident Response Readiness
Establish memory forensics capability before the next incident: deploy Magnet RAM Capture or WinPmem on a secure USB drive for each incident response team member. Document the memory acquisition procedure — including that acquisition must happen before any reboot or shutdown.
Prepare Volatility with standard plugins pre-configured for Windows 10 analysis (malfind, dlllist, netscan, pstree, cmdline, consoles). Run a test acquisition and analysis against a clean known-good machine to establish baseline output for comparison.
Create canary token LSASS access trap: configure a honeypot account whose credentials are "present" in LSASS memory on specific machines; any use of those credentials alerts immediately.
Conduct quarterly purple team exercises specifically targeting memory injection: red team uses Cobalt Strike or Metasploit with reflective DLL injection and process hollowing; blue team measures detection time, alert fidelity, and response time against these specific techniques. Tune EDR rules based on exercise findings.
Metrics to track: Time-to-detect for injection attempts (purple team baseline), LSASS access alert false positive rate (drives tuning), percentage of endpoints with Credential Guard enabled, percentage with LSA Protection enabled, EDR coverage percentage (all endpoints enrolled). Report to CISO quarterly.
Phase 1 — Credential Protection (highest priority — stops the immediate threat class)
Enable Windows Defender Credential Guard on all Enterprise endpoints. Prerequisites to verify: UEFI Secure Boot enabled, Intel VT-x or AMD-V enabled in BIOS, Windows 10 Enterprise version 1607 or later. Enable via Group Policy (Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security) or via Microsoft Endpoint Manager/Intune for cloud-managed devices. Impact: Mimikatz sekurlsa::logonpasswords fails; NTLM hashes and Kerberos tickets are isolated in VTL1.
Enable LSA Protection (PPL) for LSASS: set registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1. Requires reboot. Impact: prevents non-protected processes from opening a handle to LSASS with VM_READ permissions. Mimikatz requires a signed kernel driver to bypass PPL.
Disable WDigest authentication (should be disabled by default on Win 8.1+ but verify): HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0. Ensures cleartext passwords are never cached in LSASS.
Disable NTLM authentication where Kerberos is available: enforce Kerberos-only for internal domain authentication via Group Policy (Network Security: Restrict NTLM). Eliminating NTLM removes pass-the-hash as a post-exploitation technique even if hashes are somehow obtained.
Enforce MFA for all domain accounts — if stolen NTLM hashes are used for network authentication and modern NTLM, MFA adds a layer that hash-only attacks cannot satisfy. This is a compensating control for environments where NTLM cannot be fully disabled.
Phase 2 — Memory Protections
Confirm system-wide DEP is enforced: run bcdedit /set nx AlwaysOn from an elevated command prompt, or verify via System Properties → Performance → Data Execution Prevention. Should be enabled by default on modern Windows — verify it hasn't been disabled.
Verify High Entropy ASLR is enabled: PowerShell command Set-ProcessMitigation -System -Enable HighEntropyASLR, BottomUp, ForceRelocateImages. Verify via Get-ProcessMitigation -System.
Enable CFG (Control Flow Guard) system-wide: via Windows Security → App & Browser Control → Exploit Protection → System Settings. Enable CFG for system default settings.
Enforce WDAC (Windows Defender Application Control) code integrity policy to restrict which DLLs can load into processes. This prevents unsigned or untrusted DLLs from loading via DLL injection. Create a policy in audit mode first to identify legitimate DLL load patterns, then enforce. Particularly effective against standard DLL injection where the attacker DLL must be loadable.
Phase 3 — Behavioral Detection
Deploy EDR with the following behavioral rules (adapt to your EDR platform's query language):
Rule 1 — Injection API sequence: Alert when any process (not in an approved list of debuggers and security tools) calls VirtualAllocEx or WriteProcessMemory targeting a different process, within 60 seconds of also calling CreateRemoteThread targeting that same process. This is the DLL injection triad.
Rule 2 — LSASS access: Alert when any process not on an approved list (lsass.exe parent, security tools, EDR agent) opens a handle to lsass.exe with PROCESS_VM_READ permissions. Sysmon Event ID 10 with TargetImage=lsass.exe and GrantedAccess values including 0x10 (VM_READ) is the specific artifact.
Rule 3 — Thread context modification: Alert when any process calls SetThreadContext targeting a thread in a different process. Normal use is extremely rare outside of debuggers.
Rule 4 — PowerShell encoded execution: Alert on any PowerShell invocation with -EncodedCommand or -enc arguments. Flag immediately for review. Legitimate use is rare; malicious use is extremely common.
Rule 5 — RWX memory creation: Alert when any non-approved process creates a memory region with simultaneous Read, Write, and Execute permissions (VirtualAlloc or VirtualAllocEx with PAGE_EXECUTE_READWRITE). This is the signature of shellcode injection preparation.
Deploy Sysmon with a comprehensive ruleset covering: CreateRemoteThread (Event ID 8), ProcessAccess to LSASS (Event ID 10), NetworkConnect from unusual processes (Event ID 3), ProcessCreate with full command lines (Event ID 1).
Phase 4 — Visibility and Logging
Enable PowerShell Script Block Logging via Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging = Enabled. This logs every PowerShell script block (including decoded content of encoded commands) to the Windows event log.
Enable PowerShell Module Logging: Logs all pipeline execution details including variable values — more verbose than Script Block Logging.
Enable Windows Event ID 4688 with full command-line logging: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events.
Forward all logs to SIEM: Create correlation rule for LSASS access events (Sysmon Event ID 10, TargetImage=lsass.exe) from non-approved sources. Alert within 5 minutes. This is the highest-priority alert for credential theft attempts.
Phase 5 — Incident Response Readiness
Establish memory forensics capability before the next incident: deploy Magnet RAM Capture or WinPmem on a secure USB drive for each incident response team member. Document the memory acquisition procedure — including that acquisition must happen before any reboot or shutdown.
Prepare Volatility with standard plugins pre-configured for Windows 10 analysis (malfind, dlllist, netscan, pstree, cmdline, consoles). Run a test acquisition and analysis against a clean known-good machine to establish baseline output for comparison.
Create canary token LSASS access trap: configure a honeypot account whose credentials are "present" in LSASS memory on specific machines; any use of those credentials alerts immediately.
Conduct quarterly purple team exercises specifically targeting memory injection: red team uses Cobalt Strike or Metasploit with reflective DLL injection and process hollowing; blue team measures detection time, alert fidelity, and response time against these specific techniques. Tune EDR rules based on exercise findings.
Metrics to track: Time-to-detect for injection attempts (purple team baseline), LSASS access alert false positive rate (drives tuning), percentage of endpoints with Credential Guard enabled, percentage with LSA Protection enabled, EDR coverage percentage (all endpoints enrolled). Report to CISO quarterly.