← Blog
LLMjackingPiattaforme AIFurto di chiavi APIBlack October

Violazioni delle piattaforme AI: WorkOS, Northflank, Trigger.dev e l'ondata di LLMjacking

WorkOS, Northflank, Trigger.dev e una dozzina di piattaforme AI violate per rubare le chiavi AI. Cosa è stato esposto e quali chiavi ruotare ora.

Zero Hunt Research··9 min di lettura

Pubblicato da Zero Hunt, un red team AI autonomo su un'appliance on-premise con AI privata: penetration test automatizzato per reti e infrastrutture, in black box o gray box, con una persona che approva ogni passo che conta.

Il 4 novembre WorkOS ha confermato che un'applicazione interna è stata violata il 30 ottobre e che la sua stessa indagine "ha identificato l'uso di un framework offensivo assistito da AI per automatizzare ricognizione e tentativi di exploit" (bollettino di sicurezza WorkOS). È l'ultimo nome di uno schema che i ricercatori di Wiz chiamano ormai "Black October" delle piattaforme di sviluppo AI: almeno una dozzina di piattaforme che custodiscono credenziali dei clienti — PaaS di hosting, gateway AI, console per coding agent, servizi di evaluation — hanno comunicato intrusioni nel giro di un mese circa, e quasi tutte hanno esposto chiavi per servizi di inferenza AI. Il bottino non è il tuo codice sorgente. È la chiave API che hai incollato in una dashboard e dimenticato.

Notizia in evoluzione — pubblicata alle 13:55 (12:55 UTC) del 4 novembre 2026. Aggiornata man mano che piattaforme e ricercatori pubblicano.

Cosa è successo

La Cloud Security Alliance descrive la forma di questi attacchi come "platform-chain": raggiungere un account di inferenza AI "passando attraverso una o più piattaforme che ne custodiscono le credenziali, senza toccare direttamente il provider o il cliente finale" (nota di ricerca CSA, 23 ottobre). Consegni la tua chiave OpenAI, Anthropic, Google o Amazon Bedrock a un host PaaS, a un gateway come LiteLLM, a una piattaforma di evaluation, a un sistema CI, alla console del tuo coding agent. Ogni copia è un punto da cui la chiave può trapelare. Come dice CSA, "la credenziale nel suo insieme è sicura solo quanto la sua copia meno protetta" — e la comunicazione di Fireworks AI ha chiarito il punto più duro: cancellare un secret salvato non invalida la credenziale.

Wiz conta almeno nove piattaforme che hanno dichiarato incidenti durante ottobre, con altre arrivate in seguito. I report non descrivono un'unica vulnerabilità né un unico attore. L'accesso iniziale varia — credenziali rubate per Fireworks, Zeabur e Lightning; un'escalation di privilegi nell'infrastruttura di build di Railway; una dipendenza da fornitore terzo per Warp; un sistema legacy in dismissione per OpenCode. Ciò che è costante è l'obiettivo. Nelle parole di Wiz, "tutti i report pubblici evidenziano exploit mirati, a caccia esplicita di variabili d'ambiente salvate, con particolare attenzione a quelle che concedono accesso AI".

Tracker degli incidenti verificati

Lo stato riflette ciò che conferma una fonte primaria, non ciò che è circolato sui social. Le date sono finestre di comunicazione o osservazione, secondo Wiz, CSA e SecurityWeek.

Piattaforma Comunicato Cosa è stato esposto / causa Stato
WorkOS 30 ott App interna vendite/CRM; contatti commerciali, riassunti di call e supporto, estratti di Slack dei clienti. Nessuna prova di accesso ai dati di produzione o al prodotto auth ✅ confermato
Northflank 30 ott Incidente comunicato; nessun TTP o IOC ancora condiviso ⚠️ dettagli attesi
Trigger.dev inizio nov Incidente comunicato; nessun TTP o IOC ancora condiviso ⚠️ dettagli attesi
Chainstack ~26–31 ott Dev + produzione raggiunti via componente di terze parti; DB clienti con nomi organizzazione e titolari, email, hash delle password; credenziali dei nodi ruotate ✅ confermato
CommandCode 28 ott Secret dei clienti; l'azienda lo ha attribuito alla "distillation" ⚠️ parziale
Warp 23 ott Dipendenza da fornitore terzo; indizi di "agent swarm" ✅ confermato
Railway 20–21 ott Escalation di privilegi nell'infrastruttura di build; variabili d'ambiente dei clienti forse accedute, alcune forse decifrate; prosciugati wallet ✅ confermato
OpenCode 16–17 ott Sistema legacy in dismissione; chiavi OpenAI/Anthropic/Google salvate da ~1,4% degli utenti console; addebiti non autorizzati oltre 1.000 $ ✅ confermato
Lightning AI 15 ott Accesso via credenziali; già colpita dalla campagna supply-chain Mini-Shai-Hulud ✅ confermato
Zeabur 14 ott Variabili d'ambiente lette; l'azienda sta chiudendo ✅ confermato
Andromeda 9 ott Secret salvati; descritto come parte di un "attacco di settore" ⚠️ parziale
Fireworks AI 6 ott Abuso di credenziali interne; env var nei job di evaluation, incluse chiavi e token API di terze parti ✅ confermato
Brev (NVIDIA) 4–20 ott Incidente comunicato; nessun TTP o IOC ancora condiviso ⚠️ dettagli attesi

Nessun attore unico è stato confermato. CSA è esplicita: l'etichetta di "campagna" finora "poggia sulla caratterizzazione di Railway", e gli incidenti "non sembrano correlati". Vedi la tabella come un grappolo di furti opportunistici contro una debolezza condivisa, non un singolo operatore.

Dalla chiave rubata alla fattura a sei cifre

Ciò che rende questa storia degna della tua mattinata è il retro. Wiz ha tracciato due chiavi rubate dal momento della violazione del fornitore fino all'abuso, e l'economia è il punto. In entrambi i casi la prima attività non autorizzata è arrivata entro 30 minuti dall'accesso alla credenziale — una singola chiamata InvokeModel da un IP residenziale in una sweep di un minuto che testava chiavi rubate su molte organizzazioni. (Una sweep ha chiesto Claude Fable 5.1, ha fallito, ed è ripiegata su Opus 5.5, che ha funzionato.) Poi un piccolo client Go ha eseguito un job di validazione, da 14 a 120 chiamate al giorno, solo per confermare che la chiave restasse viva.

Quando è arrivata la piena, è arrivata forte:

  • Caso A: circa 800.000 chiamate Bedrock in 30 ore, circa il 90% riuscite, da indirizzi residenziali poi hosting.
  • Caso B: circa 1,7 milioni di chiamate in 13 ore, oltre un milione riuscite, su una dozzina di modelli Claude.
  • A listino, Wiz stima che quelle due chiavi da sole abbiano "probabilmente generato oltre 100 mila dollari di consumo".

È LLMjacking su scala industriale, e gira su infrastruttura. Wiz attribuisce l'impennata "all'ascesa dell'LLMjacking e alla relativa infrastruttura di LLM Broker" — hub di rivendita che pubblicizzano accesso scontato ai modelli di frontiera in USDT e instradano in silenzio il traffico su chiavi rubate. Una di queste console, ricondotta a un operatore che si fa chiamare "momo", ospitava l'8 ottobre una pagina intitolata "ARTEX — autonomous penetration testing console". Lo stesso framework open source Artex è ciò che più vendor, CrowdStrike incluso, collegano al cluster cinese VAPOR PANDA e alla sua campagna contro 200 organizzazioni, e ciò che SecurityWeek lega agli attacchi di Storm-0940 contro ConnectWise. La domanda è trainata in parte dalla distillation — costruire modelli rivali più economici dal reasoning rubato — che OpenCode e CommandCode hanno entrambe indicato come movente dei propri incidenti.

"Cancella il secret esposto dalla dashboard e non hai fatto niente. La chiave funziona ancora dal provider. L'unica revoca che conta è quella che fai all'emittente — e la maggior parte dei team non ha mai inventariato dove una singola chiave di produzione è stata copiata."

Il filo offensivo dell'AI

Il motivo per cui questa storia è più di una sfilza di startup sfortunate è l'automazione dal lato attaccante. Fireworks, OpenCode e Warp hanno tutte segnalato indizi di un "agent swarm". WorkOS, con parole sue, ha trovato "un framework offensivo assistito da AI" che automatizzava ricognizione ed exploit. Quando OpenCode ha provato ad analizzare il codice malevolo, "i modelli di frontiera commerciali si sono rifiutati di analizzarlo" e l'indagine si è bloccata. È lo stesso schema operativo che documentiamo da tutto l'autunno — agenti autonomi che violano un'organizzazione dopo l'altra, scegliendo le mosse successive dalle risposte del bersaglio, a un ritmo che nessun pentest trimestrale regge. Le chiavi di accesso AI sono insieme l'obiettivo e, una volta rubate, il carburante per l'ondata successiva. Quel loop — la chiave rubata finanzia l'attacco autonomo che ruba la chiave successiva — è ciò che lo rende autoalimentato.

Remediation

Qui non c'è una patch. È un problema di igiene delle credenziali e di detection, e la finestra per agire è ora, prima che un job di validazione diventi una piena.

1. Sono coinvolto? Se hai mai salvato una chiave di provider AI, una credenziale cloud, una password di database o un token di registry su una qualsiasi delle piattaforme sopra — o su qualunque servizio terzo che custodisce secret per tuo conto — presumi l'esposizione e agisci senza aspettare una notifica. La guida CSA è netta: il costo di una rotazione inutile è piccolo rispetto a quello di una mancata.

2. Ruota dall'emittente, non dalla dashboard. Revoca e riemetti ogni chiave coinvolta dal provider che l'ha generata (OpenAI, Anthropic, Google, AWS/Bedrock, il tuo database). Rimuovere il secret dalla piattaforma violata non lo revoca. È il passo che la maggior parte dei team sbaglia.

3. Rivedi i log del provider da metà settembre. Scarica i log di consumo e fatturazione presso il provider di inferenza da almeno metà settembre — o dalla data più antica nella comunicazione della piattaforma — e cerca picchi di volume, modelli mai usati, profili di inferenza cross-region che non adoperi (global.*, us.*) e chiamate da IP residenziali o hosting. La firma dell'abuso è una cadenza breve di validazione seguita da una raffica di InvokeModel (T1496 Resource Hijacking, T1526 Cloud Service Discovery).

4. Limita l'ambito delle chiavi perché una fuga sia piccola. Emetti una chiave separata per piattaforma e per applicazione. Applica tetti di spesa e rate limit lato provider vicini al consumo atteso, non ai massimi dell'account. Preferisci accessi project-scoped o workload-identity, e inietta le credenziali a runtime da un secrets manager invece di incollarle in una dashboard (T1552.001 Unsecured Credentials in Files).

5. Sorveglia lo strumento interno, non solo il perimetro. WorkOS ha perso un'app vendite/CRM, non il prodotto auth; gli attaccanti hanno puntato alla superficie interna più morbida e ai dati che rendono credibile il phishing futuro. Tratta console interne, sandbox di evaluation e pannelli admin come bersagli primari (T1190 Exploit Public-Facing Application, T1078.004 Cloud Accounts), limita le letture massive di secret e rendi "quali terze parti hanno una copia di questa chiave" una domanda fissa nelle valutazioni dei fornitori. La guida all'acquisto di una piattaforma di pentest on-premise copre il lato data-residency del tenere le credenziali fuori dalle dashboard di terzi, in primo luogo.

Cosa non si sa ancora

  • Attribuzione. Nessun vendor ha legato le violazioni a un unico attore; l'infrastruttura di LLM broker tracciata da Wiz è "sospettata di essere collegata" alla rivendita di token ma non è provata dietro le violazioni.
  • Northflank, Trigger.dev e Brev hanno comunicato ma non pubblicato TTP o IOC al 3 novembre.
  • Il vettore d'ingresso di WorkOS non è dichiarato, e WorkOS non nomina Artex: l'attribuzione del framework viene da ricerca di terze parti (Wiz, CrowdStrike), non dalla vittima.
  • Portata. Quali account di inferenza siano stati davvero prosciugati, e non solo esposti, è ancora in conteggio sulla maggior parte di queste piattaforme.

Dove si inserisce Zero Hunt

Le piattaforme di quella tabella non sono state abbattute da uno zero-day. Sono state abbattute da un agente automatico che ha trovato un deposito di secret raggiungibile più in fretta di chi osservava — e il prosciugamento che è seguito è stato puro traffico. È la superficie che un attaccante non può riscrivere. Il modello di analisi del traffico di Zero Hunt è uno stack di deep learning con quattro teste di inferenza su miliardi di sequenze PCAP, sulla GPU dell'apparato, e legge la ricognizione a ritmo di macchina verso una console interna, e l'outbound anomalo verso ASN mai visti quando una chiave viene bruciata, mentre accade — non nell'export di fatturazione del mattino dopo. Quando l'abuso passa dal tuo egress, è un host che di norma riceve e che improvvisamente sostiene traffico in uscita: esattamente il comportamento che il modello è costruito per segnalare.

L'altra metà è trovare la chiave esposta prima dello swarm. Zero Hunt è un red team AI autonomo che gira on-premise sui propri modelli privati, con un umano che approva ogni azione che conta. Punta il suo swarm di 10 agenti sulle tue piattaforme, gateway e CI — black-box o gray-box — e caccia gli stessi secret raggiungibili che cacciano gli attaccanti, dalla variabile d'ambiente raggiungibile in input alla policy Bedrock troppo permissiva, e archivia ogni risultato firmato al momento della scrittura perché la catena probatoria regga. I modelli dell'engine sono tuoi; nessun terzo può rallentare, rifiutare o spegnere il test, e nulla lascia l'apparato. Per il lato cadenza di test, per restare davanti all'offesa a velocità di agente, vedi il penetration test automatico.

Le chiavi sono i gioielli della corona, ora. Tratta i posti in cui le conservi come il caveau.

È sfruttabile nel tuo ambiente?

Zero Hunt lo verifica sulla tua rete: un red team AI autonomo su un'appliance on-premise, con AI privata, in black box o gray box e con una persona che approva ogni passo che conta. La prova di cosa è sfruttabile, la correzione e le evidenze firmate — nessun dato esce dal tuo perimetro.