Sovrascrittura Argomenti di Processo: Overwrite Process Arguments (T1036.011)

La simulazione di T1036.011 in un contesto di red team è concettualmente semplice ma richiede attenzione ai dettagli implementativi. Il principio operativo si basa sul fatto che il kernel Linux espone la regione arg_start-arg_end del processo (visibile in /proc/<PID>/stat) come memoria scrivibile dal processo stesso.

Un proof-of-concept minimale in C sfrutta direttamente argv[0] all'avvio del programma. Dopo aver salvato la lunghezza cumulativa originale degli argomenti, si azzera l'intera regione con memset(argv[0], 0, total_len) e si scrive la stringa di spoofing con strncpy(argv[0], "/sbin/udevd -d", total_len - 1). È fondamentale non eccedere la lunghezza originale, altrimenti si corrompe l'environment adiacente in memoria.

In Python il pattern equivalente si realizza con la libreria setproctitle (open source), che incapsula la logica di manipolazione di argv[0] e gestisce anche la primitiva prctl(PR_SET_NAME) per il nome del thread. Un'invocazione tipica è setproctitle.setproctitle("dbus-daemon --system") eseguita subito dopo l'avvio dello script. Per Go esiste una logica analoga tramite manipolazione diretta di os.Args[0] combinata con syscall a basso livello.

Una catena d'attacco realistica in laboratorio prevede tre passaggi. Prima si ottiene l'esecuzione iniziale, ad esempio tramite un payload dropped da una web shell in una VM di test. Il payload, all'avvio, invoca la routine di rewriting di argv[0] scegliendo un nome coerente con il contesto (un host di produzione ha tipicamente systemd-journald, dbus-daemon, rsyslogd attivi). Infine si valida l'efficacia della mimetizzazione confrontando l'output di ps auxf con quello di cat /proc//cmdline e cat /proc//comm: quest'ultimo, alimentato dalla struttura task_struct del kernel e non dalla memoria user-space, può divergere dal cmdline manipolato e diventare un tell-tale sign.

Per emulare specificamente BPFDoor in ambiente controllato si può utilizzare Atomic Red Team (open source), che include test procedurali per varie sottotecniche di masquerading, oppure costruire un binario custom che replichi il pool di dieci nomi hardcoded documentato. È essenziale eseguire questi test in VM isolate e ripulire gli artefatti al termine dell'esercizio, poiché la persistenza di processi con nomi spoofati può confondere anche gli operatori legittimi del laboratorio.

La detection di T1036.011 richiede visibilità sia sui syscall che sullo stato interno dei processi, poiché il fenomeno è per definizione invisibile agli strumenti che si affidano al solo /proc/<PID>/cmdline. La strategia DET0164 documentata identifica tre segnali correlabili: sequenze anomale di byte nulli nella regione argv, discrepanze tra cmdline e ancestry del processo, e write in memoria immediatamente successive alla creazione del processo.

La fonte di telemetria primaria è auditd (open source), configurato per tracciare le syscall rilevanti. Regole utili includono il monitoraggio di execve per costruire la baseline del comando originale al momento del fork+exec, che rappresenta la verità storica contro cui confrontare successive letture di /proc. Una regola di esempio è -a always,exit -F arch=b64 -S execve -k proc_exec, che popola il campo proctitle con la riga di comando reale all'avvio.

La detection strategy suggerisce anche l'uso di eBPF tracepoints, implementabili con framework come bpftrace (open source) o Falco (open source). Falco in particolare permette di scrivere regole dichiarative che confrontano proc.cmdline con proc.exe e proc.pname: se un processo il cui eseguibile risolto via /proc/<PID>/exe è /tmp/xyz ma il cui cmdline recita /sbin/udevd -d, la discrepanza è un indicatore ad alta confidenza. Anche Sysmon for Linux (open source) fornisce eventi di process creation con il cmdline originale, utili per confronto retrospettivo.

Un approccio complementare consiste nel confrontare periodicamente /proc/<PID>/comm (nome del task nel kernel, limitato a 15 caratteri) con /proc/<PID>/cmdline. Le divergenze non sono di per sé malevole ma restringono drasticamente il set da analizzare. Altrettanto significativa è la coerenza tra /proc/<PID>/exe (link simbolico al binario reale) e il nome mostrato: un processo che si dichiara dbus-daemon ma il cui exe punta a un percorso in /tmp, /dev/shm o home directory utente è quasi certamente malevolo.

Sui falsi positivi occorre modellare con cura il tuning documentato: alcune applicazioni legittime (interpreti come Python con setproctitle, server come PostgreSQL e Nginx che rinominano i worker) modificano intenzionalmente argv[0]. La whitelist ParentExecutableTrustList deve includere questi casi noti, mentre AllowedArgvMismatchPatterns filtra i pattern ricorrenti in packaging quirks. La TimeWindow definisce la finestra temporale post-fork entro cui la modifica è attesa: manipolazioni tardive, ore o giorni dopo l'avvio, sono statisticamente più sospette e meritano priorità di triage superiore.

L'analisi forense di T1036.011 su un host Linux compromesso richiede di ricostruire la verità storica del processo bypassando le informazioni cosmetiche esposte in user-space. La prima raccolta prioritaria, se il sistema è ancora attivo, è un dump completo di /proc per ogni processo sospetto: cmdline, comm, exe, maps, status, environ, stat. Il confronto tra questi file rivela immediatamente le incoerenze introdotte dalla tecnica.

L'artefatto più affidabile è il link /proc/<PID>/exe, che punta all'inode del binario realmente in esecuzione anche se il file è stato cancellato dal filesystem (in tal caso il link mostra il suffisso (deleted)). Copiare questo link con cp /proc//exe /evidence/binary_ permette di recuperare il binario originale per successiva analisi statica, anche quando l'attaccante ha rimosso il dropper. Il campo Name: in /proc/<PID>/status fornisce il nome del task come registrato dal kernel, spesso divergente dal cmdline manipolato.

Sul fronte log, i record di auditd in /var/log/audit/audit.log conservano gli eventi SYSCALL di tipo execve con il campo proctitle codificato in esadecimale, che rappresenta la riga di comando reale al momento dell'esecuzione. La decodifica con ausearch -i o aureport permette di ricostruire la timeline autentica delle esecuzioni. Se disponibile, il journal di systemd (journalctl _COMM=) può fornire correlazioni aggiuntive per processi lanciati come unit.

Per analisi post-mortem su immagini di memoria, Volatility 3 (open source) con il plugin linux.psaux estrae gli argomenti di processo dalla struttura mm_struct del kernel: poiché la lettura avviene direttamente dallo spazio kernel e non da /proc, la manipolazione dell'attaccante è comunque visibile ma può essere confrontata con altri artefatti in memoria (VMA, heap, stack) per identificare la stringa originale sopravvissuta prima dell'azzeramento.

La timeline di un incidente che coinvolge BPFDoor presenta segnali caratteristici: comparsa di un processo con nome coincidente con uno dei dieci demoni hardcoded (/sbin/udevd -d, dbus-daemon --system, avahi-daemon: chroot helper, /sbin/auditd -n, /usr/lib/systemd/systemd-journald) ma con exe che non punta al percorso canonico atteso, presenza di socket raw o filtri BPF caricati dal processo (verificabili con ss -0 per pacchetti raw e bpftool prog list per programmi BPF attivi), e assenza del processo dai unit file di systemd nonostante il nome suggerisca un servizio di sistema. La correlazione con log di rete che mostrano traffico C2 attivato da magic packet completa il quadro attributivo.

Il dataset MITRE ATT&CK associato a T1036.011 non riporta gruppi APT formalmente attribuiti né campagne dedicate, ma documenta un singolo software di rilievo strategico: BPFDoor (S1161). L'assenza di attribuzione formale nel dataset non riflette assenza di attività, quanto piuttosto la natura elusiva della tecnica e la difficoltà di correlare implementazioni di masquerading in memoria a threat actor specifici tramite indicatori tradizionali.

BPFDoor è la manifestazione più matura e documentata dell'abuso di questa tecnica. Il malware seleziona il proprio nome cosmetico da un pool di dieci stringhe hardcoded che riproducono con precisione la nomenclatura di demoni Linux ubiqui in ambienti di produzione: /sbin/udevd -d (gestore hotplug device), dbus-daemon --system (bus di messaggistica IPC), avahi-daemon: chroot helper (mDNS/zeroconf), /sbin/auditd -n (audit framework, particolarmente ironico data la sua funzione), e /usr/lib/systemd/systemd-journald (raccolta log del journal). La scelta di questi nomi non è casuale: sono processi presenti in praticamente ogni distribuzione Linux moderna, il cui riavvio o duplicazione raramente attira attenzione operativa.

Il pattern operativo di BPFDoor combina T1036.011 con l'abuso di filtri Berkeley Packet Filter per implementare un listener passivo che non apre porte TCP, evadendo così la detection basata su enumerazione di socket in ascolto. Questa combinazione rende il masquerading non un semplice espediente cosmetico ma un tassello di una strategia coerente di low-observability persistence, particolarmente efficace su server esposti a lungo termine come gateway, load balancer e sistemi di telecomunicazione.

La telemetria pubblica disponibile su BPFDoor indica un utilizzo prevalente contro target nei settori telecomunicazioni, logistica ed educazione, con particolare concentrazione in region asiatica e mediorientale. La persistenza pluriennale osservata su alcuni host compromessi, in taluni casi superiore ai cinque anni prima della scoperta, dimostra l'efficacia della combinazione tra masquerading in memoria e listener passivo BPF nell'eludere audit periodici.

A livello di trend strategico, la tecnica T1036.011 è indicativa di una maturazione degli attaccanti sofisticati verso approcci Linux-native che sfruttano peculiarità architetturali del sistema operativo piuttosto che tecniche portate da altri ecosistemi. Ci si può aspettare un'espansione dell'uso di questa tecnica da parte di attori che operano nel segmento server-side, in particolare per campagne di lunga durata contro infrastruttura critica dove la mimetizzazione tra processi di sistema legittimi è più preziosa della velocità operativa. Il fatto che la tecnica non richieda privilegi elevati la rende inoltre attraente anche per fasi iniziali di compromise, non solo per persistenza root-level.

MITRE ATT&CK: T1036.011 Overwrite Process Arguments, tattica TA0005 Defense Evasion. Software: S1161 BPFDoor. Detection strategy DET0164 con analytic AN0466 (Linux) basata su auditd SYSCALL ed eBPF tracepoints. Riferimenti a MITRE D3FEND per artefatti di processo e strategie di detection basate su Process Analysis. Parti tecniche relative a comandi, tool (setproctitle, Falco, bpftrace, Sysmon for Linux, Volatility 3, Atomic Red Team) e procedure operative derivano da conoscenza professionale di cybersecurity Linux e forensic analysis.