Dentro l'attacco all'AUR: account fantasma, commit avvelenati e un server nascosto nella rete Tor
Di questo attacco avete letto praticamente ovunque la stessa cosa: quanti pacchetti coinvolti, quali credenziali rubate, quali portafogli svuotati. L'elenco del bottino.
È la parte meno utile della storia.
Il bottino dice cosa hai perso. Non dice perché è stato possibile perderlo, e soprattutto non ti dice se domani può ricapitare. Per saperlo bisogna guardare il meccanismo: la sequenza esatta di passaggi che porta da un comando di aggiornamento digitato distrattamente a una chiave SSH nelle mani di qualcun altro. È quello che proviamo a ricostruire qui, passo per passo, con i riferimenti pubblici che permettono di verificare ogni anello.
Partiamo da una cosa che quasi tutti hanno dato per scontata.
Non hanno violato i repository ufficiali di Arch Linux. Non hanno compromesso pacman, i server di distribuzione ufficiali o le firme dei pacchetti mantenuti dal progetto.
Hanno fatto qualcosa di più semplice: hanno sfruttato la fiducia degli utenti nell'Arch User Repository, meglio conosciuto come AUR.
L'AUR è una piattaforma comunitaria nella quale vengono pubblicati soprattutto PKGBUILD, cioè script che spiegano al sistema come scaricare, compilare e installare un programma. Il problema è strutturale, non accidentale: durante la costruzione del pacchetto questi file possono eseguire comandi sul computer dell'utente. Se qualcuno ne prende il controllo e aggiunge un comando malevolo, è l'utente stesso a lanciare l'attacco mentre crede di stare aggiornando un normale software.
Nessuno ha bucato niente. La vittima ha eseguito il codice volontariamente, con i propri privilegi, convinta di fare manutenzione ordinaria.
La catena, in sette mosse
Prima di entrare nel dettaglio conviene avere la mappa, perché la forza di questa operazione sta proprio nel fatto che ogni singolo passaggio, isolato, sembra legittimo:
- si prende il controllo di un pacchetto, adottandolo se orfano oppure creandone uno nuovo;
- si modifica lo script di installazione aggiungendo un eseguibile dal nome innocuo;
- l'eseguibile, prima di fare qualsiasi cosa, verifica di non essere osservato;
- se il campo è libero si installa in modo da sopravvivere ai riavvii;
- scarica un client Tor e lo maschera da processo di sistema;
- attraverso Tor recupera il vero malware da un server irrintracciabile;
- il malware raccoglie credenziali e prova a propagarsi via SSH sulle macchine raggiungibili.
Ognuno di questi passaggi merita di essere guardato da vicino, perché è lì che si vede la differenza tra un attacco improvvisato e uno progettato.
Il primo allarme
La storia non comincia alla fine di luglio.
L'11 giugno 2026 i ricercatori di Sonatype avevano già individuato una campagna chiamata Atomic Arch. Gli aggressori adottavano pacchetti AUR rimasti senza manutentore e ne modificavano le istruzioni di installazione, facendo scaricare dipendenze npm malevole come atomic-lockfile, js-digest e lockfile-js.
Le prime stime parlavano di alcune centinaia di pacchetti. Con l'avanzare dell'indagine, Sonatype ha indicato circa 1.500 pacchetti potenzialmente coinvolti nelle diverse ondate. Arch Linux aveva reagito limitando temporaneamente registrazioni, creazione di pacchetti, adozioni e aggiornamenti.
A fine luglio, però, gli attaccanti sono tornati. E avevano imparato qualcosa.
Questa volta non si sono limitati a richiamare una dipendenza malevola facilmente riconoscibile, cioè la cosa che chiunque legga un PKGBUILD con attenzione può notare. Hanno iniziato a inserire nei pacchetti veri e propri eseguibili Linux ELF, spesso con nomi innocui come validator, converter, parser, optimizer, hasher o bundler.
Il salto è più sottile di quanto sembri: un nome di dipendenza sospetto si cerca su un motore di ricerca in dieci secondi. Un binario chiamato validator dentro un progetto che effettivamente valida qualcosa non fa alzare nessun sopracciglio.
Il commit che ha riaperto il caso
Il primo caso confermato della nuova ondata è apparso il 29 luglio 2026 nel pacchetto AUR openconnect-sso, un wrapper utilizzato per collegarsi a VPN aziendali attraverso autenticazione SSO. Da notare la scelta del bersaglio: chi installa un client VPN aziendale è, con ottima probabilità, qualcuno che ha accesso a una rete aziendale.
Un commento pubblicato nella pagina del pacchetto avvertiva gli utenti di non installare l'ultima versione e segnalava l'esecuzione di un file chiamato validator attraverso sudo.
Da quel momento, ricercatori indipendenti e membri della comunità hanno iniziato a smontare il file pezzo per pezzo.
Il primo stadio analizzato era un eseguibile Linux x86-64 di circa 43 KB. Il suo hash SHA-256 pubblico è:
2d25d2ea313767fae5808164224cf6ad610ab09546d1e5a6f033eedbfd98a281
Il programma non partiva immediatamente con il furto dei dati. Prima controllava l'ambiente: cercava debugger, sandbox, hostname tipici dei laboratori di analisi malware e almeno 25 variabili associate a piattaforme CI/CD come GitHub Actions, GitLab CI, Jenkins e CircleCI.
In altre parole, la prima domanda che il malware si poneva non era "cosa posso rubare" ma "qualcuno mi sta guardando". Se la risposta era sì, non faceva nulla. È il motivo per cui campagne come questa restano invisibili così a lungo: si comportano bene esattamente davanti a chi le sta cercando.
Una porta nascosta dietro dbus-daemon
Superati i controlli, il loader si copiava in una directory nascosta, utilizzando un nome generato casualmente. Se disponeva dei privilegi necessari poteva collocarsi sotto /var/lib, altrimenti operava all'interno della home dell'utente.
Per sopravvivere ai riavvii creava servizi systemd, abilitava il "linger" per mantenere attivi i servizi dell'utente anche dopo il logout e aggiungeva attività cron con esecuzione automatica all'avvio. Tre meccanismi diversi per la stessa funzione: se un amministratore ne trova uno e lo rimuove, gli altri due restano.
Poi arriva la parte più interessante dell'infrastruttura.
Il malware scaricava un client Tor dall'archivio ufficiale del Tor Project, preparava una configurazione locale e lo avviava modificando il nome mostrato nella lista dei processi. Il comando passava a Tor il nome apparente dbus-daemon, imitando uno dei processi più comuni e legittimi di un sistema Linux.
Fermatevi un attimo su questo dettaglio. Quante volte, guardando l'output di ps, vi siete soffermati su dbus-daemon? È esattamente il punto: il camuffamento non punta a essere invisibile, punta a essere noioso.
Quando Tor aveva completato la connessione alla rete, il loader utilizzava il proxy SOCKS locale per contattare un indirizzo .onion inserito direttamente nel binario. Da quel server scaricava un archivio contenente il secondo stadio, salvato inizialmente come /dev/shm/.agent.bin oppure nella directory /tmp.
Dire che gli aggressori hanno "pubblicato un onion" non significa che abbiano registrato un dominio tradizionale. Un indirizzo .onion deriva crittograficamente dalla chiave del servizio e viene distribuito attraverso la rete Tor. Il server reale stabilisce soltanto connessioni in uscita verso i relay, nascondendo la propria posizione e il proprio indirizzo IP. Senza un errore operativo dell'attaccante, l'acquisizione fisica del server o dati provenienti dal provider, risalire all'operatore può essere estremamente difficile.
Ed è qui che la scelta architetturale rivela l'intenzione: separare il primo stadio dal payload vero significa che, anche quando la comunità trova e analizza il file caricato sull'AUR, il malware vero e proprio resta fuori portata, su un server che nessuno sa dove sia e che può cambiare contenuto in qualsiasi momento.
Il secondo stadio: stealer, RAT e worm SSH
Il payload finale era molto più grande: un binario Rust di circa 3,6 MB, anch'esso compilato per Linux x86-64.
Il suo SHA-256 pubblico è:
06c857c8ca798d50c765b4de39e6c4f272ecb57bc8316a8ed4c0fdf02fb59502
L'analisi lo descrive come una combinazione di tre strumenti:
- un infostealer, progettato per rubare informazioni;
- un RAT, cioè un sistema di controllo remoto;
- un worm SSH, capace di provare a propagarsi su altre macchine.
Il malware cercava password, cookie e sessioni dei browser; dati di 1Password, Bitwarden e LastPass; portafogli come Exodus, Electrum, Ledger e Trezor; token di Discord, Slack e Telegram; configurazioni AWS, Azure, Google Cloud e Kubernetes; credenziali GitHub e GitLab; file .env; token Vault; chiavi API di servizi di intelligenza artificiale; chiavi GPG e, soprattutto, chiavi private SSH.
Leggeva anche known_hosts, il file che contiene gli indirizzi dei server ai quali l'utente si è già collegato. Utilizzando le chiavi rubate, poteva tentare di copiare sé stesso sulle altre macchine attraverso scp e avviarsi in remoto con ssh.
Vale la pena esplicitare cosa significa. known_hosts non è un file di credenziali, è una comodità: serve a evitare l'avviso sull'impronta del server. Nessuno lo considera sensibile. Ma messo accanto alle chiavi private diventa la mappa: da un lato le chiavi, dall'altro l'elenco delle porte che aprono. Il malware non deve nemmeno cercare bersagli, glieli abbiamo già catalogati noi.
Un singolo portatile di uno sviluppatore diventa così l'ingresso verso server aziendali, ambienti cloud, sistemi di produzione e runner CI/CD.
Le comunicazioni con il centro di comando avvenivano attraverso Tor e un ulteriore protocollo cifrato basato su X25519, HKDF e ChaCha20-Poly1305. Nel secondo stadio è stata identificata anche una chiave pubblica X25519 fissa, che può essere usata come indicatore per collegare tra loro campioni appartenenti alla stessa infrastruttura.
Gli ultimi pacchetti e i commit rimossi
Il 30 luglio un utente della mailing list ufficiale di Arch ha pubblicato un primo elenco di pacchetti nei quali erano stati trovati eseguibili sospetti. Tra questi comparivano:
archutil/linter, boringssl-git/hasher, icloudpd/preprocessor, stirling-pdf-desktop-bin/optimizer, windscribe-cli-v2-bin/parser e magic-context-dashboard-bin/validator.
Robin Candau, membro del team DevOps di Arch Linux, ha risposto dichiarando di avere bannato gli account responsabili e annullato i commit malevoli.
Il giorno successivo sono stati segnalati altri pacchetti, tra cui i915-sriov-dkms, warp-terminal-git, weather-display, astro-box, rtk-git e diverse decine di progetti minori. Arch ha dichiarato di avere agito anche su questi.
Il 1º agosto è comparso anche un pacchetto collegato a Pandoc, pubblicato dall'account alicemarty, che includeva un file sospetto chiamato bundler. Candau ne ha confermato la cancellazione.
Nella stessa giornata sono stati segnalati altri 19 pacchetti e, poco dopo, un secondo gruppo di 27. Tra i nomi più delicati figuravano debtap-bin, hexchat-bin, aurutils-bin, paru-git, linux-cachyos-bin, openssl-1.1-bin, gtk2-bin e grub-customizer-bin.
Un particolare modifica la ricostruzione iniziale, ed è il dettaglio più importante di tutta la vicenda: Candau ha spiegato che almeno il gruppo dei 19 pacchetti non era formato da vecchi progetti orfani appena adottati. Erano pacchetti completamente nuovi, caricati appositamente dagli attaccanti.
Il 30 luglio Arch Linux aveva disabilitato l'adozione dei pacchetti orfani. Gli aggressori hanno semplicemente smesso di adottare e hanno cominciato a creare. Il 1º agosto, constatando che l'attacco continuava, il team ha bloccato completamente tutti i push verso l'AUR.
È la sequenza che racconta più di ogni analisi del binario: la difesa ha chiuso una porta e l'attacco ne ha aperta un'altra nel giro di ore, il che significa che qualcuno stava seguendo le contromisure in tempo reale e decidendo come aggirarle. Non un automatismo lanciato e dimenticato, ma una persona al lavoro.
L'ultimo stato pubblico verificabile che ho trovato risale al 2 agosto: i push risultavano ancora disabilitati e il team non forniva una data per la riapertura.
Molti commit malevoli oggi non sono più consultabili normalmente perché sono stati annullati o perché l'intero pacchetto è stato cancellato. La mailing list conserva però nomi, orari, account sospetti e nomi degli eseguibili, diventando di fatto una sorta di registro forense pubblico dell'incidente.
Gli account fantasma
Due nomi sono emersi pubblicamente: alicemarty, associato al pacchetto Pandoc, e zelmaandersen.
Il secondo account era stato creato usando un indirizzo email temporaneo e aveva adottato python-airtable-wrapper senza ancora pubblicare un aggiornamento. Un membro della comunità lo ha segnalato preventivamente e il team Arch lo ha sospeso.
È una traccia importante, ma non è un'identità.
I nomi degli account possono essere inventati, le caselle email possono essere temporanee e i dati dell'autore inseriti nei commit Git possono essere falsificati. Su quest'ultimo punto vale la pena essere chiari, perché è un equivoco diffuso: il nome che compare come autore di un commit è un campo di testo che si imposta da solo, non una prova di identità. Nella campagna di giugno erano già apparsi commit che sembravano provenire da manutentori conosciuti, anche se questi ultimi non avevano realmente eseguito il push.
Per attribuire l'attacco servirebbero informazioni non pubbliche: IP utilizzati per creare gli account o caricare i commit, access log dell'AUR, indirizzi email completi, eventuali impronte del browser, dati dei provider e collegamenti con altre infrastrutture criminali.
Chi potrebbe esserci dietro?
Non esiste, al momento, un'attribuzione pubblica a una persona, a un gruppo criminale conosciuto o a un governo.
Il movente più probabile appare economico.
Il malware cercava criptovalute, password, sessioni, credenziali cloud, token per piattaforme di sviluppo e chiavi SSH. Tutti dati immediatamente monetizzabili: possono essere venduti, utilizzati per rubare fondi, sfruttati per compromettere aziende oppure impiegati in ulteriori attacchi alla supply chain.
La capacità di muoversi attraverso SSH suggerisce inoltre che l'obiettivo non fosse soltanto il singolo utente Arch, ma l'intera rete professionale accessibile dal suo computer. Detto altrimenti: non stavano attaccando persone, stavano attaccando le aziende per cui quelle persone lavorano.
Gli elementi tecnici fanno pensare ad almeno un operatore con buone competenze su Linux e sulla supply chain: il malware usa Rust, crittografia moderna, tecniche per accorgersi di essere analizzato, rilevamento delle sandbox, servizi systemd, cron, Tor e propagazione SSH.
È possibile che dietro l'ondata di luglio ci siano gli stessi operatori della campagna Atomic Arch di giugno, oppure un gruppo collegato. Il bersaglio, il modello di attacco e l'interesse per credenziali e infrastrutture di sviluppo sono simili.
Ma esistono anche differenze significative: la prima campagna utilizzava soprattutto dipendenze npm o Bun e includeva funzionalità legate a eBPF, la nuova ondata ha distribuito direttamente binari ELF e ha utilizzato una catena Tor in due stadi. Potrebbe essere l'evoluzione dello stesso malware oppure un gruppo imitativo che ha copiato un metodo già dimostratosi efficace. Le prove pubbliche non consentono di scegliere con certezza tra le due ipotesi, e chi lo afferma senza riserve sta indovinando.
Non ci sono elementi sufficienti per parlare di un'operazione statale. L'ampiezza del furto di credenziali e criptovalute è più compatibile con criminalità informatica motivata dal denaro, ma anche questa resta un'inferenza e non un'attribuzione.
La vera vulnerabilità non era nel codice
Torniamo alla domanda di partenza: come è potuto succedere.
La risposta scomoda è che non è successo niente di anomalo. L'attaccante non ha dovuto scoprire una vulnerabilità sofisticata nei server di Arch Linux. Ha usato un processo legittimo, l'adozione di pacchetti abbandonati, esattamente per come è stato progettato. Ha ereditato nomi conosciuti, cronologie già esistenti e la fiducia accumulata da altri sviluppatori. Quando quella strada è stata chiusa, ha iniziato a pubblicare pacchetti nuovi.
Nessun exploit, nessuna falla, nessun bug da correggere con una patch. Il che solleva la domanda davvero fastidiosa: che cosa esattamente dovrebbe sistemare Arch Linux, dal momento che il sistema ha funzionato come previsto?
L'incidente mostra quanto sia fragile una supply chain nella quale il codice viene eseguito localmente e la revisione è affidata quasi interamente agli utenti. Fragile non perché scritta male, ma perché regge su un'assunzione che nessuno verifica mai: che chi mantiene un pacchetto oggi sia la stessa persona che lo manteneva ieri.
Il dettaglio più inquietante non è il server .onion, il malware scritto in Rust o il processo Tor mascherato da dbus-daemon. Sono acrobazie tecniche, e le acrobazie tecniche si studiano e si riconoscono.
Il dettaglio più inquietante è che, dal punto di vista della vittima, tutto comincia con un gesto completamente normale:
yay -Syu
Un semplice aggiornamento. Quello che facciamo tutti, senza leggere, perché aggiornare è la cosa giusta da fare. E subito dopo, le chiavi per entrare in tutto il resto.