Oltre 9.300 chiavi AWS ancora attive sono esposte online: centinaia possono dare il controllo completo degli account

Quattro anni di monitoraggio rivelano migliaia di credenziali valide

Un’analisi di Truffle Security ha individuato più di 9.300 chiavi di accesso AWS pubblicate online tra agosto 2022 e agosto 2026 e ancora valide. La rilevazione è stata resa nota il 21 agosto 2026, dopo un’attività di monitoraggio durata quattro anni.

Il problema non riguarda una vulnerabilità del software AWS, ma la pubblicazione accidentale di credenziali utilizzabili per autenticarsi agli account cloud. Le chiavi sono comparse in repository di codice, cronologie Git, dataset, immagini Docker, registri e log prodotti da sistemi di integrazione continua.

Nel complesso, i ricercatori hanno trovato 431.875 segreti AWS. Dopo aver rimosso i duplicati, il campione comprendeva 64.024 chiavi uniche associate a 50.654 account AWS.

Il sottoinsieme analizzato con credenziali complete, quindi verificabile attraverso una nuova autenticazione, contava 10.616 chiavi. L’88% continuava ad autenticarsi correttamente al 10 agosto. Il dato indica che una parte consistente delle credenziali pubblicate non era stata revocata o sostituita.

Root e AdministratorAccess possono trasformare una fuga in un takeover

Tra le chiavi ancora attive, 817 erano riconducibili ad aziende. Di queste, 526 appartenevano a utenti root AWS, mentre 242 erano associate a utenti IAM con la policy AdministratorAccess.

Le due categorie concentrano i privilegi più rischiosi. L’identità root è il livello amministrativo massimo dell’account e non è limitata dalle autorizzazioni normalmente applicate agli utenti IAM. AdministratorAccess consente invece di creare, modificare, eliminare e consultare praticamente tutte le risorse e i servizi presenti nell’account.

Secondo i ricercatori, 768 chiavi attive appartenenti a questi due gruppi privilegiati permettevano il controllo completo dell’account AWS aziendale. Non significa che ogni chiave sia stata utilizzata da un aggressore, ma che una credenziale pubblica e funzionante poteva offrire un punto d’ingresso estremamente ampio.

Con accesso di questo tipo, un intruso può:

• leggere, copiare o cancellare dati archiviati nel cloud;
• intervenire su server, applicazioni, database e configurazioni;
• modificare risorse esistenti o crearne di nuove;
• generare account amministrativi fraudolenti per conservare l’accesso;
• installare software di mining, facendo aumentare rapidamente i costi;
• alterare servizi e componenti dell’infrastruttura online.

Il rischio non si limita quindi alla sottrazione della chiave. Un attaccante può sfruttarla per cambiare l’ambiente AWS e rendere più difficile distinguere l’attività malevola dalle normali operazioni amministrative.

Hugging Face è la principale fonte individuale delle esposizioni

La piattaforma dalla quale proviene il maggior numero di esposizioni è Hugging Face, utilizzata per condividere modelli di intelligenza artificiale, dataset e applicazioni. I ricercatori vi hanno associato 8.482 esposizioni di chiavi uniche.

Il 17,9% di queste era costituito da chiavi root. La presenza di credenziali AWS nei contenuti pubblicati su una piattaforma dedicata all’intelligenza artificiale può derivare da codice dimostrativo, notebook, dataset, file di configurazione o materiale inserito durante lo sviluppo.

Una chiave pubblicata in un progetto pubblico deve essere considerata compromessa anche se il repository viene successivamente reso privato o il file viene cancellato. Le copie possono infatti restare nella cronologia Git, nei fork, nelle cache, nei dataset scaricati o nei sistemi di indicizzazione.

Le organizzazioni coinvolte possono subire conseguenze diverse in base alle risorse presenti nei rispettivi account: esposizione di dati, interruzione di applicazioni, alterazioni dell’infrastruttura oppure costi imprevedibili per servizi creati abusivamente.

Credenziali vecchie e controlli di spesa insufficienti amplificano il rischio

L’analisi dell’anzianità, disponibile per 2.903 chiavi, ha rilevato un’età mediana di 1.831 giorni, pari a circa cinque anni. La chiave più vecchia risultava esistente da 17,4 anni.

Soltanto 398 elementi, il 13,7%, avevano una chiave di accesso più recente associata allo stesso utente. Per Truffle Security, questo suggerisce che molte credenziali probabilmente non erano mai state ruotate.

Una chiave rimasta attiva per anni aumenta la finestra temporale nella quale può essere raccolta e riutilizzata. Inoltre, la semplice presenza di una chiave più recente non dimostra automaticamente che quella vecchia sia stata revocata: la verifica deve essere eseguita direttamente nelle configurazioni dell’account.

A peggiorare il quadro contribuisce la gestione dei costi. Soltanto 262 account su 2.754 per i quali il dato era leggibile disponevano di un alert di budget. Senza avvisi, un aggressore può creare risorse cloud o avviare attività intensive senza che il titolare riceva rapidamente un segnale anomalo.

Il contesto operativo resta difficile anche quando l’organizzazione dispone di strumenti di difesa. Il Blue Report 2026, basato su 338 milioni di simulazioni in ambienti produttivi dei clienti, indica che quando l’attaccante usa credenziali valide viene bloccato soltanto il 37% delle azioni. Una chiave corretta può quindi superare numerosi controlli progettati per individuare accessi non autorizzati.

Che cosa devono fare i titolari degli account AWS

La priorità è revocare ogni chiave comparsa in una fonte pubblica e sostituirla con credenziali nuove, senza limitarsi a rimuovere il file che la contiene. La rotazione deve essere accompagnata dalla verifica dei log per individuare autenticazioni o modifiche sospette.

Le indicazioni principali sono:

1. eliminare le chiavi di accesso root;
2. censire le credenziali IAM in base all’età e all’ultimo utilizzo;
3. revocare o ruotare immediatamente quelle esposte;
4. controllare utenti, ruoli, policy e account amministrativi creati di recente;
5. configurare alert di budget e soglie di spesa;
6. cercare le chiavi in repository, cronologie Git, immagini Docker, dataset e log;
7. considerare compromessa qualsiasi credenziale pubblicata, anche se non risultano abusi.

Per il monitoraggio futuro è preferibile usare ruoli IAM e credenziali temporanee, riducendo il ricorso a chiavi statiche. I segreti non dovrebbero essere inseriti nel codice o nei dataset: devono essere conservati in sistemi dedicati e sottoposti a scansioni automatiche prima della pubblicazione.

Truffle Security dichiara di aver limitato i test alla lettura dei metadati e di aver avvisato tutti i proprietari identificabili. Non è noto quanti account siano stati effettivamente compromessi o quanti attacchi abbiano sfruttato le chiavi individuate. Il dato certo è però sufficiente per trattare ogni credenziale esposta come non più affidabile.