Home Tecnologia In che modo le frodi nel reclutamento hanno trasformato il cloud IAM...

In che modo le frodi nel reclutamento hanno trasformato il cloud IAM in una superficie di attacco da 2 miliardi di dollari

49
0

Uno sviluppatore riceve un messaggio LinkedIn da un reclutatore. Il ruolo sembra legittimo. La valutazione della codifica richiede l’installazione di un pacchetto. Quel pacchetto estrae tutte le credenziali cloud dal laptop dello sviluppatore (token di accesso personale GitHub, chiavi API AWS, entità servizio di Azure e altro ancora) e l’avversario si trova all’interno dell’ambiente cloud in pochi minuti.

La tua sicurezza e-mail non l’ha mai vista. Lo scanner delle dipendenze potrebbe aver contrassegnato il pacchetto. Nessuno stava guardando cosa accadde 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à. Ricerca di CrowdStrike Intelligence pubblicato il 29 gennaio documenta come i gruppi avversari abbiano reso operativa questa catena di attacchi su scala industriale. Gli autori delle minacce stanno mascherando la distribuzione di pacchetti Python e npm contenenti trojan tramite frodi nel reclutamento, per poi passare dalle credenziali degli sviluppatori rubate alla compromissione completa dell’IAM del cloud.

In un caso della wonderful del 2024, gli aggressori hanno consegnato pacchetti Python dannosi a una società europea FinTech attraverso esche a tema di reclutamento, si sono rivolti a configurazioni IAM cloud e hanno dirottato la criptovaluta verso portafogli controllati da avversari.

L’entrata e l’uscita non hanno mai toccato il gateway di posta elettronica aziendale e non ci sono show digitali su cui procedere.

In un recente episodio di CrowdStrike Podcast dell’Universo AvversarioAdam Meyers, vicepresidente senior dell’intelligence e capo delle operazioni di contrasto dell’azienda, ha descritto l’entità: Più di 2 miliardi di dollari associati a operazioni di criptovaluta gestite da un’unità avversaria. La valuta decentralizzata, ha spiegato Meyers, è l’ideale perché consente agli aggressori di evitare sanzioni e essere scoperti contemporaneamente. Il CTO di CrowdStrike per le Americhe, Cristian Rodriguez, ha spiegato che il successo delle entrate ha guidato la specializzazione organizzativa. Quello che una volta period un unico gruppo di minacce si è diviso in tre unità distinte che prendono di mira obiettivi di criptovaluta, fintech e spionaggio.

Quel caso non period isolato. L’Agenzia per la sicurezza informatica e le infrastrutture (CISA) e 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 ulteriormente la messaggistica di WhatsApp come vettore primario 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 avversari stanno spostando i vettori di ingresso in tempo reale. I pacchetti trojanizzati non arrivano tramite typosquatting are available passato: vengono consegnati manualmente tramite canali di messaggistica personali e piattaforme social che i gateway di posta elettronica aziendali non toccano. CrowdStrike ha documentato che gli avversari adattavano le esche a tema occupazionale a settori e ruoli specifici e ha osservato la distribuzione di malware specializzati presso le aziende FinTech fino a giugno 2025.

CISA lo ha documentato su vasta scala a settembre, ha emesso un avviso su una diffusa compromissione della catena di fornitura NPM che prendeva di mira i token di accesso personale GitHub e le chiavi API AWS, GCP e Azure. Il codice dannoso è stato scansionato per individuare le credenziali durante l’installazione del pacchetto ed esfiltrato in domini esterni.

La scansione delle dipendenze rileva il pacchetto. Questo è il primo controllo e la maggior parte delle organizzazioni lo possiede. Quasi nessuno dispone del secondo, ovvero il monitoraggio comportamentale in fase di esecuzione che rileva l’esfiltrazione di credenziali durante il processo di installazione stesso.

“Quando si riduce questo attacco all’essenziale, ciò che risalta non è una tecnica rivoluzionaria”, ha affermato Shane Barney, CISO di Keeper Safety, in un analisi di una recente catena di attacchi cloud. “È la scarsa resistenza offerta dall’ambiente una volta che l’aggressore ha ottenuto un accesso legittimo.”

Gli avversari stanno migliorando nel creare pivot letali e non monitorati

Quello di Google Cloud Rapporto sugli orizzonti delle minacce ha scoperto che credenziali deboli o assenti rappresentavano il 47,1% degli incidenti cloud nella prima metà del 2025, con configurazioni errate che aggiungevano un altro 29,4%. Questi numeri sono rimasti stabili nei periodi di riferimento consecutivi. Questa è una condizione cronica, non una minaccia emergente. Gli aggressori con credenziali valide non hanno bisogno di sfruttare nulla. Effettuano l’accesso.

Ricerca pubblicata all’inizio di questo mese ha dimostrato esattamente quanto velocemente viene eseguito 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 AI di Amazon Bedrock e disabilitare la registrazione delle invocazioni dei modelli.

Otto minuti. Nessun malware. Nessun sfruttamento. Bastano credenziali valide e l’assenza di linee guida comportamentali IAM.

Ram Varadarajan, CEO di Acalvio, dirlo senza mezzi termini: la velocità delle violazioni è passata da giorni a minuti e la difesa da questa classe di attacchi richiede una tecnologia in grado di ragionare e rispondere alla stessa velocità degli aggressori automatizzati.

Il rilevamento e la risposta alle minacce identità (ITDR) colma questa lacuna monitorando il comportamento delle identità all’interno degli ambienti cloud, non solo se si autenticano correttamente. Bussola della leadership 2025 di KuppingerCole on ITDR ha scoperto che la maggior parte delle violazioni di identità ora ha origine da identità non umane compromesse, ma l’adozione dell’ITDR a livello aziendale rimane disomogenea.

Morgan Adamski, vice chief di PwC per il rischio informatico, dati e tecnologico, porre la posta in gioco in termini operativi. Ottenere la giusta identità, compresi gli agenti IA, significa controllare chi può fare cosa alla velocità della macchina. Gli avvisi antincendio provenienti da ogni parte del mondo non riusciranno a tenere il passo con l’espansione multicloud e gli attacchi incentrati sull’identità.

Perché i gateway AI non fermano tutto ciò

I gateway AI eccellono nella convalida dell’autenticazione. Controllano se l’identità che richiede l’accesso a un endpoint del modello o a una pipeline di formazione detiene il token corretto e dispone dei privilegi per il periodo di tempo definito dagli amministratori e dalle coverage di governance. Non controllano se quell’identità si sta comportando in modo coerente con il suo modello storico o se sta sondando in modo casuale l’infrastruttura.

Consideriamo uno sviluppatore che normalmente interroga un modello di completamento del codice due volte al giorno, enumerando improvvisamente ogni modello Bedrock nell’account, disabilitando prima la registrazione. Un gateway AI vede un token valido. ITDR rileva un’anomalia.

UN articolo del blog di CrowdStrike sottolinea perché questo è importante ora. I gruppi avversari che tiene traccia si sono evoluti da furti di credenziali opportunistici a operatori di intrusione attenti al cloud. Stanno passando dalle workstation degli sviluppatori compromesse direttamente alle configurazioni IAM cloud, le stesse configurazioni che regolano l’accesso all’infrastruttura AI. Gli strumenti condivisi tra unità distinte e il malware specializzato per gli ambienti cloud indicano che questo non è sperimentale. È industrializzato.

L’ufficio del CISO di Google Cloud ha affrontato questo problema direttamente nel proprio Previsioni sulla sicurezza informatica di dicembre 2025sottolineando che i consigli di amministrazione ora si interrogano sulla resilienza aziendale contro gli attacchi a velocità macchina. Gestire le identità umane e non umane è essenziale per mitigare i rischi derivanti dai sistemi non deterministici.

Non c’è alcun divario tra l’IAM di calcolo e l’infrastruttura AI. Quando l’identità cloud di uno sviluppatore viene violata, l’aggressore può raggiungere i pesi dei modelli, i dati di addestramento, gli endpoint di inferenza e qualsiasi strumento a cui tali modelli si connettono tramite protocolli come il protocollo di contesto del modello (MCP).

Quella connessione MCP non è più teorica. OpenClaw, un agente AI autonomo open supply che ha attraversato 180.000 stelle GitHub in una sola settimana, si connette a e-mail, piattaforme di messaggistica, calendari e ambienti di esecuzione di codice tramite MCP e integrazioni dirette. Gli sviluppatori lo stanno installando sui laptop aziendali senza una verifica della sicurezza.

Il team di ricerca sulla sicurezza AI di Cisco ha definito lo strumento “rivoluzionario” dal punto di vista delle capacità e “un incubo assoluto” dal punto di vista della sicurezza, riflettendo esattamente il tipo di infrastruttura agente che un’identità cloud dirottata potrebbe raggiungere.

Le implicazioni IAM sono dirette. In un’analisi pubblicata il 4 febbraioElia Zaitsev, CTO di CrowdStrike, ha avvertito che “un’iniezione tempestiva riuscita contro un agente AI non è solo un vettore di perdita di dati. È un potenziale punto d’appoggio per il movimento laterale automatizzato, in cui l’agente compromesso continua a perseguire gli obiettivi dell’aggressore attraverso l’infrastruttura.”

L’accesso legittimo dell’agente advert API, database e sistemi aziendali diventa l’accesso dell’avversario. Questa catena di attacco non termina all’endpoint del modello. Se dietro di esso si trova uno strumento dell’agente, il raggio dell’esplosione si estende a tutto ciò che l’agente può raggiungere.

Dove sono le lacune di controllo

Questa catena di attacco si articola in tre fasi, ciascuna con un distinto divario di controllo e un’azione specifica.

Iscrizione: I pacchetti con trojan distribuiti tramite WhatsApp, LinkedIn e altri canali diversi dalla posta elettronica aggirano completamente la sicurezza della posta elettronica. CrowdStrike ha documentato esche a tema lavorativo adattate a settori specifici, con WhatsApp come meccanismo di consegna principale. Il divario: la scansione delle dipendenze rileva il pacchetto, ma non l’esfiltrazione delle credenziali di runtime. Azione suggerita: distribuisce il monitoraggio comportamentale in fase di runtime sulle workstation degli sviluppatori che contrassegna i modelli di accesso alle credenziali durante l’installazione del pacchetto.

Perno: Le credenziali rubate consentono l’assunzione del ruolo IAM invisibile alla sicurezza basata sul perimetro. Nel documentato caso FinTech europeo di CrowdStrike, gli aggressori sono passati da un ambiente di sviluppo compromesso direttamente alle configurazioni IAM cloud e alle risorse affiliate. Il divario: non esistono linee di base comportamentali per l’utilizzo dell’identità cloud. Azione suggerita: Distribuire l’ITDR che monitora il comportamento dell’identità negli ambienti cloud, segnalando modelli di movimento laterale come l’attraversamento di 19 ruoli documentato nella ricerca Sysdig.

Obiettivo: L’infrastruttura AI si fida dell’identità autenticata senza valutare la coerenza comportamentale. Il divario: i gateway AI convalidano i token ma non i modelli di utilizzo. Azione suggerita: implementare controlli di accesso specifici dell’intelligenza artificiale che correlano le richieste di accesso del modello con i profili comportamentali dell’identità e impongono la registrazione che l’identità di accesso non può disabilitare.

Jason Soroko, membro senior presso Settigine, identificato la causa principale: Guarda oltre la novità dell’assistenza AI e l’errore banale è ciò che l’ha resa possibile. Le credenziali valide vengono esposte nei bucket S3 pubblici. Un ostinato rifiuto di padroneggiare i fondamenti della sicurezza.

Cosa convalidare nei prossimi 30 giorni

Controlla il tuo stack di monitoraggio IAM rispetto a questa catena in tre fasi. Se si dispone della scansione delle dipendenze ma non del monitoraggio comportamentale in fase di runtime, è possibile rilevare il pacchetto dannoso ma non rilevare il furto di credenziali. Se autentichi le identità cloud ma non ne definisci il comportamento, non vedrai il movimento laterale. Se il tuo gateway AI controlla i token ma non i modelli di utilizzo, una credenziale dirottata arriva direttamente ai tuoi modelli.

Il perimetro non è più il luogo in cui avviene questa lotta. L’identità è.

fonte