Un nuovo diario tecnico del SANS Internet Storm Center, pubblicato mercoledì 24 giugno, dimostra con codice sorgente come i processi malevoli su Linux possano mascherarsi effettivamente come [kworker/0:1-events] — nome legittimo di un kernel worker thread — manipolando simultaneamente prctl(PR_SET_NAME) e la memoria contigua argv/environ. Il problema non è teorico: Sygnia ha documentato l'uso operativo di questa stessa tecnica nella campagna APT Velvet Ant, con binari che si spacciavano per [khubd] e smbd -D. La rivelazione più scomoda per i team di sicurezza è che i tool eBPF moderni come Kunai individuano il path reale dell'eseguibile, ma non riescono a recuperare il nome originale dell'exec.
- Il nome processo in
ps/topsu Linux deriva da/proc/<pid>/comm, limitato a 15 caratteri, modificabile viaprctl(PR_SET_NAME)senza privilegi speciali. - Per alterare
/proc/<pid>/cmdline— letto daps aux— il malware deve sovrascrivere la memoria contigua diargv[1..n]eenviron, azzerando l'intera regione perchéargv[0]è buffer a dimensione fissa. - Il PoC SANS mostra mascheramento completo come
[kworker/0:1-events], nome indistinguibile da un thread kernel legittimo in una lista processi. - Kunai, tool eBPF di rilevamento, espone il path reale dell'eseguibile (
/home/remnux/ps-masquerade) ma non il nome originale dell'exec, lasciando un gap di attribuzione nel flusso di esecuzione. - Velvet Ant, APT a nesso cinese, ha applicato questa tecnica in campo nel 2016, sovrascrivendo
argv[0]con[khubd]per un proxy SOCKS5 camuffato dasmbd -D.
Il doppio strato del mascheramento: comm e cmdline
La prima componente del trucco è prctl(PR_SET_NAME), la syscall documentata nelle man page Linux che permette a un processo di ridefinire il proprio nome in /proc/<pid>/comm. Questo campo è quello che top, htop e ps -ef mostrano per default, ed è limitato a 15 caratteri — esattamente come il campo ImageFileName in Windows, come nota l'autore del diario SANS.
Il risultato: un processo malevolo può chiamarsi [kworker/0:1] e apparire, a colpo d'occhio, come un thread del kernel.
La seconda componente è più aggressiva. ps aux legge /proc/<pid>/cmdline, che deriva dall'array argv passato al execve. Qui entra in gioco una limitazione strutturale del formato: argv[0] è un buffer a dimensione fissa.
Per sovrascriverlo, il malware non può semplicemente scrivere un nome più lungo: deve azzerare l'intera regione contigua che include argv[1], argv[2], ... argv[n] e le variabili d'ambiente environ, poi copiare il nome fasullo in quella memoria spazzata.
Il codice sorgente del PoC SANS mostra questo meccanismo esplicitamente: un ciclo che azzera tutta la memoria da argv[i] + strlen(argv[i]) + 1 in poi, poi la sovrascrittura con il nome fittizio. Il nome scelto è deliberatamente credibile: [kworker/0:1-events], con le parentesi quadre che imitano la convenzione di naming dei kernel thread in Linux.
Il gap di Kunai: eBPF vede il file, non la storia
La buona notizia, secondo il diario, è che i tool eBPF come Kunai rilevano il percorso reale dell'eseguibile: nel test dell'autore, il JSON di output mostra "exe": {"path": "/home/remnux/ps-masquerade"}. La cattiva notizia è che Kunai non recupera il nome originale dell'exec — l'argomento passato al momento della execve prima della manipolazione.
La catena di ancestor process è visibile, ma il nome originale del binario al momento del lancio resta perso.
Questo crea un problema operativo per i team di sicurezza: un allarme basato solo su "nome processo sospetto" può essere aggirato, ma anche un allarme basato su "path eseguibile" richiede una baseline di eseguibili legittimi. Se l'attaccante deposita il binario in una directory poco monitorata, l'unico indizio di anomalia resta il comportamento post-esecuzione, non l'identità dichiarata al momento del lancio.
Da Velvet Ant al PoC: la tecnica in campo
La tecnica non è una curiosità di laboratorio. Sygnia, nella sua analisi della campagna Operation Highland, ha documentato che Velvet Ant — gruppo a nesso cinese attivo dal 2016 — sovrascriveva il proprio argv[0] con [khubd], un nome che imita un thread kernel USB legittimo.
Il proxy SOCKS5 usato per la comunicazione C2 era invece camuffato da smbd -D, il demone Samba. La classificazione MITRE ATT&CK T1036 (Masquerading) racconta decine di campagne analoghe, ma il dettaglio Linux resta meno documentato del corrispettivo Windows.
Il diario SANS collega esplicitamente il proprio PoC a questa casistica operativa: il meccanismo argv[0] + prctl è lo stesso che Velvet Ant ha impiegato in campo, anche se il gruppo APT non necessariamente usa prctl — la sovrascrittura di argv[0] da sola è sufficiente per ingannare ps.
Cosa fare adesso
I team di sicurezza devono agire su tre fronti specifici, derivati direttamente dai limiti documentati nel brief.
Primo: verificare che i tool di rilevamento eBPF in uso — Kunai o equivalenti — siano configurati per loggare il campo exe.path e la catena ancestors, non solo il nome processo corrente. Il brief mostra che Kunai espone /home/remnux/ps-masquerade nel JSON: questa telemetria deve essere integrata nelle regole di alerting, con baseline dei path eseguibili per utente e per host.
Secondo: i filtri su ps, top o htop come unico criterio di autorizzazione o monitoring sono ora inaffidabili. Le policy che autorizzano connessioni di rete, accesso a file o privilegi in base al nome processo devono essere ricalibrate per usare l'identità del file eseguibile (inode, path canonicalizzato, o hash) anziché il nome dichiarato a runtime.
Terzo: il brief non documenta patch di sistema o configurazioni kernel che impediscano la manipolazione di argv[0]. prctl e la sovrascrittura di argv sono meccanismi legittimi del kernel Linux, non vulnerabilità. Non esiste CVE da correggere, né versione kernel che li disabiliti. La difesa rimane nel rilevamento comportamentale, non nella prevenzione per configurazione.
Il vero nodo: autenticazione basata sul nome processo
La conseguenza più immediata è per i sistemi di autorizzazione che usano il nome processo come identificatore. Container runtime, policy SELinux, regole AppArmor o semplici script di monitoring che filtrano su ps sono vulnerabili a questo mascheramento.
Non è richiesta exploitazione di zero-day né escalation di privilegi: un processo utente normale può eseguire entrambe le operazioni.
L'impatto per gli sviluppatori di tool di sicurezza è altrettanto chiaro. Il rilevamento eBPF ha dimostrato il suo valore nel vedere oltre il nome fittizio, ma il gap sul nome originale dell'exec è un promemoria che la telemetria è sempre una ricostruzione parziale.
La catena di esecuzione è più affidabile del singolo punto nel tempo, ma anche la catena può essere manipolata se l'attaccante controlla l'intero flusso di lancio.
La tecnica è nota da anni, classificata, eppure la sua efficacia pratica resta elevata. Il kernel worker thread è un target di impersonazione naturale perché la sua presenza è attesa, la sua attività è opaca alla maggior parte degli amministratori, e il nome con parentesi quadre lo rende immediatamente riconoscibile come "interno" al sistema.
Fingersi [kworker/0:1-events] non è un attacco sofisticato: è un'ingegneria sociale applicata al sistema operativo, che sfrutta l'attenzione limitata di chi legge ps in fretta.
"A good news is that tools like Kunai (that rely on eBPF) will catch the real command line but won't be able to find back the exec name." — Senior ISC Handler, SANS Internet Storm Center
La lettura complessiva è di una asimmetria persistente: l'attaccante ha due meccanismi a disposizione (prctl + argv sovrascrittura), mentre il difensore ha un rilevamento parziale e nessuna contromisura kernel. Fino a quando il tracciamento eBPF non recupererà l'intera storia dell'exec, il nome processo in Linux rimarrà un campo di battaglia.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
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://www.sygnia.co/blog/operation-highland-velvet-ant/
- https://man7.org/linux/man-pages/man2/prctl.2.html