Infostealer Azure: 3,64 milioni di record Fortune 500 esfiltrati

Marcus Chen Ingegnere senior (Backend & Cloud), YuSMP Group · Sicurezza cloud e architettura delle identità per team di sviluppo americani ed europei

In sintesi

Cosa è successo: dall’infostealer alla directory Azure

La catena d’attacco si articola in due fasi. Prima, il malware infostealer — una categoria di software per la raccolta di credenziali che estrae silenziosamente password salvate, cookie del browser e token di sessione dagli endpoint infetti — ha compromesso dispositivi appartenenti a dipendenti delle aziende prese di mira. Una volta attivo su un endpoint, l’infostealer raccoglie tutte le credenziali cloud che riesce a trovare: token Microsoft 365, accessi al portale di gestione Azure, account amministratori di Entra ID. Queste credenziali rubate vengono poi vendute o scambiate nei mercati underground.

Nella seconda fase, l’attaccante ha utilizzato quelle credenziali raccolte per autenticarsi direttamente ai tenant Microsoft Azure ed Entra ID delle vittime come utenti legittimi. Dall’interno del tenant, esportare la directory dei dipendenti — che Azure espone tramite la sua Graph API e il portale di amministrazione agli utenti autenticati con autorizzazioni sufficienti — è un’operazione a bassa frizione che lascia tracce solo se i log di audit corretti vengono monitorati. Hudson Rock osserva di aver “identificato credenziali Azure compromesse collegate ad attività infostealer” presso diverse aziende citate, corroborando il vettore dichiarato senza poter confermare quale credenziale specifica sia stata utilizzata per ogni singola esportazione.

Il motivo per cui questa catena d’attacco è così efficace è che bypassa completamente le difese perimetrali. Non vi è alcun exploit, nessun payload malevolo consegnato all’infrastruttura Azure, nessuna intrusione di rete nel senso tradizionale del termine. L’attaccante accede con una password reale e un token di sessione valido (o di recente invalidato), naviga nella directory e la esporta. Dal punto di vista di Azure, la sessione appare come una normale azione amministrativa.

Chi è stato colpito e quali dati sono stati sottratti

La portata dichiarata è ampia. McDonald’s figura in testa con circa 1,7 milioni di record, seguita da Tata Consultancy Services con circa 800.000, Vodafone con circa 425.000 e HCL Technologies con circa 250.000. Il resto dei 3,64 milioni totali è distribuito tra Gap Inc., InterContinental Hotels Group, Kyndryl, Hexaware Technologies e Wyndham Hotels.

Ciò che rende i dati particolarmente sensibili non è solo il volume, ma la ricchezza dello schema della directory. I campioni esaminati da Hudson Rock includevano presumibilmente indirizzi e-mail aziendali, numeri di telefono, indirizzi fisici degli uffici, ID dipendente, qualifiche, organigrammi dipartimentali con le relazioni gerarchiche, appartenenze ai gruppi di Active Directory e dettagli degli account di servizio. In modo critico, alcuni record identificavano presumibilmente account con privilegi di Global Administrator in Entra ID. Quest’ultima categoria rappresenta un elenco di target: un attaccante che sa quali account detengono i ruoli con i privilegi più elevati in un tenant dispone di una mappa pronta per la fase successiva di un’intrusione più ampia.

TCS ha depositato una dichiarazione alla Borsa di Bombay il 10 agosto dopo aver ricevuto avvisi di threat intelligence, affermando di “non aver trovato prove credibili di una violazione” dei propri sistemi o degli ambienti dei clienti. Nessuna delle altre aziende citate aveva rilasciato dichiarazioni pubbliche al momento della prima pubblicazione.

Perché la questione va oltre i numeri dei titoli

Le directory di dipendenti trapelate vengono spesso trattate come incidenti di gravità inferiore rispetto alle violazioni di dati finanziari o sanitari — una classificazione che sottovaluta il loro valore a valle per gli attaccanti. Un organigramma completo con indirizzi e-mail e strutture di report è la base per campagne mirate di spear-phishing e di compromissione della posta elettronica aziendale (BEC). Sapere che “Alice in Finanza riporta a Bob, il CFO” consente a un attaccante di costruire un’impersonazione altamente convincente di Bob che richiede ad Alice un bonifico urgente.

L’inclusione degli account di servizio e delle loro appartenenze ai gruppi di Entra ID aumenta ulteriormente la gravità. Gli account di servizio spesso dispongono di autorizzazioni elevate e vengono raramente monitorati con la stessa attenzione degli account umani. Se uno qualsiasi di quegli account di servizio utilizza password che compaiono altrove nei dump degli infostealer, diventano immediatamente punti di pivot verso l’infrastruttura di produzione, le pipeline CI/CD o i data warehouse.

Per le organizzazioni soggette al Regolamento generale sulla protezione dei dati dell’UE, qualsiasi esfiltrazione confermata di dati personali dei dipendenti attiva un obbligo di notifica della violazione alle autorità di controllo competenti entro 72 ore, indipendentemente dal fatto che la violazione sia stata causata da un difetto della piattaforma o da una credenziale rubata. L’articolo 33 del GDPR non distingue tra i metodi di intrusione. Le esposizioni di Vodafone e IHG, se confermate, attiverebbero obblighi di notifica in più Stati membri dell’UE.

Cosa significa per i team cloud statunitensi ed europei

Il problema sistemico che questo incidente mette in luce è il divario tra la sicurezza del tenant cloud e la sicurezza degli endpoint. I team che hanno investito molto in Conditional Access di Entra ID, rilevamento delle minacce e architettura Zero Trust possono comunque essere compromessi se un infostealer viene eseguito non rilevato sul laptop di uno sviluppatore per un tempo sufficiente a raccogliere un token di sessione valido. I token di sessione nei moderni sistemi di identità possono rimanere validi per ore o giorni, e molti infostealer li prendono di mira specificamente piuttosto che le password, perché i token bypassano completamente l’MFA.

I team software che sviluppano su Azure sono particolarmente esposti a questo schema perché gli ambienti di sviluppo tendono ad accumulare ampie autorizzazioni. Uno sviluppatore a cui è stato concesso il ruolo Directory Reader di Entra ID, o che è membro di un gruppo con autorizzazioni elevate sulle risorse Azure, diventa un target di alto valore per qualsiasi campagna infostealer. Il principio del minimo privilegio — ben compreso a livello di infrastruttura — viene spesso violato a livello di ruolo sviluppatore perché crea attrito nel lavoro quotidiano.

Il messaggio pratico per i leader dell’ingegneria è di trattare l’igiene degli endpoint come un controllo di sicurezza cloud di primo livello, non come una preoccupazione IT separata. Le infezioni da infostealer si diffondono tramite e-mail di phishing, estensioni browser dannose, strumenti di sviluppo troianizzati e software craccato. Un team che distribuisce l’accesso di rete Zero Trust ma consente agli sviluppatori di installare estensioni browser non verificate ha una lacuna che gli attaccanti troveranno.

Cosa fare ora: una checklist pratica

1. Verificate i log di audit di Entra ID per operazioni di esportazione massiva della directory. Nell’interfaccia di amministrazione di Microsoft Entra, accedete a Identità → Monitoraggio e integrità → Log di audit e filtrate per operazioni come “Esportazione directory”, “Recupero utenti” in scala massiva, o chiamate all’API Graph che hanno restituito set di risultati di grandi dimensioni. Analizzate almeno gli ultimi 90 giorni. Gli accessi anomali da nuove aree geografiche, dispositivi non familiari o al di fuori dell’orario di lavoro in questo lasso di tempo richiedono un’indagine immediata.
2. Applicate l’MFA resistente al phishing per tutti gli account privilegiati, in particolare i Global Administrator e gli account di servizio. L’autenticazione solo con password e l’MFA basato su SMS sono entrambi inadeguati. Richiedete chiavi hardware FIDO2 o Microsoft Authenticator con number matching (che vanifica il push-bombing) per qualsiasi account con autorizzazioni a livello di directory. Applicate criteri di accesso condizionale che blocchino i protocolli di autenticazione legacy, che non supportano affatto l’MFA.
3. Ruotate le credenziali degli account di servizio che potrebbero essere stati accessibili da sessioni compromesse. Se un account umano nel vostro tenant aveva accesso alle credenziali degli account di servizio, alle chiavi API o ai segreti durante la finestra sospetta, ruotate subito tali credenziali. Date priorità ai segreti archiviati nelle variabili d’ambiente, nelle configurazioni delle pipeline CI/CD e nelle voci di Azure Key Vault accessibili dagli account in questione.
4. Esaminate l’ambito delle autorizzazioni degli sviluppatori in Entra ID. Verificate quali account di sviluppatori detengono i ruoli Directory Reader, User Administrator o Global Administrator, e se le appartenenze ai gruppi concedono accesso implicito a risorse Azure sensibili. Applicate il principio del minimo privilegio: gli sviluppatori che lavorano su Azure raramente necessitano di autorizzazioni di lettura a livello di directory per il loro lavoro quotidiano. Rimuovete ciò che non è necessario.
5. Valutate l’esposizione agli infostealer sui vostri endpoint. Esaminate la telemetria EDR per comportamenti di raccolta di credenziali del browser, injection di processi inattesi nei processi browser e connessioni di rete verso infrastrutture C2 di infostealer note. Se non disponete di una soluzione EDR che copra le workstation degli sviluppatori, tale lacuna è ora un rischio di sicurezza cloud documentato, non solo una mancanza nella gestione degli endpoint.
6. Se siete soggetti al GDPR, valutate gli obblighi di notifica. Ai sensi dell’articolo 33 del GDPR, una violazione di dati personali che coinvolge record di dipendenti attiva un obbligo di notifica entro 72 ore alla vostra autorità di controllo principale se sussiste un rischio per i diritti e le libertà delle persone fisiche. Contattate immediatamente il vostro Responsabile della protezione dei dati se la vostra organizzazione è tra le aziende citate o se un’indagine interna rivela un’esposizione analoga delle credenziali.

Domande frequenti

Fonti

The Register — Crook hawks millions of records allegedly plundered from corporate Azure tenants (17 agosto 2026)
BleepingComputer — Hacker claims 3.6 million Azure account records stolen from major companies
Help Net Security — Hacker claims millions of records stolen from corporate Azure tenants (18 agosto 2026)
SC Media — McDonald’s employee records allegedly stolen from Azure