L.Columbus
Uno sviluppatore riceve un messaggio LinkedIn da un recruiter. Il ruolo sembra legittimo. La valutazione del codice richiede l’installazione di un pacchetto. Questo pacchetto estrae tutte le credenziali cloud dalla macchina dello sviluppatore (token di accesso personali GitHub, chiavi API AWS, entità di servizio Azure e altro ancora) e l’avversario si ritrova all’interno dell’ambiente cloud in pochi minuti.Il tuo sistema di sicurezza email non l’ha mai visto. Il tuo strumento di analisi delle dipendenze potrebbe aver segnalato il pacchetto. Nessuno ha visto cosa è successo dopo.
La catena di attacco sta rapidamente diventando nota come il perno della gestione delle identità e degli accessi (IAM) e rappresenta una lacuna fondamentale nel modo in cui le aziende monitorano gli attacchi basati sull’identità. Una ricerca di CrowdStrike Intelligence, pubblicata il 29 gennaio, documenta come i gruppi di hacker abbiano reso operativa questa catena di attacco su scala industriale. Gli autori delle minacce stanno mascherando la distribuzione di pacchetti Python e npm trojanizzati attraverso frodi di reclutamento, per poi passare dal furto di credenziali di sviluppo alla compromissione completa dell’IAM nel cloud.
In un caso avvenuto alla fine del 2024, gli aggressori hanno consegnato pacchetti Python dannosi a un’azienda FinTech europea tramite esche a tema reclutamento, sono passati a configurazioni IAM cloud e hanno dirottato la criptovaluta verso wallet controllati dagli avversari.
L’ingresso e l’uscita non hanno mai toccato il gateway di posta elettronica aziendale e non vi è alcuna prova digitale su cui basarsi.
In un recente episodio del podcast Adversary Universe di CrowdStrike , Adam Meyers, SVP Intelligence e responsabile delle operazioni di contrasto agli attacchi avversari dell’azienda, ne ha descritto la portata: oltre 2 miliardi di dollari associati a operazioni di criptovaluta gestite da un’unica unità avversaria. La valuta decentralizzata, ha spiegato Meyers, è ideale perché consente agli aggressori di evitare sanzioni e di essere individuati contemporaneamente. Cristian Rodriguez, CTO di CrowdStrike per le Americhe, ha spiegato che il successo in termini di fatturato ha guidato la specializzazione organizzativa. Quello che un tempo era un unico gruppo di minaccia si è diviso in tre unità distinte che prendono di mira obiettivi di criptovaluta, fintech e spionaggio.
Quel caso non era isolato. La Cybersecurity and Infrastructure Security Agency ( CISA ) e la società di sicurezza JFrog hanno monitorato campagne sovrapposte nell’ecosistema npm, con JFrog che ha identificato 796 pacchetti compromessi in un worm autoreplicante che si diffondeva attraverso dipendenze infette. La ricerca documenta inoltre che la messaggistica WhatsApp è il principale vettore di compromissione iniziale, con gli avversari che distribuiscono file ZIP dannosi contenenti applicazioni trojanizzate attraverso la piattaforma. La sicurezza della posta elettronica aziendale non intercetta mai questo canale.
La maggior parte degli stack di sicurezza sono ottimizzati per un punto di ingresso che questi aggressori hanno completamente abbandonato.
Quando la scansione delle dipendenze non è sufficiente
Gli aggressori stanno modificando i vettori di accesso in tempo reale. I pacchetti trojanizzati non arrivano più tramite typosquatting come in passato, ma vengono consegnati manualmente tramite canali di messaggistica personale e piattaforme social che i gateway di posta elettronica aziendali non toccano. CrowdStrike ha documentato aggressori che adattano esche a tema lavorativo a settori e ruoli specifici e ha osservato l’implementazione di malware specializzati presso aziende FinTech fino a giugno 2025.
La CISA ha documentato questo fenomeno su larga scala a settembre, emettendo un avviso su una diffusa compromissione della supply chain npm che prendeva di mira i token di accesso personali di GitHub e le chiavi API di AWS, GCP e Azure. Il codice dannoso è stato scansionato alla ricerca di credenziali durante l’installazione del pacchetto ed esfiltrato verso domini esterni.
La scansione delle dipendenze rileva il pacchetto. Questo è il primo controllo, e la maggior parte delle organizzazioni lo implementa. Quasi nessuna ha il secondo, ovvero il monitoraggio comportamentale in fase di esecuzione che rileva l’esfiltrazione delle credenziali durante il processo di installazione.
“Se si riduce questo attacco all’essenziale, ciò che salta all’occhio non è una tecnica rivoluzionaria”, ha affermato Shane Barney, CISO di Keeper Security, in un’analisi di una recente catena di attacchi al cloud . “È la scarsa resistenza offerta dall’ambiente una volta che l’aggressore ha ottenuto l’accesso legittimo”.
Gli avversari stanno diventando più bravi a creare perni letali e non monitorati
Il Threat Horizons Report di Google Cloud ha rilevato che credenziali deboli o assenti hanno rappresentato il 47,1% degli incidenti cloud nella prima metà del 2025, con configurazioni errate che hanno aggiunto un ulteriore 29,4%. Questi numeri sono rimasti stabili nei periodi di riferimento consecutivi. Si tratta di una condizione cronica, non di una minaccia emergente. Gli aggressori con credenziali valide non hanno bisogno di sfruttare nulla. Effettuano l’accesso.
Una ricerca pubblicata all’inizio di questo mese ha dimostrato esattamente la velocità di esecuzione di questo pivot . Sysdig ha documentato una catena di attacchi in cui le credenziali compromesse hanno raggiunto i privilegi di amministratore cloud in otto minuti, attraversando 19 ruoli IAM prima di enumerare i modelli di intelligenza artificiale di Amazon Bedrock e disabilitare la registrazione delle invocazioni dei modelli.
Otto minuti. Nessun malware. Nessun exploit. Solo credenziali valide e l’assenza di baseline comportamentali IAM.
Ram Varadarajan, CEO di Acalvio , lo ha detto senza mezzi termini : la velocità delle violazioni è passata da giorni a minuti e per difendersi da questo tipo di attacchi è necessaria una tecnologia in grado di ragionare e rispondere alla stessa velocità degli aggressori automatizzati.
Il rilevamento e la risposta alle minacce di identità (ITDR) colma questa lacuna monitorando il comportamento delle identità all’interno degli ambienti cloud, non solo se l’autenticazione avviene correttamente. Il Leadership Compass 2025 di KuppingerCole sull’ITDR ha rilevato che la maggior parte delle violazioni di identità proviene ora da identità non umane compromesse, ma l’adozione dell’ITDR a livello aziendale rimane disomogenea.
Morgan Adamski, vice responsabile per i rischi informatici, dei dati e tecnologici di PwC, ha messo in luce la posta in gioco in termini operativi . Ottenere la giusta identità, inclusi gli agenti di intelligenza artificiale, significa controllare chi può fare cosa alla velocità della macchina. Gli avvisi di emergenza provenienti da ogni parte del mondo non riusciranno a tenere il passo con la proliferazione multicloud e gli attacchi incentrati sull’identità.
Perché i gateway AI non fermano questo
I gateway di intelligenza artificiale eccellono nella convalida dell’autenticazione. Verificano se l’identità che richiede l’accesso a un endpoint del modello o a una pipeline di addestramento possiede il token corretto e dispone dei privilegi per l’intervallo di tempo definito dagli amministratori e dalle policy di governance. Non verificano se tale identità si comporta in modo coerente con il suo modello storico o se effettua ricerche casuali nell’infrastruttura.
Si consideri uno sviluppatore che normalmente interroga un modello di completamento del codice due volte al giorno, enumerando improvvisamente tutti i modelli Bedrock presenti nell’account e disabilitando prima la registrazione. Un gateway AI rileva un token valido. L’ITDR rileva un’anomalia.
Un post sul blog di CrowdStrike sottolinea perché questo sia importante ora. I gruppi di aggressori che monitora si sono evoluti da opportunisti furti di credenziali a operatori di intrusione attenti al cloud. Stanno passando dalle workstation degli sviluppatori compromesse direttamente alle configurazioni IAM del cloud, le stesse configurazioni che regolano l’accesso all’infrastruttura di intelligenza artificiale. Gli strumenti condivisi tra unità distinte e il malware specializzato per gli ambienti cloud indicano che non si tratta di una sperimentazione. È industrializzata.
L’ufficio CISO di Google Cloud ha affrontato questo aspetto direttamente nelle previsioni sulla sicurezza informatica di dicembre 2025 , osservando che i consigli di amministrazione ora chiedono informazioni sulla resilienza aziendale contro gli attacchi informatici. Gestire sia le identità umane che quelle non umane è essenziale per mitigare i rischi derivanti da sistemi non deterministici.
Non esiste alcun air gap tra l’IAM di elaborazione e l’infrastruttura di intelligenza artificiale. Quando l’identità cloud di uno sviluppatore viene dirottata, l’aggressore può raggiungere i pesi dei modelli, i dati di training, gli endpoint di inferenza e qualsiasi strumento a cui tali modelli si connettono tramite protocolli come il protocollo MCP (Model Context Protocol).
La connessione MCP non è più solo una teoria. OpenClaw, un agente di intelligenza artificiale autonomo open source che ha raggiunto le 180.000 stelle su GitHub in una sola settimana, si connette a e-mail, piattaforme di messaggistica, calendari e ambienti di esecuzione del codice tramite MCP e integrazioni dirette. Gli sviluppatori lo stanno installando sui computer aziendali senza una verifica di sicurezza.
Il team di ricerca sulla sicurezza dell’intelligenza artificiale di Cisco ha definito lo strumento “rivoluzionario” dal punto di vista delle capacità e “un vero incubo” dal punto di vista della sicurezza, riflettendo esattamente il tipo di infrastruttura agente che un’identità cloud dirottata potrebbe raggiungere.
Le implicazioni dell’IAM sono dirette. In un’analisi pubblicata il 4 febbraio , il CTO di CrowdStrike, Elia Zaitsev, ha avvertito che “un’iniezione tempestiva riuscita contro un agente di intelligenza artificiale non è solo un vettore di fuga di dati. È un potenziale punto d’appoggio per un movimento laterale automatizzato, in cui l’agente compromesso continua a eseguire gli obiettivi dell’aggressore attraverso l’infrastruttura”.
L’accesso legittimo dell’agente ad API, database e sistemi aziendali diventa l’accesso dell’avversario. Questa catena di attacco non termina all’endpoint del modello. Se dietro di essa si trova uno strumento di tipo agentico, il raggio d’azione si estende a tutto ciò che l’agente può raggiungere.
Dove si trovano le lacune di controllo
Questa catena di attacco è suddivisa in tre fasi, ciascuna con un divario di controllo distinto e un’azione specifica.
Voce: i pacchetti trojanizzati consegnati tramite WhatsApp, LinkedIn e altri canali non email aggirano completamente la sicurezza della posta elettronica. CrowdStrike ha documentato esche a tema lavorativo su misura per settori specifici, con WhatsApp come meccanismo di distribuzione principale. Lacuna : la scansione delle dipendenze rileva il pacchetto, ma non l’esfiltrazione delle credenziali di runtime. Azione suggerita : implementare il monitoraggio comportamentale runtime sulle workstation degli sviluppatori che segnali i modelli di accesso alle credenziali durante l’installazione del pacchetto.
Pivot: le credenziali rubate consentono l’assunzione di ruoli IAM invisibili alla sicurezza perimetrale. Nel caso documentato di CrowdStrike nel settore FinTech europeo, gli aggressori sono passati da un ambiente di sviluppo compromesso direttamente alle configurazioni IAM cloud e alle risorse associate. Lacuna : non esistono linee guida comportamentali per l’utilizzo dell’identità cloud. Azione suggerita : implementare un ITDR che monitori il comportamento delle identità negli ambienti cloud, segnalando modelli di movimento laterale come l’attraversamento di 19 ruoli documentato nella ricerca Sysdig.
Obiettivo: l’infrastruttura di intelligenza artificiale si fida dell’identità autenticata senza valutare la coerenza comportamentale. Lacuna : i gateway di intelligenza artificiale convalidano i token ma non i modelli di utilizzo. Azione suggerita : implementare controlli di accesso specifici per l’intelligenza artificiale che correlino le richieste di accesso al modello con i profili comportamentali dell’identità e impongano una registrazione che l’identità che effettua l’accesso non possa disabilitare.
Jason Soroko, senior fellow di Sectigo , ha identificato la causa principale : se si guarda oltre la novità dell’assistenza dell’intelligenza artificiale, è proprio l’errore banale a renderla possibile. Credenziali valide sono esposte in bucket S3 pubblici. Un ostinato rifiuto di padroneggiare i principi fondamentali della sicurezza.
Cosa convalidare nei prossimi 30 giorni
Verifica il tuo stack di monitoraggio IAM rispetto a questa catena a tre fasi. Se hai la scansione delle dipendenze ma non il monitoraggio comportamentale in fase di esecuzione, puoi intercettare il pacchetto dannoso ma non il furto di credenziali. Se autentichi le identità cloud ma non ne definisci il comportamento di base, non vedrai il movimento laterale. Se il tuo gateway AI controlla i token ma non i pattern di utilizzo, una credenziale dirottata arriva direttamente ai tuoi modelli.
Il perimetro non è più il luogo in cui avviene questa lotta. Lo è l’identità.