Tra il 15 e il 18 ottobre 2026 è emerso uno degli incidenti di supply chain più rilevanti dell'anno per chi gestisce Microsoft 365 tramite un fornitore di servizi gestiti (MSP). Qualcuno è entrato in possesso della credenziale applicativa di ConnectWise Cloud Backup, il servizio di backup per Microsoft 365 e Google Workspace noto fino a poco tempo fa come SkyKick, e l'ha usata per autenticarsi direttamente nei tenant dei clienti. ConnectWise ha sospeso il servizio e disattivato sette identità applicative; Huntress ha confermato accessi non autorizzati in 173 tenant (le prime stime parlavano di 162).

Cosa è successo

Secondo la ricostruzione di Huntress, ripresa da BleepingComputer e dall'analisi di SpecterOps, il 13 e 14 ottobre lo stesso indirizzo IP ha tentato un password spraying su quattro tenant di studi legali, senza riuscire ad accedere con utenze umane. Il 15 ottobre, tra le 06:13 e le 08:34 UTC, l'attaccante ha cambiato approccio: invece di forzare gli utenti, ha usato il secret dell'applicazione Cloud Backup per ottenere token Microsoft Graph in tenant diversi, a distanza di pochi secondi l'uno dall'altro e in ordine di identificativo, segno di uno script che lavorava su un elenco di bersagli.

Il punto tecnico decisivo è che si tratta di un'autenticazione da applicazione ad applicazione. Il token eredita i permessi che ogni cliente aveva concesso al servizio di backup in fase di installazione, probabilmente anche Directory.ReadWrite.All, come ipotizzato da Microsoft Threat Intelligence. Le richieste sono automatizzate, quindi l'autenticazione a più fattori non interviene: l'MFA protegge le persone, non le credenziali delle app.

Dopo l'accesso, gli analisti hanno osservato ricognizione tramite Microsoft Graph e tentativi di aggiungere credenziali ai service principal per mantenere un accesso persistente. In almeno un tenant di un partner, l'applicazione "Cloud Management - MS Teams" si è assegnata da sola il ruolo di Global Administrator e uno script Python ha aggiunto nuovi client secret a uno strumento di gestione dell'MSP e all'applicazione di Huntress stessa. In molti altri tenant i service principal si sono attribuiti il ruolo di Exchange Administrator. Todyl, che ha analizzato nove tenant, ha invece visto solo sign-in, senza creazione di account o modifica di password: il quadro non è quindi uniforme.

Lo stato delle indagini è ancora aperto. Non è noto come l'attaccante abbia ottenuto la credenziale, né quanti dati siano stati effettivamente letti. ConnectWise afferma di non avere evidenze di compromissione dei backup archiviati, descritti come cifrati e isolati, ma al momento backup pianificati e ripristini non sono disponibili. Le informazioni qui riportate vanno lette come un quadro in evoluzione.

Cosa significa per le aziende italiane

Il caso è istruttivo per tre ragioni che riguardano da vicino il tessuto produttivo italiano, fatto in larga parte di PMI che affidano la gestione IT a un MSP.

Primo: il perimetro reale non coincide con il vostro tenant. Un fornitore di backup con permessi di scrittura sulla directory è, di fatto, un amministratore con una credenziale unica valida per centinaia di clienti. Una singola chiave compromessa a monte ha aperto porte in tenant che a valle non avevano commesso alcun errore. È la logica del rischio concentrato: più i fornitori sono condivisi, più un loro incidente si trasforma in incidente di molti.

Secondo: i backup sono fermi. Anche senza alcuna violazione nel vostro tenant, se usate Cloud Backup avete oggi una finestra senza backup SaaS e senza possibilità di ripristino tramite quel servizio. Per chi non ha un secondo livello di protezione dei dati di Microsoft 365, è un rischio operativo concreto, soprattutto se in contemporanea arrivasse un incidente ransomware o una cancellazione accidentale.

Terzo: l'MFA non basta. Molte PMI considerano l'MFA obbligatoria sugli utenti come la risposta definitiva ai furti di credenziali. Qui il canale d'attacco sono le identità non umane, che raramente sono inventariate, ruotate o monitorate. È un punto che i controlli di base di molte organizzazioni non coprono.

Il quadro normativo

Se un'organizzazione italiana ha il servizio installato e riscontra accessi anomali ai dati personali (caselle di posta, file, chat Teams), potrebbe trovarsi di fronte a una violazione di dati personali. In tal caso l'art. 33 del GDPR prevede la notifica al Garante entro 72 ore da quando il titolare ne viene a conoscenza, salvo che sia improbabile un rischio per i diritti degli interessati; il titolare resta responsabile anche quando la causa è nel fornitore. I soggetti NIS2 (essenziali e importanti) devono inoltre valutare gli obblighi di notifica degli incidenti significativi al CSIRT Italia, e il tema della sicurezza della catena di fornitura rientra tra le misure di gestione del rischio. Il caso dimostra perché i contratti con i fornitori (DPA, clausole di notifica degli incidenti, elenco dei sub-responsabili) non sono un adempimento formale. Questa non è una consulenza legale: la valutazione sulla notifica va fatta caso per caso con il DPO o con un legale.

Cosa fare subito

Chi usa ConnectWise Cloud Backup o ha tenant gestiti da un MSP che lo usa dovrebbe agire in quest'ordine:

  • Disattivare l'applicazione ConnectWise Cloud Backup (ID 506e08f9-6e9a-4da4-942b-a099a03644ae) nell'Entra admin center e tenerla disattivata finché ConnectWise non conferma la rotazione di tutte le credenziali. Nei tenant più vecchi può comparire come "SkyKick Cloud Manager". I token già emessi possono restare validi fino a circa 90 minuti.
  • Verificare le altre applicazioni "Cloud Management" (Teams, Exchange Online, MS Graph, Partner Center, SharePoint Online), i cui ID sono riportati nelle analisi di Huntress e SpecterOps.
  • Controllare i sign-in dei service principal in Entra ID (Sign-in logs, scheda dei service principal) filtrando per questi ID e cercando in particolare l'indirizzo 144.172.64.128 e user agent come curl, python-requests e python-urllib.
  • Cercare credenziali aggiunte dal 13 ottobre in tutte le registrazioni di app e le applicazioni aziendali (secret e certificati sconosciuti), e verificare che nessuna app si sia assegnata ruoli come Global Administrator o Exchange Administrator nei log di audit.
  • Attivare i Microsoft Graph activity logs, se non lo sono già, perché alcune letture della directory non lasciano tracce in altri log.
  • Revocare i consensi a SkyKick e ConnectWise Cloud Backup se il servizio non è in uso.
  • Chiedere per iscritto al vostro MSP se il servizio era attivo, su quali tenant, quali verifiche ha fatto e con quali esiti; poi documentare tutto, utile sia per l'eventuale valutazione GDPR sia per le evidenze NIS2.
  • Predisporre un piano B per i backup di Microsoft 365 finché il servizio non torna disponibile.

Revocare le sessioni degli utenti non interrompe questo tipo di accesso, perché è legato all'applicazione e non all'utente: la sola azione efficace è disattivare l'app e ruotarne le credenziali.