Analyzing Memory-Mapped File Abuses for Malware Evasion

In the perpetual arms race between malware authors and endpoint detection and response (EDR) systems, the battleground has shifted from the disk to the much more volatile realm of volatile memory. While traditional injection techniques like Process Hollowing or `CreateRemoteThread`-based DLL injection have become heavily scrutinized by modern security tooling, a more subtle and structurally integrated primitive remains a potent vector for evasion: Memory-Mapped Files (MMFs).

By leveraging the kernel's own mechanisms for file-backed memory management, sophisticated actors can execute code and facilitate inter-process communication (IPC) in ways that bypass many of the standard API hooks and behavioral heuristics used by modern defenders.

The Mechanics of Memory Mapping

To understand the abuse, one must first understand the legitimate utility of memory mapping. At its core, memory mapping is a mechanism that allows a process to treat the contents of a file as if it were a contiguous block of memory in its virtual address space.

On Windows, this is achieved through a specific sequence of kernel objects and APIs:

1. `CreateFile`: Obtains a handle to a file on disk.
2. `CreateFileMapping`: Creates a "Section Object." This is a kernel-level abstraction that represents a block of memory that can be shared. The section object can be backed by a file (file-backed) or by the system paging file (anonymous).
3. `MapViewOfFile` / `MapViewOfFileEx`: Maps a "view" of this section object into the calling process's virtual address space.

When a file is mapped, the kernel's memory manager handles the heavy lifting. When a process accesses an address within the mapped range that is not currently in physical RAM, a page fault occurs. The kernel then intercepts this fault, reads the required data from the disk, and populates a physical page frame.

The elegance of this system lies in its efficiency, but for an attacker, the elegance lies in the shared nature of the Section Object. Because a section object exists independently of any single process, multiple processes can map the same section into their respective address spaces. This provides a high-bandwidth, low-noise channel for data exchange and code execution.

Abuse Pattern 1: Section Object Injection (The "Ghost" Injection)

The most sophisticated abuse of MMFs involves using Section Objects to inject executable code into a remote process without ever calling `WriteProcessMemory`.

Traditional injection relies on a "Write" primitive. An attacker gains a handle to a target process and uses `WriteProcessMemory` to overwrite a legitimate buffer with shellcode. This is a "noisy" operation; EDRs heavily hook this API and look for the transition of memory from `PAGE_READWRITE` to `PAGE_EXECUTE_READ`.

In a Section Object injection, the workflow is fundamentally different:

1. Creation: The attacker process creates a section object using `CreateFileMapping` with `PAGE_EXECUTE_READWRITE` permissions.
2. Mapping: The attacker maps a view of this section into their own process and writes the malicious payload into that memory.
3. Injection: Instead of writing to the target, the attacker uses `MapViewOfFileEx` to map the same section object into the virtual address space of the target process.

From the perspective of the target process, the memory has always been there. There was no `WriteProcess Mapping` event or `WriteProcessMemory` call directed at the target's memory space. The payload is "born" into the target's address space as a result of a mapping operation, which is a far more difficult event to intercept and analyze in real-time.

Abuse Pattern 2: File-Backed Payload Staging

Another evasion technique involves using legitimate, seemingly innocuous files as a backing store for malicious payloads. An attacker might drop a large, encrypted `.dat` or `.bin` file in a common directory like `C:\ProgramData\`.

Rather than loading this file into memory via standard `ReadFile` operations-which might trigger "large file read" or "unusual file access" alerts-the malware maps the file directly into memory. By using `MEM_MAPPED` instead of `MEM_PRIVATE` memory, the payload resides in a region of memory that is technically backed by a disk object.

This complicates forensics. When an analyst examines the process memory, they see a `MEM_MAPPED` region. If the file on disk appears to be a legitimate application component or a large database fragment, the analyst might overlook the fact that the "data" within that file is actually a structured, executable payload.

Detection and Operational

Conclusion

As shown across "The Mechanics of Memory Mapping", "Abuse Pattern 1: Section Object Injection (The "Ghost" Injection)", "Abuse Pattern 2: File-Backed Payload Staging", a secure implementation for analyzing memory-mapped file abuses for malware evasion depends on execution discipline as much as design.

The practical hardening path is to enforce host hardening baselines with tamper-resistant telemetry, behavior-chain detection across process, memory, identity, and network telemetry, and continuous control validation against adversarial test cases. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track time from suspicious execution chain to host containment and reduction in reachable unsafe states under fuzzed malformed input, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.