Ghost in the RAM: weaponizing memfd_create() for fileless attacks

In the modern Linux threat landscape, threat actors often use “fileless” execution as a mechanism to avoid dropping malware on disk: it helps them to bypass traditional signature-based scanners and file system security-related mount options, and leaves a significantly smaller forensic footprint.

System call memfd_create() plays a vital role in such attacks. Introduced in Linux kernel 3.17, memfd_create() was designed to create anonymous files that live entirely in RAM. According to the memfd_create(2) manual page, these files behave like regular files — they have a size, they can be mapped, and they can be written to — but they have no backing on the physical filesystem. The memfd_create() call returns a file descriptor that can be used by fexecve(3) that allows a process to execute a binary via a file descriptor (FD) unlike execve(2) that requires a pathname on the filesystem.

The typical exploit chain follows a highly effective three-step process:

1. Allocation: The loader calls memfd_create(name, flags). This returns a file descriptor. The “name” provided is purely for debugging and does not appear in the directory tree.

2. Population: The loader writes the malicious payload (often fetched over the network) into this FD.

3. Execution: The loader calls fexecve(fd, argv, envp). The kernel replaces the current process image with the binary stored in the anonymous memory segment.

This ensures that the final payload didn’t touch the disk bypassing:

• signature-based detection that scans the disk;

• noexec restriction: many hardened systems mount world writable directories (e.g., /tmp, or /dev/shm) with the noexec flag because it’s highly being abused by threat actors since they have access to write and execute from such directories.

Example of the attack:

Consider a mount point that is mounted with noexec flag. Trying executing the id binary from that mount will not work even if it was executed with highest user privileges and the binary file itself is executable:

That restriction can be bypassed if the binary was loaded into memory and executed directly from memory. For the sake of demonstration, a web server was created hosting the id binary (could be malware in real attacks), and a simple python script was written to drop the binary into the same location, loading the binary in memory, and executing in memory bypassing all the file system security measures. Note that syscalls 319 is memfd_create():

Detection:

While there is no file on disk, the Linux kernel still maintains metadata about the running process. Look for the following:

• The /proc filesystem. Even anonymous files are tracked in the process metadata. The /proc/[PID]/exe typically points to the path of the binary like /usr/bin/python3. A memfd process will point to a virtual path, often labeled memfd: (deleted).

• Memory maps. Analyzing /proc/[PID]/maps or smaps provides the smoking gun. Look for memory segments with executable permissions (r-xp) that are mapped to a memfd object rather than a shared library or a known binary on disk: