Ci sono voluti solo otto minuti. Dall'esposizione cloud al controllo amministrativo completo in AWS, l'attacco documentato da Sysdig dimostra quanto velocemente un cloud possa essere compromesso quando convergono automazione, abuso di identità e cloud permissivi.
Nonsono stati utilizzati zero-day, malware nuove catene di exploit. L'autore dell'attacco ha fatto affidamento esclusivamente su credenziali valide, servizi AWS nativi e processi decisionali automatizzati per passare dall'accesso iniziale ai privilegi di amministratore alla velocità della macchina.
Nelle ultime settimane abbiamo esaminato il comportamento iniziale degli agenti autonomi dotati di intelligenza artificiale, il modo in cui hanno iniziato a interagire e influenzarsi a vicenda all'interno di ambienti condivisi e come si è rapidamente instaurato un coordinamento senza l'intervento umano.
Questo incidente mostra cosa succede quando tali dinamiche vengono applicate a un cloud reale.
Quello che avevamo previsto è ora evidente: la ricognizione accelera e, una volta che un aggressore controlla un'identità, controlla di fatto l'ambiente. Il risultato non è una nuova classe di attacchi, ma una velocità notevolmente maggiore.
Questa analisi descrive passo dopo passo l'intrusione, evidenziando dove l'attacco ha subito un'accelerazione, dove i difensori avrebbero potuto realisticamente intervenire e perché il rilevamento comportamentale incentrato sull'identità è ora l'unico modo praticabile per fermare cloud che si muovono alla velocità dell'intelligenza artificiale.
Quando l'automazione riduce drasticamente i tempi di attacco
Questo incidente è degno di nota perché l'intelligenza artificiale ha eliminato gli attriti. L'autore dell'attacco non ha agito con cautela né ha concatenato le vulnerabilità. L'automazione gli ha permesso di enumerare i servizi, valutare i percorsi di privilegio ed eseguire l'escalation più rapidamente di quanto un operatore umano avrebbe potuto fare manualmente.
Per i difensori, la maggior parte delle azioni coinvolte sembrerebbe legittima se considerata isolatamente. Le chiamate API erano autenticate, l'accesso ai servizi avveniva tramite meccanismi approvati e le autorizzazioni sono state abusate, non aggirate.
L'unico segnale affidabile era comportamentale: chi agiva, con quale rapidità si muoveva e quale sequenza di azioni si svolgeva nei vari servizi.
Flusso di attacco di alto livello
A livello generale, l'intrusione si è svolta in cinque fasi:
- Accesso iniziale tramite risorse esposte
- Ricognizione tra servizi
- Elevazione dei privilegi tramite abuso di Lambda
- Persistenza ed espansione
- Abuso delle risorse ed esternalizzazione dei dati
Sebbene la sequenza completa comprendesse molti passaggi individuali, solo una parte di essi era fondamentale per il successo dell'attacco. Se tali passaggi vengono rilevati o bloccati, l'attacco fallisce completamente.
Fase 1: Accesso iniziale tramite Cloud esposte
Cosa è successo:
L'attacco è iniziato al di fuori dell'account AWS e non era rivolto a un'organizzazione specifica.
L'autore dell'attacco ha cercato bucket S3 accessibili pubblicamente utilizzando convenzioni di denominazione comunemente associate agli strumenti di intelligenza artificiale e cloud . Qualsiasi ambiente AWS che seguiva tali convenzioni rappresentava un potenziale punto di accesso.
All'interno di un bucket, l'autore dell'attacco ha trovato dei file contenenti le chiavi di accesso IAM. Grazie a queste credenziali valide, è riuscito ad autenticarsi direttamente nell'account AWS della vittima.
Dal punto di vista di AWS, un'identità valida aveva effettuato correttamente l'accesso.
Perché è importante:
È qui che molti cloud hanno inizio in modo silenzioso. I problemi relativiCloud spesso creano l'occasione, ma è l'uso improprio delle identità a determinare fino a che punto un aggressore può spingersi.
Una volta autenticato, l'autore dell'attacco è passato immediatamente alla fase successiva dell'attacco.
Fase 2: Ricognizione cross-service alla velocità della macchina
Cosa è successo:
Dopo l'autenticazione, l'autore dell'attacco ha effettuato un'ampia ricognizione su diversi servizi AWS, tra cui S3, Lambda, EC2, IAM, Bedrock e CloudTrail.
L'attività è stata rapida, sistematica e automatizzata. Le risposte API sono state acquisite e valutate in tempo reale per identificare percorsi di escalation praticabili.
Perché è importante:
La ricognizione rende possibile tutto ciò che segue. Senza visibilità sui servizi, sui ruoli e sull'affidabilità, i percorsi di escalation rimangono nascosti.
È qui che l'automazione cambia le carte in tavola. Gli strumenti assistiti dall'intelligenza artificiale consentono agli aggressori di acquisire le risposte API, valutare le autorizzazioni e identificare percorsi praticabili in pochi secondi.
Per i team SOC, questa fase rappresenta la prima opportunità realistica di intervento. Una volta avviata l'escalation dei privilegi, i margini di manovra per reagire si riducono drasticamente.
Questo comportamento è molto simile alle tecniche documentate nel MITRE ATLAS, relative all'abuso di account validi e alla scoperta cloud . Anziché inventare nuove tecniche, l'autore dell'attacco ha accelerato comportamenti già noti utilizzando l'automazione.
Fase 3: Abuso di Lambda come principale punto di strozzatura
Cosa è successo:
L'autore dell'attacco si è concentrato su una funzione AWS Lambda esistente e l'ha utilizzata come meccanismo di escalation dei privilegi.
In primo luogo, hanno modificato il codice della funzione e aumentato il tempo massimo di esecuzione. Questo Lambda aveva un ruolo di esecuzione con autorizzazioni sufficienti per creare utenti IAM e chiavi di accesso.
Successivamente, hanno richiamato la funzione modificata. Una volta eseguita, la funzione ha creato nuove chiavi di accesso IAM con privilegi amministrativi.
Ogni fase era legittima di per sé, ma nel loro insieme hanno trasformato un componente di automazione di routine in un percorso di escalation.
Perché è importante:
Questa sequenza è stata il punto in cui l'attacco è diventato irreversibile.
Se una qualsiasi parte di essa fallisce, la catena si interrompe. Se la funzione non può essere modificata, non può essere utilizzata in modo improprio. Se non viene mai eseguita, non vengono create nuove credenziali. Se viene eseguita ma non è in grado di creare chiavi di accesso amministrative, l'autore dell'attacco rimane bloccato.
Le funzioni Lambda concentrano l'automazione e i privilegi in un modo che pochi altri servizi fanno. I ruoli di esecuzione sono spesso più ampi di quanto previsto. Le modifiche al codice sono poco frequenti e vengono esaminate con poca attenzione. L'invocazione è prevista e comune.
Nulla in questa sequenza viola la politica AWS o provoca un evidente errore di controllo. Il rischio diventa visibile solo quando si osserva come è cambiato il comportamento della funzione e cosa ha abilitato immediatamente dopo.
Questo è un modello ricorrente negli cloud moderni. Gli aggressori non hanno bisogno di sfruttare l'infrastruttura. La riutilizzano.
Fase 4: Escalation programmatica dei privilegi
Cosa è successo:
Utilizzando la funzione Lambda modificata, l'autore dell'attacco ha creato nuove chiavi di accesso IAM con privilegi amministrativi.
Si trattava di un'escalation di privilegi senza sfruttamento.
L'autore dell'attacco ha semplicemente utilizzato un ruolo di esecuzione per eseguire azioni che era autorizzato a eseguire, ma non nel modo previsto dai suoi creatori.
Da quel momento in poi, l'autore dell'attacco è diventato effettivamente il proprietario dell'account.
Perché è importante:
Per i difensori, è proprio qui che spesso falliscono i controlli di sicurezza tradizionali. I sistemi di gestione delle identità e degli accessi applicano le politiche, non le intenzioni.
Una volta ottenuti i privilegi di amministratore, la maggior parte dei controlli viene meno. Una volta ottenuto l'accesso amministrativo, l'ambito di risposta si restringe e la risoluzione dei problemi diventa significativamente più complessa.
Fase 5: Perseveranza ed espansione
Cosa è successo:
Una volta ottenuto l'accesso amministrativo, l'autore dell'attacco si è concentrato sulla persistenza.
Nello specifico, hanno creato un nuovo utente IAM e hanno allegato il file Accesso amministratore politica, generato chiavi di accesso aggiuntive per gli utenti esistenti e recuperato segreti da Secrets Manager e SSM Parameter Store.
Ogni azione ha ampliato il margine di manovra dell'autore dell'attacco e ridotto l'efficacia delle misure correttive. Anche se una credenziale veniva revocata, le altre rimanevano valide.
Perché è importante:
Questa fase riflette un passaggio dall'accesso alla garanzia. L'aggressore garantiva il controllo continuo anche se i difensori rispondevano.
Anche in questo caso, tali azioni sono state eseguite tramite API legittime utilizzando autorizzazioni valide. La differenza tra manutenzione e compromissione risiede interamente nel comportamento e nella tempistica.
Fase 6: Abuso delle risorse ed esternalizzazione dei dati
Cosa è successo:
L'attaccante si è mosso per colpire.
Hanno lanciato un'istanza GPU di fascia alta con un gruppo di sicurezza aperto e hanno esposto l'interfaccia JupyterLab.
Hanno richiamato i modelli Bedrock e condiviso esternamente un'istantanea EBS.
Perché è importante:
A questo punto, il compromesso aveva già avuto successo. Queste azioni segnalano chiaramente le intenzioni dell'autore dell'attacco: abuso di risorse, potenziale esfiltrazione di dati e monetizzazione.
Questa fase è in linea con i modelli discussi nel nostro episodio podcast su come gli aggressori prendono di mira AWS Bedrock, tra cui LLMjacking, abuso dei costi ed esposizione dei dati una volta compromesse cloud .
"E se...?"
L'attacco documentato si è interrotto perché è stato osservato, non perché l'aggressore avesse esaurito le opzioni.
Con un accesso amministrativo prolungato, l'autore dell'attacco avrebbe potuto:
- Persistenza a lungo termine consolidata attraverso politiche di fiducia e ruoli tra account
- Pipeline CI/CD modificate per iniettare codice dannoso nella produzione
- Creazione di un'infrastruttura ombra che rispecchiava i carichi di lavoro legittimi
- Eseguita esfiltrazione silenziosa e incrementale dei dati utilizzando snapshot e replica
- Utilizzo continuo dei servizi di IA, confondendo l'abuso dei costi con un utilizzo normale
- Collegato ad account AWS o piattaforme SaaS connessi
Nessuna di queste azioni richiede ulteriori exploit. Richiedono tempo. Otto minuti erano solo il punto di partenza.
La necessità critica del rilevamento post-compromissione
Quando si verifica l'impatto, la prevenzione ha già fallito.
Il valore difensivo si sposta all'inizio della catena di attacco, prima che l'escalation dei privilegi e la persistenza consolidino il controllo dell'aggressore.
Sebbene la catena di attacco completa sia lunga, i difensori possono concentrarsi su una serie ridotta di passaggi critici lungo il flusso dell'attacco:
- Ricognizione ampia e rapida tra i vari servizi
- Modifica di una funzione Lambda esistente
- Creazione programmatica dell'accesso amministrativo
- Creazione di identità IAM persistenti
- Esternalizzazione dei dati tramite meccanismi cloud
Si tratta di comportamenti che, se osservati in sequenza, si discostano nettamente dai normali modelli di utilizzo.
La sfida è la correlazione.
La maggior parte dei controlli cloud sono statici per definizione e faticano a contrastare gli attacchi intenzionali.
In questo incidente:
- Le credenziali erano valide
- Le API sono state utilizzate come previsto
- Le autorizzazioni esistevano legittimamente
L'unica anomalia era il comportamento nel tempo.
Questo è il divario di rilevamento che gli attacchi rapidi e assistiti dall'intelligenza artificiale sfruttano.
Perché è necessario un rilevamento comportamentale incentrato sull'identità
Quando gli attacchi si muovono alla velocità delle macchine, il rilevamento deve operare allo stesso livello.
Ciò richiede comprensione:
- Come si comportano normalmente le identità umane, delle macchine e degli agenti
- Come si accede solitamente ai servizi
- Quali sequenze di azioni sono tipiche o rare
- Come cambia il comportamento quando il controllo passa all'aggressore
Il rilevamento incentrato sull'identità considera cloud , umane, non umane e agenti, come il segnale principale. L'intelligenza artificiale comportamentale modella il modo in cui tali identità operano nei vari servizi e ambienti.
Quando la ricognizione accelera, quando il comportamento di Lambda cambia, quando vengono concessi privilegi inaspettati, tali cambiamenti vengono rilevati in tempo reale.
Questoè l'unico modo pratico per interrompere gli attacchi prima che l'escalation dei privilegi diventi irreversibile.
Come Vectra AI questa classe di attacchi
La Vectra AI è progettata proprio per questo tipo di problematiche.
Analizzando il comportamento delle identità attraverso i piani cloud , il traffico di rete, l'attività SaaS e cloud , Vectra AI le fasi iniziali degli attacchi che si basano su accessi validi e automazione.
Invece di aspettare l'impatto, si concentra su:
- Modelli di ricognizione
- Abuso di privilegio
- Movimento laterale
- Uso improprio dei dati
Quando l'accesso amministrativo può essere compromesso in pochi minuti, la risposta automatizzata non è facoltativa. È l'unico modo per agire nel breve lasso di tempo che intercorre tra l'accesso e l'escalation.
Questo incidente dovrebbe ridefinire le aspettative.
Otto minuti non sono più un tempo eccezionale. È ciò che l'automazione rende possibile quando l'identità viene abusata e le difese si basano su ipotesi statiche. La lezione da trarre non è quella di temere l'IA, ma di riconoscere che gli aggressori la stanno già utilizzando per comprimere i tempi, eliminare le esitazioni e ampliare il processo decisionale.
I difensori devono rispondere in modo adeguato: il rilevamento deve essere comportamentale, la copertura deve essere incentrata sull'identità e la risposta deve essere automatizzata.
Perché quando l'accesso cloud rallenta alla velocità dell'intelligenza artificiale, non c'è più tempo per mettere insieme gli avvisi dopo il fatto.