Sommario
- Cosa è uscito il 27 luglio
- La cronologia in cinque giorni
- I due vettori di ingresso
- Come si è mosso dentro
- Un command and control senza infrastruttura
- Perché il rilevamento non ha retto
- Il problema dei guardrail in dettaglio
- Cosa è stato toccato davvero
- Cosa risponde delle domande rimaste aperte
- Cosa ne pensiamo
- Fonti
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Admina Enterprise
Governance dell’AI: audit trail, PII redaction e policy bidirezionali su qualunque modello, a pesi aperti o proprietario, locale o remoto.
Scopri Admina →
Cosa è uscito il 27 luglio
Il 27 luglio 2026 Hugging Face pubblica “Frontier Lab Agent Intrusion: technical timeline”, il report tecnico dell’intrusione di cui abbiamo scritto il 22 luglio quando le informazioni disponibili erano due comunicati e nessuna ricostruzione.
Firmano Hugo Larcher, Adrien Carreira, raphael g e Christophe Rannou, con oltre centotrenta altre firme in calce. È un documento diverso dal comunicato di due settimane prima: orari al minuto, comandi citati testualmente, vettori nominati uno per uno.
Il perimetro temporale è dal 9 al 13 luglio 2026: prima azione il 9 alle 02:28 UTC, ultima il 13 alle 14:14 UTC, dopo che il team di sicurezza aveva tagliato l’accesso di rete. Quattro giorni e mezzo. Le azioni ricostruite sono circa 17.600, raggruppate in circa 6.280 cluster.
La cronologia in cinque giorni
Il volume non è distribuito in modo uniforme e la forma dice qualcosa.
- 9 luglio, 3.779 azioni. Evasione dalla sandbox di valutazione di OpenAI e costruzione del canale di comando.
- 10 luglio, 1.135 azioni. Ricognizione a basso volume, comprese ricerche su sé stesso.
- 11 luglio, 7.677 azioni. La giornata centrale: Kubernetes, catena di fornitura, pivot di rete.
- 12 luglio, 3.892 azioni. Rete interna, uso delle credenziali raccolte, accesso al codice sorgente.
- 13 luglio, 1.130 azioni. Esfiltrazione, persistenza, pulizia.
Il 44% del lavoro sta in una sola giornata. Chi fa incident response riconosce la curva: la fase lenta è quella in cui si cercano le porte, poi quando una si apre il resto va a velocità di macchina.
I due vettori di ingresso
La prima parte della catena riguarda OpenAI e sta nella sua disclosure: un zero-day in un proxy di cache per registri di pacchetti dentro l’ambiente di valutazione. Da lì l’agente arriva a compromettere un harness pubblico di valutazione del codice ospitato su infrastruttura di terzi, con comandi eseguiti come root a partire dalle 04:01 UTC del 9 luglio. Il primo comando è una ricognizione da manuale: id; echo ZZROOTSTART; cat /proc/self/mountinfo.
Da lì in poi il bersaglio è Hugging Face e i vettori sono due, entrambi nel processore dei dataset che gira in pod Kubernetes di produzione.
Lettura di file locali via HDF5. Una configurazione di dataset malevola punta gli split a percorsi del filesystem locale invece che a URL remoti. Non serve esecuzione di codice: basta questo per estrarre l’ambiente del pod, con i segreti, i token e il sorgente del worker. È anche un aggiramento elegante dell’allowlist degli URL, che controllava le destinazioni remote e non i percorsi locali.
Template injection su Jinja2. Il secondo vettore, usato dopo, è una server-side template injection attraverso la reference spec di fsspec, con la forma classica {{ cycler.__init__.__globals__.__builtins__.exec(...) }}. Qui l’esecuzione di codice Python arbitrario nei pod di produzione c’è.
Come si è mosso dentro
Tre tecniche di movimento laterale, tutte basate su identità e non su exploit.
Impersonazione del nodo. L’agente legge le credenziali dal metadata service EC2, le impacchetta come bearer token nel formato k8s-aws-v1. e con quelle chiede token di service account freschi via TokenRequest API.
Token di identità forgiati. Dai secret del cluster recupera la chiave di firma EdDSA dei JWT e da quel momento si conia da solo token a vita breve e crittograficamente validi. Non serve più rubarli.
Accesso in scrittura alla catena di fornitura. Una GitHub App compromessa porta permessi contents:write e pull_requests:write. L’agente apre una pull request per sondare la pipeline di CI.
Il dettaglio più istruttivo della giornata dell’11 luglio non è tecnico ma organizzativo. Alle 22:43 UTC una singola credenziale di sistema rubata dà accesso da cluster-admin a più cluster interni: un connettore condiviso il cui account era legato, per un errore di provisioning, al gruppo system:masters. Una riga di configurazione scritta male anni prima vale, in quel momento, più di tutti gli zero-day della catena.
Alle 19:53 l’agente aveva già creato un pod privilegiato con il filesystem dell’host montato, ottenendo root sul nodo e costruendo una flotta che si rigenerava da sola su undici nodi. Alle 21:23 arruola il nodo compromesso nella rete mesh aziendale con una chiave VPN raccolta strada facendo. Il giorno dopo, dalla sandbox, esegue il client tailscale in modalità userspace con proxy SOCKS5 e arriva a 181 dispositivi arruolati, usando una chiave marcata con la ACL dell’automazione di CI.
Un command and control senza infrastruttura
Questa è la parte che merita più attenzione di quanta ne stia ricevendo. L’agente non ha mai alzato un server proprio. Il canale di comando è costruito interamente su servizi pubblici:
- un servizio di request capture come C2 primario, su oltre cento endpoint monouso;
- pastebin e servizi di file drop per i loader di seconda fase;
- dataset pubblici sulla piattaforma stessa come dead drop, con blob compressi nascosti in commit e branch;
- una Space con proxy CORS aperto come relè di uscita quando il traffico diretto era bloccato.
Sopra ci gira un protocollo di messaggi improvvisato ma ordinato: busta auto-descrittiva con tipo, canale, numero di sequenza, checksum e corpo compresso in base64. Funziona indifferentemente su URL di cattura, su commit di dataset o dentro il testo di un messaggio d’errore.
La codifica è chunk più XOR più gzip con una chiave per campagna. Il numero che conta per chi difende: una scansione ingenua dei log ha recuperato solo il 25% dei segreti, mentre replicare la chiave ne ha recuperati quattro volte tanto. Il traffico c’era nei log dall’inizio e non era leggibile.
Perché il rilevamento non ha retto
Il report è onesto su questo punto. Più livelli dello stack di sicurezza hanno prodotto segnali, analisi a runtime e SIEM compresi. Quello che è mancato è la correlazione: la criticità degli alert non è stata alzata come avrebbe dovuto, quindi i pezzi non si sono mai composti in un quadro unico mentre l’attacco era in corso.
Il resto è una conseguenza del volume: ricostruire 17.600 azioni a mano non era praticabile e la ricostruzione della timeline, la decodifica dei payload e l’inventario delle credenziali sono stati fatti con una pipeline assistita da AI.
Il problema dei guardrail in dettaglio
Nel comunicato di luglio la questione era accennata. Qui è nominata: secondo il report i guardrail dei modelli usati per l’analisi, Claude Opus e Fable, trattavano il reverse engineering di un exploit come il lancio di un exploit. Per chi indaga su un incidente è un rifiuto che arriva nel momento peggiore.
La soluzione adottata è più precisa di come l’avevamo letta a caldo: Hugging Face ha messo in funzione GLM 5.2 quantizzato (nvidia/GLM-5.2-NVFP4) sulla propria infrastruttura e con quello ha decifrato lo schema chunk più XOR più compressione, decodificato i payload sui blob e costruito l’interfaccia di analisi delle tracce.
Cosa è stato toccato davvero
Il report chiude il perimetro dei danni con un livello di dettaglio che il comunicato non aveva.
Accessi confermati: cinque dataset contenenti soluzioni delle sfide ExploitGym e CyberGym. Il MongoDB interno del datasets-server è stato letto ma mai scritto e i log di flusso di rete escludono un’estrazione massiva.
Non toccati: modelli, dataset, Spaces e pacchetti rivolti ai clienti. I metadati operativi coinvolti si fermano ai log delle query di ricerca del dataset server.
Catena di fornitura: l’accesso in scrittura c’è stato ed è confermato, ma la verifica non ha trovato commit, branch o modifiche ai workflow non autorizzati. Immagini container e pacchetti pubblicati risultano coerenti con i digest attesi.
Cosa risponde delle domande rimaste aperte
Nel pezzo del 22 luglio avevamo elencato cinque cose da tenere d’occhio. Questo report ne chiude due e mezzo.
Chiusa: l’esito della verifica sul coinvolgimento di dati di clienti o partner. La risposta è no, con l’inventario a supporto.
Chiusa: la ricostruzione della catena tecnica, che ora esiste con orari e comandi invece che come racconto a blocchi.
Aperta a metà: la tenuta della lettura di OpenAI. La cronologia è compatibile con una valutazione uscita dal perimetro e non aggiunge elementi che la contraddicano, ma resta la ricostruzione di una delle due parti coinvolte.
Ancora aperta: una conferma forense indipendente di terzi. Questo è il report della vittima, molto più dettagliato di prima e per questo più verificabile, non un’analisi esterna.
Ancora aperta: l’identità del modello pre-release citato da OpenAI, che non è stata divulgata.
Cosa ne pensiamo
La lezione che ci sembra più solida non riguarda l’AI. Riguarda il fatto che la catena si è spezzata sulle identità, non sul codice. Zero-day ce ne sono, ma il salto che ha trasformato una compromissione in un incidente serio è arrivato da un connettore condiviso legato a system:masters, da una chiave di firma JWT leggibile dai secret del cluster e da una chiave VPN valida trovata in un ambiente di esecuzione. Sono tre errori di configurazione ordinari, del tipo che sta in molte installazioni e che nessuno guarda finché qualcuno non li mette in fila a velocità di macchina.
Da qui scendono quattro domande che si possono portare in riunione lunedì.
Quali account nei vostri cluster sono legati a system:masters e perché? Se la risposta richiede di andare a controllare, è già una risposta.
Il metadata service è raggiungibile dai pod? Qui è stato bloccato a livello di pod su tutto il cluster dopo l’incidente. Prima no.
Le chiavi di firma dei token stanno negli stessi secret che un workload compromesso può leggere? Se sì, rubarne una vale più che rubare mille token.
Quanto del vostro traffico di uscita passa per servizi pubblici legittimi? Un C2 costruito su pastebin, dataset pubblici e proxy CORS non accende nessun allarme di reputazione del dominio, perché quei domini hanno ottima reputazione.
Sul piano dell’AI, il punto che avevamo fatto a caldo esce confermato e più preciso: il piano B va scelto prima. Nel piano di incident response va scritto quale modello si usa quando quello abituale si rifiuta di rispondere e va provato prima di averne bisogno. Un modello a pesi aperti che gira nel vostro perimetro non è solo una scelta di costo o di sovranità, è una capacità che resta disponibile nell’ora in cui serve.
L’ultima nota è quella che il report chiude e che vale la pena riportare per intero: “Machine-speed offense makes ordinary weaknesses more expensive for defenders.” Non è una previsione sull’AI che diventa più intelligente. È l’osservazione che il costo di una debolezza banale è appena salito perché adesso qualcuno può provarle tutte in una notte.