Home Cybersecurity Frodi di reclutamento e cloud IAM: una superficie d’attacco da 2 miliardi

Frodi di reclutamento e cloud IAM: una superficie d’attacco da 2 miliardi

0
19
Rappresentazione visiva degli attacchi cloud IAM attraverso frodi di reclutamento

Un developer riceve un messaggio su LinkedIn da un recruiter. La posizione sembra legittima, il test di programmazione richiede l’installazione di un pacchetto. Quel pacchetto, però, esfiltrata tutte le credenziali cloud IAM dalla macchina dello sviluppatore: token di accesso personali GitHub, chiavi API AWS, service principal Azure. In pochi minuti, l’attaccante è dentro l’ambiente cloud.

Grazie per avere letto questo articolo, non dimenticare di iscriverti al nostro feed!

La vostra sicurezza email non ha visto nulla. Il vostro scanner di dipendenze potrebbe aver segnalato il pacchetto. Nessuno ha monitorato ciò che è successo dopo.

La catena d’attacco che sfrutta il cloud IAM

Rappresentazione visiva degli attacchi cloud IAM attraverso frodi di reclutamento

Questa sequenza di attacco sta rapidamente diventando nota come IAM pivot 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 gruppi avversari abbiano operazionalizzato questa catena d’attacco su scala industriale.

Gli attori delle minacce mascherano la distribuzione di pacchetti Python e npm trojanizzati attraverso frodi di reclutamento, quindi passano dalle credenziali rubate agli sviluppatori al compromesso completo delle configurazioni cloud IAM. In un caso della fine del 2024, gli attaccanti hanno consegnato pacchetti Python malevoli a una società FinTech europea attraverso esche a tema reclutamento, hanno compromesso le configurazioni cloud IAM e deviato criptovalute verso wallet controllati dagli avversari.

Dall’ingresso all’uscita, nulla ha toccato il gateway email aziendale. Non ci sono prove digitali su cui indagare.

Un’industria criminale da 2 miliardi di dollari

In un recente episodio del podcast Adversary Universe di CrowdStrike, Adam Meyers, vicepresidente senior dell’intelligence dell’azienda, ha descritto la scala: oltre 2 miliardi di dollari associati a operazioni di criptovaluta gestite da un’unica unità avversaria. Inoltre, Meyers ha spiegato che la valuta decentralizzata è ideale perché consente agli attaccanti di evitare simultaneamente sanzioni e rilevamento.

Cristian Rodriguez, field CTO di CrowdStrike per le Americhe, ha spiegato che il successo economico ha guidato la specializzazione organizzativa. Quello che era un singolo gruppo di minaccia si è diviso in tre unità distinte che prendono di mira obiettivi di criptovaluta, fintech e spionaggio.

Quel caso non è stato isolato. Tuttavia, la Cybersecurity and Infrastructure Security Agency (CISA) e la società di sicurezza JFrog hanno tracciato campagne sovrapposte nell’ecosistema npm, con JFrog che ha identificato 796 pacchetti compromessi in un worm auto-replicante diffuso attraverso dipendenze infette.

Quando lo scanning delle dipendenze non basta

Gli avversari stanno spostando i vettori di ingresso in tempo reale. I pacchetti trojanizzati non arrivano più attraverso il typosquatting come in passato: vengono consegnati manualmente tramite canali di messaggistica personale e piattaforme social che i gateway email aziendali non intercettano. Di conseguenza, CrowdStrike ha documentato avversari che adattano esche a tema lavorativo a settori e ruoli specifici.

CISA ha documentato questo fenomeno su larga scala a settembre, emettendo un avviso su un compromesso diffuso della supply chain npm che prendeva di mira token di accesso personali GitHub e chiavi API AWS, GCP e Azure. Il codice malevolo scansionava le credenziali durante l’installazione del pacchetto e le esfiltrava verso domini esterni.

Lo scanning delle dipendenze cattura il pacchetto. Questo è il primo controllo, e la maggior parte delle organizzazioni ce l’ha. Quasi nessuna ha il secondo: il monitoraggio comportamentale runtime che rileva l’esfiltrazione delle credenziali durante il processo di installazione stesso.

Pivot 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 aggiungono un altro 29,4%. Questi numeri sono rimasti stabili in periodi di reporting consecutivi. In altre parole, questa è una condizione cronica, non una minaccia emergente.

Una ricerca pubblicata all’inizio di questo mese ha dimostrato esattamente quanto velocemente si esegue questo pivot. Sysdig ha documentato una catena d’attacco in cui credenziali compromesse hanno raggiunto privilegi di amministratore cloud in otto minuti, attraversando 19 ruoli IAM prima di enumerare modelli AI Amazon Bedrock e disabilitare il logging delle invocazioni del modello.

Otto minuti. Nessun malware. Nessun exploit. Solo una credenziale valida e l’assenza di baseline comportamentali IAM.

Perché i gateway AI non fermano questo attacco

I gateway AI eccellono nella validazione dell’autenticazione. Verificano se l’identità che richiede l’accesso a un endpoint del modello o a una pipeline di training possiede il token giusto e ha privilegi per il periodo definito dagli amministratori. Tuttavia, non verificano se quell’identità si comporta coerentemente con il suo pattern storico o sta sondando casualmente l’infrastruttura.

Considerate uno sviluppatore che normalmente interroga un modello di completamento codice due volte al giorno, che improvvisamente enumera ogni modello Bedrock nell’account, disabilitando prima il logging. Un gateway AI vede un token valido. L’ITDR (Identity Threat Detection and Response) vede un’anomalia.

Un post del blog di CrowdStrike sottolinea perché questo è importante ora. I gruppi avversari che traccia si sono evoluti dal furto opportunistico di credenziali a operatori di intrusione consapevoli del cloud. Stanno passando da workstation di sviluppatori compromesse direttamente alle configurazioni cloud IAM, le stesse configurazioni che governano l’accesso all’infrastruttura AI.

Dove si trovano le lacune di controllo

Questa catena d’attacco si articola in tre fasi, ciascuna con una lacuna di controllo distinta e un’azione specifica:

  • Ingresso: Pacchetti trojanizzati consegnati tramite WhatsApp, LinkedIn e altri canali non email bypassano completamente la sicurezza email. La lacuna: lo scanning delle dipendenze cattura il pacchetto, ma non l’esfiltrazione runtime delle credenziali. Azione suggerita: implementare il monitoraggio comportamentale runtime sulle workstation degli sviluppatori.
  • Pivot: Le credenziali rubate consentono l’assunzione di ruoli IAM invisibile alla sicurezza basata sul perimetro. La lacuna: non esistono baseline comportamentali per l’utilizzo dell’identità cloud. Azione suggerita: implementare ITDR che monitora il comportamento dell’identità negli ambienti cloud.
  • Obiettivo: L’infrastruttura AI si fida dell’identità autenticata senza valutare la coerenza comportamentale. La lacuna: i gateway AI convalidano i token ma non i pattern di utilizzo. Azione suggerita: implementare controlli di accesso specifici per l’AI che correlano le richieste di accesso al modello con i profili comportamentali dell’identità.

Cosa verificare nei prossimi 30 giorni

Verificate il vostro stack di monitoraggio IAM rispetto a questa catena a tre fasi. Se avete lo scanning delle dipendenze ma nessun monitoraggio comportamentale runtime, potete catturare il pacchetto malevolo ma perdere il furto di credenziali. Da un lato, se autenticate le identità cloud ma non ne tracciate il comportamento di base, non vedrete il movimento laterale. Dall’altro, se il vostro gateway AI controlla i token ma non i pattern di utilizzo, una credenziale dirottata arriva dritta ai vostri modelli.

Il perimetro non è più dove avviene questa battaglia. L’identità è tutto. Per approfondire ulteriori strategie di sicurezza cloud, visitate il Blog Digitalseeds per articoli correlati.