MF1.8 Anti-Acquisition Techniques

Anti-VM detection — malware that refuses to run in virtual environments

This section covers the most common anti-acquisition technique. It doesn't block your capture — it blocks the attack from running in your lab in the first place.

Anti-VM detection is a technique where malware checks whether it's running inside a virtual machine and terminates if it is. The logic is simple from the attacker's perspective: security researchers and forensic analysts use VMs; real victims don't (or at least, their desktops don't). If the malware detects a VM, it assumes it's being analysed and shuts down before the analyst can observe its behaviour.

The detection methods are well-documented and range from trivial to sophisticated.

Trivial checks: look for VMware or VirtualBox processes in the process list (vmtoolsd.exe, VBoxService.exe), check for VM-specific registry keys (HKLM\SOFTWARE\VMware, Inc.\VMware Tools), query the BIOS for VM-manufacturer strings (SYSTEM\CurrentControlSet\Control\SystemInformation\SystemManufacturer containing "VMware" or "innotek"). Intermediate checks: execute CPUID instruction and examine the hypervisor-present bit (bit 31 of ECX from leaf 1), check the I/O port backdoor (in eax, dx with dx = 0x5658 on VMware), measure execution timing of instructions that behave differently under virtualisation. Sophisticated checks: compare RDTSC timing across sequences of instructions to detect the overhead virtualisation introduces, check for the interrupt descriptor table (IDT) at an address that reveals a hypervisor's relocation of system structures.

For the course lab, anti-VM detection has a specific impact: if you're analysing malware that uses these checks, the malware won't execute on Target-Win (a VM) the way it would on a physical host. The attack-capture-analyse loop assumes the attack executes fully. The course's scripted attacks don't include anti-VM checks (they're controlled playbooks), but real-world malware the learner encounters in production may.

Countermeasures: disable VM-specific services and registry keys before running the malware, use hypervisor-specific hardening features that mask VM indicators (VMware's monitor_control.restrict_backdoor = TRUE), or capture from a physical system where anti-VM checks pass naturally. MF2 and later modules note where anti-VM is relevant to the specific attack scenario.

Memory wiping — destroying evidence before capture

This section covers the technique that directly counters memory forensics: the attacker zeroes their own memory before exiting.

Memory wiping is when the attacker's code explicitly zeroes the memory regions it used before terminating. A well-written implant calls RtlSecureZeroMemory on its heap allocations, C2 communication buffers, credential caches, and decrypted configuration data before calling ExitProcess. When the process terminates, the wiped pages are returned to the kernel's free list — and your capture finds zeroed regions where the evidence used to be.

The effectiveness depends on timing. Wiping only works if the attacker's code runs the cleanup before your acquisition tool captures those pages. If you capture while the malware is running (before it decides to exit and wipe), the evidence is in RAM and your image has it. If you capture after the malware has exited and wiped, the evidence is gone from RAM — but may still be in the pagefile (MF1.5), because the OS may have paged out copies of the same data before the wipe occurred.

This is one reason acquisition speed matters. The longer the gap between "we know we need memory" and "the acquisition tool starts reading pages," the more time the attacker has to detect the response and trigger cleanup. Hypervisor-based acquisition (MF1.4) is particularly valuable here: the guest is suspended instantly with no guest-visible signal, so the attacker's cleanup code can't run in response to the acquisition because the CPU is halted.

Detection in analysis: look for large zeroed regions within a process's virtual address space (VADs with RWX or RW permissions that contain nothing but zeros). A region that's RWX + zeroed + private (no file backing) is the classic post-wipe fingerprint — something was there, it was executable, and now it's gone. The presence of the zeroed region is itself a finding, even if the content is unrecoverable. The absence of content in a region with suspicious characteristics is evidentially relevant: "a private RWX allocation of 128 KB within PID XXXX contained only zeroed bytes, consistent with deliberate memory wiping prior to process termination."

Acquisition-tool detection — triggering destruction when capture begins

This section covers the adversary who monitors for your acquisition tools and responds to them. Rare in commodity attacks, real in targeted operations.

Some implants register kernel callbacks that fire when a new driver is loaded (PsSetLoadImageNotifyRoutine) or when a new process is created (PsSetCreateProcessNotifyRoutine). If the callback detects a WinPmem driver load or a forensic tool process creation, the implant triggers its cleanup routine — wiping memory, killing persistence, deleting files, disconnecting C2. The attacker's logic: if the IR team is loading forensic tools, the operation is burned; destroy evidence and extract.

This is the strongest argument for hypervisor-based acquisition in environments where advanced adversaries are a realistic threat model. Hypervisor suspension doesn't load a driver, create a process, or generate any kernel callback. The guest's entire execution state is frozen from outside. An implant monitoring for driver loads never sees the acquisition because its CPU is halted before the acquisition begins.

When hypervisor acquisition isn't available and in-guest tools are the only option, the countermeasure is speed and stealth. Use an acquisition tool the adversary hasn't pre-programmed a detection for (the tool landscape changes; adversaries can't monitor for every tool). Rename the executable to something innocuous (the driver's internal name matters more than the executable name, but renaming adds a minor layer). Execute from a network share or USB drive rather than copying the tool to the local disk first (avoids file-creation callbacks). None of these are guarantees — a determined adversary with kernel-level access can detect any in-guest acquisition — but they raise the cost of detection.

Evidence degradation — making analysis unreliable after capture

This section covers the subtlest category: the attacker doesn't prevent your capture; they poison the data you capture.

Evidence degradation is when the attacker modifies kernel structures to confuse analysis tools without preventing normal system operation. Pool-tag overwriting (changing the pool tag on an allocation to match a different object type, causing psscan to misidentify structures), EPROCESS field manipulation (setting misleading values in fields that plugins read, like false CreateTime timestamps or spoofed ImageFileName values), and DKOM (Direct Kernel Object Manipulation — unlinking a process from the active list while keeping the pool allocation intact) are all forms of evidence degradation.

The defense is multi-method analysis. A single plugin result is vulnerable to degradation; multiple independent analysis methods cross-validate each other. If pslist shows a process and psscan confirms it with consistent fields and windows.handles shows it owns handles that match expected behaviour, the evidence is corroborated. If pslist shows a process but psscan finds inconsistent pool tags and windows.handles shows no handles, the process may be a planted decoy. The confidence tier framework from MF0.7 handles this: multi-method confirmation raises confidence; single-method findings without corroboration stay at medium or low.

WinDbg (MF0.6) is the fallback for deep structure validation when plugin-level analysis is insufficient. Walking the EPROCESS structure by hand at the debugger level lets you see the raw fields without the plugin's interpretation layer — which is exactly what you need when you suspect the plugin's interpretation is being manipulated by the attacker's modifications. MF6 covers kernel-level adversary investigation in depth; this sub establishes that it exists and why it matters.

tasklist | findstr /i "vmtoolsd VBoxService VBoxTray vmware"

# VMware
reg query "HKLM\SOFTWARE\VMware, Inc.\VMware Tools" 2>nul

# VirtualBox
reg query "HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions" 2>nul

wmic computersystem get manufacturer,model