Masquerading Linux: quando ps mente e eBPF…

Un post SANS ISC mostra come prctl e la sovrascrittura di argv rendano inaffidabili ps e top su Linux, e perché solo eBPF come Kunai traccia l'eseguibile reale.

Un Senior ISC Handler del SANS Internet Storm Center ha pubblicato un'analisi tecnica che dimostra come gli strumenti standard di monitoraggio processi su Linux — ps, top, htop — possano essere ingannati da tecniche di masqueramento documentate. Il post, di natura didattica ed espositiva, non riporta threat intelligence attiva né campagne specifiche: è una lezione su un meccanismo strutturale del kernel Linux.

Punti chiave

Su Linux il nome processo risiede in due locazioni: /proc/<pid>/comm (15 caratteri max, usato da ps e top) e /proc/<pid>/cmdline (argv completo, usato da ps aux).
prctl(PR_SET_NAME) modifica comm; per alterare cmdline è necessario sovrascrivere il buffer argv[0] e, se insufficiente, propagarsi nella regione contigua argv[1..n] e environ.
L'autore ha dimostrato il mascheramento come [kworker/0:1-events], nome tipico di kernel worker thread.
Tool eBPF come Kunai rilevano il vero percorso dell'eseguibile (exe.path) ma non recuperano il nome originale dell'exec se il file è stato rimosso.

Il doppio canale che inganna gli strumenti standard

La fonte distingue con precisione i due canali di naming del kernel Linux. /proc/<pid>/comm è un campo di 15 caratteri che il kernel espone per tutti i processi; ps e top lo leggono per mostrare il nome breve. /proc/<pid>/cmdline contiene l'intera linea di comando, cioè il vettore argv passato al momento dell'execve.

La differenza implementativa è critica: comm è modificabile via prctl(PR_SET_NAME, ...) con una sola chiamata di sistema. Il codice C mostrato dalla fonte imposta il nome "kworker/0:1" e l'output di ps mostra [kworker/0:1-events], con le parentesi quadre tipiche dei kernel thread. Un analista che si fidi solo del nome visivo classificherà il processo come legittimo.

cmdline è più complesso da alterare. La fonte specifica che argv[0] è un buffer a dimensione fissa: non è possibile riallocarlo o puntarlo altrove, perché il kernel riporta la regione di memoria originale. Per superare questo vincolo, il codice deve sovrascrivere i byte contigui che seguono argv[0], invadendo argv[1..n] e eventualmente environ, azzerando la zona interessata. Questa operazione lascia tracce strutturali — la linea di comando risulta anomala o troncata — ma strumenti che non verificano la coerenza interna la possono ignorare.

Il meccanismo prctl e le sue limitazioni di rilevamento

L'uso di prctl(2) con l'argomento PR_SET_NAME è documentato nel manuale Linux ufficiale, citato come fonte di contesto. La system call è legittima: servizi e applicazioni la usano per identificare i propri thread. La sua dualità — funzione utile ma abusabile — è ciò che rende il rilevamento basato su nome processo fondamentalmente inaffidabile.

La fonte cita MITRE ATT&CK T1036, Masquerading, come framework di classificazione della tecnica. Il riferimento colloca il mascheramento tra le tattiche ricorrenti di APT cinesi, russi, iraniani e altri. Il post SANS menziona "Velvet Ant Chinese group", ma il riferimento bibliografico non è risolvibile con le fonti fornite; non è quindi verificabile l'uso specifico di questa implementazione prctl/argv da parte di quel gruppo.

"When you list running processes on a computer, can you trust what you see?"
— Senior ISC Handler, SANS Internet Storm Center

Il test pratico dell'autore, eseguito su sistema REMnux in ambiente di laboratorio controllato, mostra il processo mascherato con PID 130888. L'esperimento è proof-of-concept dell'autore, non malware in-the-wild: manca verifica indipendente che il codice sia stato osservato in malware attivo. La data di pubblicazione del post non è specificata nelle fonti come originale del 24 giugno 2025 o ripubblicazione di analisi precedenti.

Perché eBPF cambia (parzialmente) la partita

La fonte introduce Kunai come esempio di strumento eBPF che aggira parzialmente il problema. A differenza di ps e top, che leggono i file /proc generati dal kernel in user space, Kunai intercetta le chiamate a livello kernel e traccia il percorso reale dell'eseguibile tramite il campo exe.path.

L'output JSON mostrato dalla fonte è esplicito: il percorso è /home/remnux/ps-masquerade, con error: "file not found" a indicare che il file è stato rimosso dopo l'esecuzione. Gli ancestors rivelano la catena di esecuzione reale. Tuttavia, la fonte sottolinea un limite: se l'eseguibile è cancellato, Kunai "won't be able to find back the exec name". Il nome originario dell'exec non è recuperabile, anche se la catena di provenienza lo identifica indirettamente.

Non è specificato se Kunai generi alert automatici o richieda analisi manuale dei log. Il dossier non quantifica la diffusione di questa tecnica in campagne attive nel 2025.

Cosa cambia

La lezione del post SANS è strutturale, non operativa: i nomi di processo letti da ps e top sono output del kernel che l'utente può alterare. Questo non è una vulnerabilità da patchare ma una caratteristica del design Linux, con implicazioni per chiunque usi quei nomi come input di sicurezza.

La fonte non specifica mitigazioni a livello kernel né raccomanda architetture di rilevamento specifiche. Il valore del pezzo sta nel documentare un gap: strumenti che leggono /proc in user space vedono ciò che il processo decide di mostrare, mentre strumenti eBPF che intercettano sched:sched_process_exec vedono il percorso dell'eseguibile al momento dell'esecuzione — con il limite, documentato, che il nome originale è perso se il file viene rimosso.

Il contrasto con Windows è netto e citato dalla fonte: su Windows il PEB è scrivibile in userland ma i campi kernel EPROCESS non sono modificabili da user mode. Su Linux, entrambi i canali sono tecnicamente alterabili dal processo stesso.

Limiti e contesto

Questo articolo si basa su un'unica fonte primaria strutturata: il diary del SANS Internet Storm Center. Le tecniche descritte sono documentate ma non è verificata la loro diffusione in campagne attive nel 2025. Il codice mostrato è proof-of-concept didattico, non malware in-the-wild. Non sono presenti indicatori di compromissione (IOC) né campagne specifiche documentate.

Il riferimento a "Velvet Ant Chinese group" non è verificabile con le fonti fornite. Il PID 130888 è un esempio di test pratico dell'autore, non un IOC. Il sistema REMnux è un ambiente di laboratorio controllato, non un sistema di produzione compromesso.

La fonte non specifica se Kunai generi alert automatici sul mascheramento né quantifichi la diffusione reale della tecnica. Le implicazioni operative per team SOC o Blue Team non sono parte del brief originale: il post è analisi didattica, non report di threat intelligence attiva.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti