Il 24 giugno 2025 un Senior ISC Handler del SANS Internet Storm Center ha pubblicato una dimostrazione tecnica che mette in luce una debolezza strutturale del monitoring su Linux: i processi malevoli possono alterare sia il nome visibile in /proc/<pid>/comm che la riga di comando in /proc/<pid>/cmdline, eludendo gli strumenti standard di enumerazione. La tecnica sfrutta meccanismi legittimi del kernel — la syscall prctl() e la sovrascrittura della memoria utente argv/environ — ed è classificata come T1036 Masquerading nel framework MITRE ATT&CK.
- Su Linux il nome processo è esposto tramite due interfacce distinte:
/proc/<pid>/comm(15 caratteri, usata dapsetop) e/proc/<pid>/cmdline(riga di comando completa, usata daps auxepgrep -f). - La syscall
prctl(PR_SET_NAME, ...)modifica il contenuto di/proc/<pid>/comm, mentre la sovrascrittura della regione contiguaargv[0..n]eenvironaltera/proc/<pid>/cmdline. - L'autore dimostra il mascheramento effettivo del processo come
[kworker/0:1-events], nome legittimo del kernel Linux, con output verificato sia inpsche inps aux. - Il tool eBPF Kunai rileva il path dell'eseguibile originale (
/home/remnux/ps-masquerade) ma non il nome diexeciniziale, lasciando un gap di visibilità.
Due facce dello stesso processo: comm e cmdline
Il kernel Linux espone il nome di un processo attraverso due file virtuali in /proc. /proc/<pid>/comm contiene al massimo 15 caratteri ed è la sorgente che alimenta ps, top e le ricerche per nome. /proc/<pid>/cmdline invece riporta la riga di comando completa, inclusi argomenti, ed è consultata da ps aux, pgrep -f e strumenti di threat hunting basati su matching di stringhe.
La fonte sottolinea un punto critico: queste due interfacce sono indipendenti e entrambe manipolabili. La modifica di comm avviene tramite la syscall prctl(PR_SET_NAME, ...), documentata nel manuale del kernel Linux. La modifica di cmdline richiede invece un intervento più invasivo: poiché argv[0] è un buffer a dimensione fissa e non un puntatore rilocabile, è necessario sovrascrivere l'intera regione contigua che include argv e environ, calcolando l'offset finale come end=argv[i]+strlen(argv[i])+1 e azzerando la memoria fino a quel limite.
"argv[0] is a fixed-size buffer! You can't just point it somewhere else, because the kernel reports the original memory region" — Senior ISC Handler, SANS ISC
La dimostrazione: da processo utente a falso kworker
L'autore ha implementato un proof-of-concept in C che applica entrambe le tecniche in sequenza. La prima chiamata è prctl(PR_SET_NAME, "kworker/0:1", 0, 0, 0), che popola /proc/<pid>/comm con un nome plausibile. Segue la funzione set_cmdline() che sovrascrive argv e environ con la stringa [kworker/0:1-events].
Il risultato è documentato con screenshot di terminale: il processo con PID 130888, originariamente lanciato dall'utente remnux, appare in ps e in ps aux come [kworker/0:1-events]. Nessun indicatore visibile rivela la discrepanza. L'esempio è stato scelto con cura: kworker è un thread legittimo del kernel, presente su ogni sistema Linux, raramente oggetto di scrutinio manuale.
La tecnica è citata dalla fonte come istanza della T1036 Masquerading nel framework MITRE ATT&CK. Nel paragrafo introduttivo l'autore menziona il gruppo cinese Velvet Ant come esempio di utilizzo di masquerading in campagne reali, ma il dossier non fornisce dettagli specifici su questa correlazione né afferma che Velvet Ant impieghi proprio questa implementazione Linux.
I limiti dell'eBPF: Kunai vede ma non ricostruisce
La fonte testa il processo mascherato con Kunai, strumento di rilevamento basato su eBPF. Il JSON di output mostra il path dell'eseguibile originale — /home/remnux/ps-masquerade — con un campo error: 'file not found' e una catena di ancestor che traccia l'esecuzione. Questo conferma che l'eBPF, operando a livello di kernel tracepoint, può risalire all'inodo e al percorso del file eseguito indipendentemente dalla mascheratura in spazio utente.
C'è però una limitazione documentata. Secondo la citazione diretta dell'autore: "A good news is that tools like Kunai (based on eBPF) will catch the real command line but won't be able to find back the exec name". Il tool rileva l'eseguibile originale e la linea di comando reale, ma non può ricostruire il nome dell'esecuzione iniziale — il parametro passato al sistema operativo al momento del execve(). Questo crea un divario di visibilità rilevante per gli analisti SOC: la correlazione temporale tra il nome di lancio e il comportamento successivo resta parzialmente oscurata.
Il dossier non specifica se Kunai o altri tool eBPF possano rilevare in tempo reale la sovrascrittura di cmdline come evento anomalo, piuttosto che semplicemente constatarne gli effetti a posteriori.
Cosa fare adesso
Per i team che monitorano sistemi Linux, la dimostrazione impone tre aggiustamenti concreti al workflow di threat hunting.
Primo: verificare la coerenza tra /proc/<pid>/comm, /proc/<pid>/cmdline e il path dell'eseguibile in /proc/<pid>/exe prima di classificare un processo come benigno. Un kworker legittimo non ha un eseguibile utente in /home.
Secondo: integrare Kunai o strumenti eBPF equivalenti per tracciare il path reale dell'eseguibile, sapendo che il gap sul nome di exec iniziale persiste. Il rilevamento dell'eseguibile originale rimane valido, ma non chiude completamente la catena di provenienza.
Terzo: trattare con sospetto i processi che mostrano nomi kernel come kworker ma eseguono da path utente o presentano cmdline con parentesi quadre in formati non standard del kernel. La fonte non fornisce regole di detection preconfezionate, ma la logica di confronto multi-interfaccia è applicabile immediatamente.
La lettura: quando il nome è solo un'etichetta
La forza di questa dimostrazione sta nell'esposizione di un'assunzione implicita: che il nome processo sia un identificatore attendibile. Su Linux questa assunzione è strutturalmente fragile perché il kernel offre meccanismi legittimi per modificarlo, e gli strumenti di enumerazione standard non validano la coerenza tra nome, eseguibile e riga di comando. La migrazione verso eBPF migliora la visibilità sull'eseguibile originale, ma non chiude completamente il gap, specialmente per il nome di exec iniziale.
Per i team di threat hunting, l'implicazione è che le whitelist basate su nomi processo — operazioni comuni nei SOC che cercano di filtrare kworker o altri thread kernel come benigni per definizione — richiedono integrazione con controlli di integrità dell'eseguibile e analisi comportamentale. La fonte non specifica quali controlli di integrità siano preferibili né come implementarli.
FAQ
Il mascheramento richiede privilegi di root?
La fonte non lo specifica esplicitamente, ma prctl(PR_SET_NAME) e la sovrascrittura della propria memoria argv sono operazioni che un processo può compiere su se stesso in spazio utente. Non è richiesta escalation di privilegi per modificare il proprio nome visibile.
La tecnica è specifica di una distribuzione Linux?
No. Il meccanismo si basa su interfacce standard del kernel Linux — /proc, prctl(), layout di memoria argv/environ — e non è vincolato a una distribuzione specifica. La dimostrazione è stata eseguita su un sistema REMnux, ma il codice è portabile.
L'eBPF può rilevare il momento esatto della sovrascrittura?
Il dossier non lo documenta. Kunai rileva l'eseguibile originale e la linea di comando reale, ma non è chiaro se generi un evento specifico quando rileva la manomissione di cmdline in corso, piuttosto che registrare lo stato risultante.
Fonti
- https://isc.sans.edu/diary/rss/33102
- https://isc.sans.edu/diary/An+Example+of+Stack+String+in+High+Level+Language/33008
- https://attack.mitre.org/techniques/T1036/
- https://man7.org/linux/man-pages/man2/prctl.2.html
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.