Supply chain attack su 400 pacchetti Arch Linux: analisi tecnica del malware Atomic Arch e come scoprirlo

La campagna Atomic Arch segna uno degli incidenti supply chain più rilevanti mai osservati nell’ecosistema Arch Linux, non perché abbia violato i repository ufficiali della distribuzione, ma perché ha sfruttato il punto più fragile e al tempo stesso più identitario della sua comunità: l’Arch User Repository, il grande spazio collaborativo in cui gli utenti condividono script di build, pacchetti non ufficiali e software mantenuto dalla community. L’attacco emerge tra l’11 e il 12 giugno 2026 e coinvolge centinaia di pacchetti AUR, con stime iniziali superiori a 400 pacchetti e analisi successive che ipotizzano una superficie più ampia, fino a circa 1.500 pacchetti collegati a più ondate di attività. Gli aggressori non creano pacchetti nuovi da promuovere artificialmente, ma adottano pacchetti orfani, conservano nomi e storia apparente e modificano i file PKGBUILD o gli hook di installazione per scaricare dipendenze malevole da npm o tramite Bun. Il payload principale, distribuito attraverso atomic-lockfile 1.4.2, esegue un binario ELF Linux chiamato deps, scritto in Rust, con funzioni da infostealer, persistenza tramite systemd, esfiltrazione HTTP e capacità opzionali di rootkit eBPF quando viene eseguito con privilegi sufficienti. Il risultato è una campagna che colpisce direttamente workstation di sviluppatori, ambienti di build e sistemi Linux usati per accedere a repository, token, chiavi SSH, credenziali GitHub, npm, Vault, browser, applicazioni Electron, Slack, Discord, Microsoft Teams, Docker, Podman e servizi API sensibili.

AUR diventa il vettore ideale per ereditare fiducia già costruita

Il cuore dell’attacco non è una vulnerabilità zero-day, ma l’abuso di un modello di fiducia. AUR funziona come repository comunitario in cui gli utenti pubblicano ricette di build, script e metadati utili a compilare o installare software non presente nei repository ufficiali di Arch Linux. Quando un pacchetto viene abbandonato, può diventare orfano ed essere adottato da un nuovo maintainer. Atomic Arch sfrutta esattamente questo processo: gli aggressori individuano pacchetti orfani, li adottano, mantengono il nome familiare e introducono modifiche minime ma decisive nei file di build. Dal punto di vista dell’utente, l’operazione può apparire come un normale aggiornamento di un pacchetto già noto; dal punto di vista dell’attaccante, invece, significa acquisire un canale di distribuzione già dotato di reputazione. La differenza rispetto a una campagna di typosquatting o brandjacking è sostanziale. Qui non si tenta di convincere qualcuno a installare un pacchetto nuovo e sospetto, ma si prende controllo di un oggetto software che ha già una storia e che molti helper AUR possono aggiornare automaticamente. È questo il tratto più insidioso della campagna: la fiducia non viene costruita, viene ereditata. Le analisi di Sonatype descrivono proprio questa dinamica, osservando che gli aggressori modificano i pacchetti adottati per eseguire l’installazione di una dipendenza npm malevola, trasformando un gesto ordinario di manutenzione in un vettore di compromissione. (sonatype.com)

Atomic-lockfile porta il malware dentro il processo di build

La prima ondata documentata della campagna utilizza il pacchetto npm atomic-lockfile 1.4.2, inserito nei processi di installazione attraverso modifiche ai pacchetti AUR compromessi. Il meccanismo è semplice e pericoloso: il file di build richiama npm install atomic-lockfile, il gestore pacchetti interpreta il file package.json, raggiunge lo script di lifecycle preinstall ed esegue il payload nativo collocato in src/hooks/deps. In questo modello, il codice dannoso non deve essere contenuto direttamente nel pacchetto AUR in modo evidente; il pacchetto AUR diventa il ponte verso una dipendenza esterna, mentre l’esecuzione automatica degli script di installazione completa la catena. L’analisi tecnica evidenzia che il layer JavaScript funge soprattutto da vettore di consegna: il vero malware risiede nel binario ELF deps, dove sono codificati esfiltrazione, persistenza, raccolta credenziali e comunicazione con il command and control. Una seconda ondata, osservata poco dopo, usa percorsi di installazione basati su Bun e pacchetti come js-digest e lockfile-js, segnale che gli operatori stanno adattando rapidamente il metodo per aggirare rimozioni e detection iniziali. Questa architettura dimostra come il confine tra ecosistemi Linux e registry JavaScript sia ormai operativo: un pacchetto AUR può diventare un trigger, npm o Bun un downloader, e un binario Linux il payload effettivo.

Deps ruba credenziali da browser, developer tool e applicazioni Electron

Il payload deps è costruito per colpire ambienti di sviluppo reali, non semplici desktop generici. L’analisi preliminare lo descrive come un credential stealer Linux con targeting molto ampio verso browser Chromium, applicazioni Electron, strumenti DevOps e materiali di accesso locale. Il malware enumera profili browser, database SQLite dei cookie, LevelDB local storage, token e sessioni riconducibili a Chrome, Edge, Brave, Opera e varianti distribuite tramite Flatpak. Parallelamente cerca dati di applicazioni come Slack, Discord, Microsoft Teams e Telegram, usando credenziali o cookie rubati anche per interrogare API remote e arricchire le informazioni sugli account compromessi. La lista dei target include GitHub, npm, HashiCorp Vault, Docker, Podman, chiavi SSH, file known_hosts, cronologie shell, configurazioni VPN, segreti locali e token legati a OpenAI o ChatGPT. Questo profilo rivela l’obiettivo operativo della campagna: non monetizzare subito l’utente finale attraverso un furto casuale, ma raccogliere credenziali ad alto valore capaci di aprire ulteriori accessi a repository, pipeline, registry, infrastrutture cloud e ambienti aziendali. In una workstation di sviluppatore, un singolo token GitHub o npm può valere più di una password consumer, perché permette compromissioni successive e distribuzione di nuovi pacchetti malevoli.

Il rootkit eBPF aumenta la gravità quando il malware gira come root

La componente più avanzata di deps è il modulo opzionale di rootkit eBPF, che non serve a ottenere privilegi ma a occultare la presenza del malware quando il processo viene già eseguito come root o con capability adeguate, in particolare CAP_BPF o CAP_SYS_ADMIN. Questa distinzione è decisiva: il rootkit non è un exploit di escalation, ma uno strato di evasione. Se il malware dispone dei privilegi necessari, carica un oggetto eBPF direttamente dalla memoria e usa mappe pinned in /sys/fs/bpf, tra cui hidden_pids, hidden_names e hidden_inodes, per nascondere processi, nomi, inode di socket e attività di rete. Gli strumenti di live response tradizionali, come ps, netstat, lsof o viste basate su /proc, possono quindi risultare incompleti sui sistemi in cui il componente è attivo. L’analisi indica anche capacità di interferire con tentativi di attach tramite ptrace verso processi nascosti, rendendo più complessa la diagnosi su host compromessi. Il dato più importante per amministratori e incident responder è che la presenza di eBPF cambia la fiducia nel sistema osservato. Se il pacchetto è stato installato con privilegi elevati o tramite helper eseguiti con privilegi impropri, la semplice rimozione del pacchetto non basta a garantire pulizia. In questi casi, la reinstallazione da supporto fidato e la rotazione completa delle credenziali diventano opzioni molto più realistiche della bonifica in-place.

Persistenza, C2 onion e temp.sh costruiscono una catena completa

Deps non si limita a eseguire una raccolta istantanea di dati. Il malware implementa persistenza, single instance, esfiltrazione e canale di comando. In modalità privilegiata copia se stesso sotto /var/lib/ con un nome generato e crea un’unità systemd in /etc/systemd/system/; in modalità non privilegiata usa la home dell’utente e unità sotto ~/.config/systemd/user/. In entrambi i casi configura Restart=always e RestartSec=30, così da riavviarsi automaticamente in caso di terminazione. Il binario applica inoltre un meccanismo di single instance con flock(), reindirizza stdin, stdout e stderr verso /dev/null, ignora SIGPIPE e avvia una macchina a stati asincrona tipica di applicazioni Rust. L’esfiltrazione avviene attraverso due livelli: upload HTTP verso temp.sh con richieste POST /upload e comunicazione con un servizio .onion tramite POST /api/agent, raggiunto attraverso un trasporto locale SOCKS-style su 127.0.0.1. Il dominio onion recuperato dagli analisti è olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion, non presente in chiaro nel binario ma decodificato tramite routine XOR. Questa architettura separa il caricamento dei dati dalla gestione di tasking e metadati, rendendo la campagna più resiliente e più difficile da analizzare con una sola vista di rete.

La scala dell’incidente supera il singolo pacchetto compromesso

La timeline mostra una campagna dinamica, non un episodio isolato. Sonatype pubblica l’analisi iniziale l’11 giugno 2026, collegando Atomic Arch a pacchetti orfani AUR e a atomic-lockfile; nelle ore successive emergono ulteriori pacchetti malevoli, meccanismi alternativi basati su Bun e stime crescenti sulla superficie colpita. IFIN riporta oltre 408 pacchetti compromessi e segnala che i maintainer AUR ritengono di aver rimosso i commit malevoli entro il 12 giugno alle 17:30 UTC, mentre liste comunitarie e gist indicano numeri intorno a 446 pacchetti in alcuni controlli pubblici. Sonatype avverte però che attività successive potrebbero portare il totale potenziale verso circa 1.500 pacchetti in più ondate, con conteggi ancora soggetti a revisione. Questa incertezza è tipica degli incidenti supply chain su repository comunitari: il perimetro cambia mentre la comunità analizza commit, account, dipendenze, script e pacchetti adottati. Esempi citati nelle discussioni includono pacchetti come alvr, premake-git, jd-gui e libgdata, ma l’elenco resta fluido e non va considerato definitivo senza verifiche aggiornate. Il punto politico e tecnico è che la risposta non riguarda solo la rimozione di un pacchetto npm malevolo, perché l’attacco ha dimostrato la possibilità di automatizzare l’adozione di fiducia e di riutilizzare pacchetti apparentemente legittimi come infrastruttura di distribuzione.

Gli utenti Arch devono verificare esposizione e ruotare credenziali

Per gli utenti Arch Linux, la distinzione più importante è tra repository ufficiali e AUR. I pacchetti ufficiali di Arch non risultano compromessi da questa campagna; l’incidente riguarda il repository utente e i pacchetti costruiti tramite workflow comunitari. Chi non usa Arch o non installa pacchetti AUR non rientra nel perimetro diretto dell’incidente. Chi invece ha aggiornato pacchetti AUR tra il 9 e il 12 giugno 2026 deve verificare l’esposizione confrontando i pacchetti installati con gli elenchi comunitari aggiornati, evitando però di eseguire ciecamente script scaricati da Internet senza ispezionarli magari consultando questa lista messa a disposizione come prima risposta. Le raccomandazioni operative sono nette: se il binario deps è stato eseguito, l’host va trattato come compromesso; vanno ruotati token GitHub, npm, Vault, chiavi SSH, credenziali Docker, Podman, cookie browser, sessioni applicative e account di collaborazione; in caso di esecuzione privilegiata o sospetto rootkit eBPF, bisogna preservare evidenze con strumenti fidati, ispezionare /sys/fs/bpf/ alla ricerca di mappe sospette, controllare unità systemd anomale, verificare log proxy verso temp.sh e traffico Tor/SOCKS, e valutare seriamente la reinstallazione del sistema. La risposta deve includere anche un controllo sugli ambienti a valle: se il sistema compromesso aveva accesso a repository, registry o pipeline CI/CD, l’incidente non resta confinato alla workstation ma può diventare un rischio aziendale.

Atomic Arch espone il limite strutturale della supply chain open source

La lezione di Atomic Arch non è che Arch Linux sia insicura, ma che ogni ecosistema fondato su manutenzione volontaria, pacchetti orfani e automazione della fiducia contiene una superficie d’attacco che cresce con la sua popolarità. AUR resta una risorsa preziosa e potente proprio perché permette alla comunità di distribuire rapidamente software non disponibile nei repository ufficiali, ma questa libertà implica responsabilità operativa. Gli utenti che installano pacchetti AUR non scaricano binari ufficialmente revisionati dalla distribuzione: eseguono script di build scritti e mantenuti da terzi. In un contesto in cui gli aggressori puntano sempre più a sviluppatori, maintainer e ambienti di build, questo modello richiede controlli più severi, review manuale dei PKGBUILD, diff degli aggiornamenti, limitazione dei privilegi, isolamento delle build, uso prudente degli helper e rotazione periodica dei segreti. La presenza di un infostealer con capacità rootkit eBPF mostra che gli attacchi supply chain non sono più semplici proof of concept o furti opportunistici, ma operazioni capaci di combinare abuso di repository, registry JavaScript, persistenza Linux, occultamento kernel e raccolta mirata di credenziali DevOps. Atomic Arch diventa così un caso di scuola: gli aggressori non hanno bisogno di violare il cuore di una distribuzione quando possono colpire la periferia fiduciaria su cui gli utenti costruiscono ogni giorno il proprio ambiente di lavoro.