Credenziali applicative rubate in Entra ID e Azure DevOps: Todyl segnala 27 organizzazioni colpite tramite gli MSP

Todyl, società di sicurezza gestita, segnala che dal 1° novembre 2026 un singolo operatore entra negli ambienti Microsoft 365 e Azure di diversi managed service provider (MSP) con credenziali applicative rubate e ancora valide. Lo scrive nel post d’indagine firmato da Andrew Scott, Field CISO, e aggiornato il 3 novembre. La campagna prende il nome di Key Eater.

L’operatore si presenta come le applicazioni stesse degli MSP e da lì raggiunge i loro clienti. Todyl conta 27 organizzazioni, tra governo, energia, agroalimentare, trasporti, edilizia, studi legali, istruzione e non profit. Esclude una vulnerabilità di Microsoft e non attribuisce la campagna a un attore noto.

Una precisazione sulle fonti. I dati vengono quasi tutti dal blog di Todyl, che è anche il fornitore che ha scoperto la campagna, e la redazione non ha potuto verificarli in modo indipendente. Altri fornitori compaiono soltanto in un thread del forum r/msp, con account di cui non si conosce l’identità. Dove non è indicato altrimenti, quello che segue è la ricostruzione di Todyl.

Credenziali applicative rubate: che cosa ha rilevato Todyl

I numeri

Todyl parla di circa 45 registrazioni di applicazioni (app registration) prese di mira in circa 18 organizzazioni, di cui più di 33 autenticate con successo. L’operatore ha cercato in circa 25 tenant, ha scaricato 81 file e ha consultato circa 2.279 elementi di posta.

Sono cifre minime, perché Todyl vede soltanto le organizzazioni che le inviano i log. L’ultimo tentativo, alle 21:31 UTC del 3 novembre, è stato bloccato. L’ultima azione riuscita risale alle 15:16 UTC dello stesso giorno. Cyber Security News ha ripreso i dati il 4 novembre senza aggiungere riscontri propri.

Come si muove l’operatore

L’operatore firma come service principal, cioè come identità applicativa di Entra ID, usando segreti dei client. In un caso ha usato una credenziale federata di workload identity di Azure DevOps, attiva dal 1° novembre alle 14:39 UTC, e ha riprodotto le sessioni Azure DevOps di due utenti.

Il copione si ripete. Per quasi ogni credenziale chiede prima un token per Azure Resource Manager e poi uno per Key Vault. Spesso, entro pochi secondi, seguono quelli per Graph, Storage e Cognitive Services. Nel giro di minuti si autenticano anche app mai usate prima. Todyl pensa che le letture di Key Vault siano la fonte del materiale nuovo, ma per confermarlo servono i log di audit di Key Vault.

Poi arrivano le ricerche con carattere jolly in Microsoft Graph (29, in circa 25 tenant) e i download da SharePoint, circa un file al secondo, scelti per nome. Todyl elenca password, chiavi private, profili VPN, chiavi API di servizi MFA e di piattaforme RMM, credenziali di backup, configurazioni di firewall e RDP, inventari Azure. Secondo Todyl servono a colpire VPN, servizi MFA, piattaforme RMM, storage di backup e apparati di rete, sistemi che i log di Microsoft 365 non mostrano.

L’accesso a un MSP si estende ai clienti. Una sola app multi-tenant ha attraversato 15 tenant clienti in cicli di circa 10 secondi. In un altro MSP l’app di automazione GDAP, quella delle deleghe di amministrazione, è stata provata sui tenant dei clienti senza successo.

Dopo i rilevamenti delle 07:57 UTC del 3 novembre l’operatore è passato da curl e Python a user agent di browser contraffatti. Alle 18:12 UTC ha riprodotto i refresh token di più utenti con client scriptati, e il Conditional Access li ha bloccati tutti. Todyl non ha osservato persistenza: nessun nuovo consenso, credenziale, ruolo o utente.

Sembra un worm, ma Todyl dice di no

La velocità fa pensare a un worm. In tre famiglie di MSP l’operatore ha usato materiale appena raccolto per accedere ad altre app nel giro di minuti. In un caso ha scaricato l’archivio di un connettore e, circa 2,5 minuti dopo, ha acceduto con l’app di quel connettore.

Todyl però esclude che qualcosa passi da solo da un MSP all’altro. Descrive una persona che lavora da un singolo server virtuale con una scorta di segreti raccolti prima del 1° novembre e che si espande dentro ogni famiglia di MSP a velocità di macchina. I client scriptati fanno il 95% degli accessi, con picchi di 24 in 10 secondi. Le lunghe pause e il cambio di user agent dopo i rilevamenti indicano qualcuno che guida gli strumenti. Nel thread Todyl aggiunge che i bersagli sono stati scelti uno per volta.

Todyl considera compatibile con i dati anche l’uso di strumenti agentici assistiti da AI. Lo dice con bassa confidenza: non ha prove di un modello che diriga l’attività.

Da dove vengono i segreti

È il punto meno chiaro, e le fonti non concordano.

Nel post Todyl scrive che l’origine è sconosciuta. Alcuni segreti erano stati usati solo da dispositivi del personale e da reti d’ufficio, alcuni sono arrivati in coppie attuale/scaduta. Per Todyl è un indizio a favore di un archivio di file o di un backend attivo, più che di configurazioni raccolte da internet.

Nel thread di r/msp un aggiornamento delle 23:05 UTC del 3 novembre, firmato dall’account di Todyl, indica invece come ipotesi più probabile un crawler automatico di credenziali. AbuseIPDB mostra lo stesso indirizzo impegnato in scansioni di credenziali nei giorni prima del primo accesso. Molte app colpite sono costruite su misura, quindi i loro segreti potrebbero essere finiti in repository pubblici o applicazioni web. Todyl precisa che non esiste prova diretta di una compromissione di cloud o endpoint prima dell’accesso iniziale. L’aggiornamento del blog è di mezz’ora dopo (16:36 MT, cioè 23:36 UTC) e torna a parlare di origine sconosciuta.

Nello stesso thread un commento che si dichiara di Blackpoint va nella direzione del crawler. GreyNoise e altri servizi di intelligence avevano visto l’indirizzo cercare file .env e .git/config esposti il giorno prima. Alle 17:41 UTC l’account di Todyl aveva scritto che i segreti corrispondono a quelli in uso legittimo, quindi sarebbero stati copiati da dove erano custoditi.

Lettura della redazione

Gli indizi a favore del crawler riguardano un solo indirizzo e non provano che i segreti siano stati trovati online. I segreti usati solo dal personale e le coppie attuale/scaduta si spiegano meglio con un archivio interno. Finché Todyl non allinea le due versioni, nessuna è accertata. Una cosa vale comunque: se l’origine fosse un’esposizione in repository o file di configurazione, ruotare il segreto senza chiudere l’esposizione lascerebbe aperto lo stesso varco.

Collegamenti esclusi e ipotesi aperte

ConnectWise Cloud Backup

Todyl giudica la campagna non correlata alla compromissione di ConnectWise Cloud Backup (ex SkyKick) di ottobre, attribuita a Storm-0940, che secondo Todyl Microsoft ritiene allineato alla Cina. Il magazine ne ha scritto in ConnectWise Cloud Backup e l’attacco alla supply chain.

Le somiglianze sono gli accessi con identità applicativa senza utente, il bersaglio negli strumenti degli MSP, la velocità da script e l’interesse per Key Vault. Le differenze pesano di più: qui si attaccano le credenziali delle applicazioni delle vittime e non quella di un solo fornitore, l’infrastruttura è diversa, non c’è persistenza e i tenant colpiti si sovrappongono poco. Nei commenti del thread l’account di Todyl aggiunge che un paio di tenant compaiono in entrambi i casi, ma i token precedenti non hanno prodotto attività registrata. L’indirizzo, aggiunge, non compare nel mese prima del 1° novembre.

L’estensione nel marketplace di Cursor

Todyl cita anche l’estensione anthropic.claude-code del marketplace di Cursor. Il 29 ottobre due versioni manomesse, la 2.1.312 e la 2.1.313, sarebbero rimaste online circa 11 ore, installando una chiave SSH e aprendo un tunnel inverso. Todyl attribuisce a Cursor la stima di 5.000 utenti coinvolti. Le versioni ufficiali su Visual Studio e npm non sono state toccate, e Anthropic dichiara di non avere sistemi compromessi.

Todyl ritiene l’estensione una fonte plausibile di credenziali, per il tempismo e per il bersaglio. Non ha però collegato nessuna organizzazione colpita a un’installazione, e la redazione non ha verificato l’episodio su fonti proprie.

L’uso non autorizzato di modelli AI

Todyl osserva un forte aumento dell’uso di modelli AI, compresi quelli di Anthropic, con consumi di token che le organizzazioni colpite non hanno autorizzato. Nella sequenza compaiono quattro token per servizi AI emessi in due MSP, tre per Cognitive Services e uno per Azure ML. Un token emesso non prova che sia stato usato.

Le spiegazioni proposte sono tre: furto di risorse AI con chiavi prese dai Key Vault (LLMjacking), automazione dell’intrusione con AI, strumenti di sviluppo AI compromessi. La confidenza è moderata sul legame con la campagna e bassa sul meccanismo. Nel thread Todyl racconta di un partner fatturato per migliaia di dollari pochi minuti dopo il furto della sua chiave API. Giudica l’attività compatibile con un intermediario di accessi iniziali o con la rivendita di accesso API. Non vede indizi di furto di dati a scopo di estorsione. Nessuna compromissione di un fornitore di AI è confermata.

Che cosa fare

Bloccare l’indirizzo

Todyl indica come operatore l’indirizzo 199[.]19[.]77[.]84 (AS203662, hosting con sede in Polonia), con confidenza alta. Raccomanda di bloccarlo in Conditional Access con una posizione denominata e un criterio per le workload identity assegnato direttamente ai service principal: le assegnazioni per gruppo non vengono applicate.

Il criterio ha dei limiti. Richiede la licenza Workload ID Premium e copre solo le app single-tenant registrate nel proprio tenant, non le identità gestite, le app multi-tenant né il SaaS di terzi. Todyl suggerisce di aggiungere l’indirizzo anche a un criterio per gli utenti, per coprire le sessioni riprodotte, e di attivare in Azure DevOps la validazione del Conditional Access.

Nel thread l’account di Todyl spiega perché il Conditional Access ordinario non basta. Le connessioni dei service principal con credenziali client non sono valutate dai criteri per gli utenti: ogni accesso riporta conditionalAccessStatus: notApplied . Nessuno dei tenant colpiti aveva il Conditional Access per le workload identity.

Sull’ampiezza del blocco le indicazioni divergono. Il blog dice di bloccare l’indirizzo esatto e non l’intero ASN, perché altri indirizzi dello stesso fornitore fanno attività non correlate. Gli indirizzi 199[.]19[.]77[.]18 e 65[.]87[.]223[.]26, usati per password spray con Azure CLI, sono collegati con confidenza bassa o moderata. Il thread consiglia invece di bloccare l’intero intervallo 199[.]19[.]77[.]0/24 e anche 65[.]87[.]223[.]26. Non vanno bloccati 20.20.34.96, 20.20.34.160 e 20.231.130.224, che appartengono a servizi Microsoft. Gli user agent esclusivi dell’attore sono task177-f2267/1.0 e sait-tenant-deep/37346.

Cercare nei log

Si filtrano per indirizzo i log AADServicePrincipalSignInLogs e AADNonInteractiveUserSignInLogs . I codici AADSTS7000215 (segreto non valido) e AADSTS7000222 (segreto scaduto) indicano che qualcuno possiede o sta provando una credenziale dell’app. Un fallimento seguito da un successo è urgente. Gli accessi falliti contano, perché le regole costruite solo sui successi li perdono.

In Azure DevOps vanno controllati l’auditing, la creazione e il primo uso dei PAT, le service connection federate e le esecuzioni delle pipeline. Se l’auditing è spento, Todyl chiede di attivarlo, e la ricerca deve risalire quanto consente la retention. Nel thread Todyl invita a cercare anche i download solo applicativi (app@sharepoint) dall’indirizzo indicato.

Contenere e ruotare

Con credenziali applicative rubate, ruotare i segreti non basta. L’operatore riprova contro app disabilitate e ruotate e ha cominciato a riprodurre i refresh token degli utenti. Todyl consiglia di verificare che i criteri di Conditional Access coprano i client scriptati che accedono da fornitori di hosting. Nel thread precisa che aiutano i criteri che richiedono un dispositivo conforme o ibrido, o che limitano gli accessi a posizioni attendibili.

Le misure di contenimento sono queste:

• rimuovere tutti i segreti, i certificati e le credenziali federate dell’app e controllare quelli che l’organizzazione non ha aggiunto;
• disabilitare il service principal, se serve, perché i token già emessi restano validi fino alla scadenza;
• revocare le sessioni Entra, i PAT di Azure DevOps e le chiavi SSH degli utenti coinvolti;
• ruotare il contenuto dei Key Vault raggiungibili dall’app e le credenziali presenti nei documenti consultati;
• risalire a dove era conservata la credenziale originale e a chi la conosceva.

Per i servizi AI Todyl raccomanda un inventario di risorse e chiavi, l’autenticazione Entra ID al posto delle chiavi, la rotazione delle chiavi nei vault, quote e allarmi su costi e consumo di token.

Indicazioni per gli MSP

Gli MSP devono verificare Partner Center, le relazioni GDAP e i tenant dei clienti, e avvisare i clienti secondo gli accordi. Todyl chiede di passare a GDAP con privilegi minimi e a tempo e di controllare le app nei tenant del partner, soprattutto quelle con accesso a Partner Center. Chiede anche di non conservare segreti dei clienti in runbook, note PSA/RMM e documentazione.

Per la prevenzione indica le identità gestite al posto dei segreti client, poi la federazione, poi i certificati custoditi nel vault, con Key Vault e Storage limitati a reti selezionate o a endpoint privati. Per il riuso dei token come classe di attacco resta utile il playbook di Microsoft Learn sul furto di token. Il playbook tratta però i token emessi agli utenti e non descrive questa campagna.

Che cosa cambia per gli MSP italiani

Al 4 novembre 2026 la redazione non ha trovato comunicazioni di ACN, CSIRT Italia o Garante per la protezione dei dati personali su questo caso. Il post di Todyl non dice se tra le vittime ci siano organizzazioni italiane.

Lettura della redazione

Gli MSP italiani con deleghe GDAP e app multi-tenant verso i clienti hanno la stessa superficie d’attacco descritta da Todyl, anche se non risultano vittime italiane. Un MSP che rientra tra i soggetti NIS2 dovrebbe valutare gli obblighi di notifica del d.lgs. 138/2024 se confermasse un accesso ai propri sistemi. Se sono coinvolti dati personali, vale anche la notifica prevista dall’art. 33 del regolamento (UE) 2016/679. L’applicabilità dipende dall’inquadramento del singolo soggetto e dal carattere significativo dell’incidente.

Che cosa resta incerto

La ricostruzione poggia sul blog di un fornitore, aggiornato di continuo, e la redazione non ha trovato un avviso di Microsoft. Nel thread account che si dichiarano di Huntress e Blackpoint dicono di aver visto lo stesso indirizzo. Huntress parla di quattro tenant clienti, con segreti validi, user agent Python-urllib/3.12 e token per Azure Resource Manager e, in alcuni casi, per Key Vault e Graph. Dice di aver già agito sui tenant colpiti. Sono commenti su un forum, con identità non verificate.

Un altro utente segnala l’indirizzo 157[.]22[.]126[.]128, da cui avrebbe visto un tentativo di svuotare un database. L’account di Todyl scrive prima che sembra lo stesso attaccante, poi che nei propri dati non c’è nulla. L’attribuzione resta aperta.

Restano aperti quattro punti. Come l’operatore abbia ottenuto i segreti. Se i token per i servizi AI siano stati usati. Se il consumo non autorizzato di modelli AI dipenda da questa campagna. Se l’estensione di Cursor sia stata una fonte di credenziali.

Lettura della redazione

Se il quadro di Todyl regge, per chi gestisce tenant Microsoft la lezione pratica è questa: le credenziali applicative rubate non passano da un prompt MFA e i controlli pensati per gli utenti non le fermano. Contano i log delle identità applicative, i criteri per le workload identity e i segreti custoditi nei vault.

Domande frequenti

Key Eater sfrutta una vulnerabilità di Microsoft Entra ID?

No. Secondo Todyl nessuna vulnerabilità Microsoft è coinvolta: l'operatore firma come applicazione con segreti rubati e ancora validi.

Perché ruotare i segreti non basta contro Key Eater?

Perché, secondo Todyl, l'attore riprova contro app disabilitate o ruotate e ha iniziato a riusare i refresh token degli utenti. Vanno revocate anche sessioni, PAT e chiavi SSH, e ruotato il contenuto dei Key Vault raggiungibili.

Il Conditional Access per le workload identity protegge tutte le app?

No. Secondo Todyl richiede la licenza Workload ID Premium e copre solo le app single-tenant registrate nel proprio tenant, non le identità gestite, le app multi-tenant né il SaaS di terzi.

Quali errori di Entra ID indicano che qualcuno ha il segreto di una mia app?

AADSTS7000215 indica un segreto non valido e AADSTS7000222 un segreto scaduto. Secondo Todyl un fallimento seguito da un successo è urgente.