ConnectWise Cloud Backup attacco supply chain: il servizio resta sospeso, e la revoca della credenziale non basta a chiudere l’incidente nei tenant dei clienti.

ConnectWise Cloud Backup, attacco supply chain: dal 15 ottobre 2026 una credenziale applicativa del fornitore ha permesso di ottenere token Microsoft Graph nei tenant di clienti e partner. Il servizio, ex SkyKick e usato da molti MSP per il backup di Microsoft 365, è sospeso. Al 19 ottobre le fonti consultate non indicano una data di ripristino. Questo articolo separa ciò che i fornitori hanno confermato, ciò che i ricercatori hanno osservato e ciò che resta aperto. Poi traduce l’incidente in azioni per gli amministratori e per gli MSP italiani.

ConnectWise Cloud Backup attacco supply chain: la cronologia verificata

Che cosa ha dichiarato ConnectWise

Le dichiarazioni sono tratte dagli avvisi del Trust Center di ConnectWise, nel testo fornito dalla redazione fino all’aggiornamento del 19 ottobre alle 01:15, e dalla pagina di stato, che riporta gli stessi aggiornamenti con orari che differiscono di pochi minuti. Gli orari che seguono sono quelli del Trust Center. Sono dichiarazioni di parte e vanno lette come tali.

• 15 ottobre: ConnectWise indica questa data come quella della scoperta e dell’avvio delle indagini interne ed esterne.
• 16 ottobre, 17:47: l’azienda parla di tentativi di accesso non autorizzato associati all’ambiente Cloud Backup. Pubblica come indicatori l’indirizzo 144.172.64.128 e gli user agent Python-urllib/3.12 e python-requests/2.31.
• 17 ottobre, 05:01: l’azienda dichiara di aver identificato accessi non autorizzati a identità applicative dell’ambiente Cloud Backup e spegne l’accesso dell’applicazione.
• 17 ottobre, 07:00: ConnectWise disabilita sette identità applicative. Revoca i certificati delle connessioni coinvolte e rende non più valide le credenziali condivise di Cloud Backup.
• 17 ottobre, 17:00: l’azienda dichiara di aver coinvolto una società esterna di risposta agli incidenti e di non aver osservato attività riuscite dell’attaccante negli ambienti che monitora.
• 18 ottobre, 01:00: ConnectWise mette offline anche SaaS Security e Cloud Management, per precauzione. Precisa che la disattivazione delle connessioni non annulla le modifiche già fatte in un tenant. I token già emessi possono restare utilizzabili fino alla scadenza. Credenziali e permessi creati tramite altre identità richiedono una revisione separata.
• 18 ottobre, 18:45: l’azienda aggiunge due indirizzi alla lista degli indicatori, 144.172.64.99 e 144.172.64.60, segnalati da monitoraggi di terze parti.
• 19 ottobre, 01:15: i tre servizi restano sospesi, senza un orario di ripristino confermato. Il prossimo aggiornamento è annunciato entro le 13:00.

Sugli archivi, ConnectWise dichiara che restano cifrati e isolati e che non ha evidenze di accesso. Aggiunge però di non avere visibilità sugli ambienti dei clienti. Per questo non può stabilire, con la sola indagine interna, se un singolo tenant Microsoft 365 sia stato toccato. Alla richiesta di iTnews ha ribadito che gli archivi esistenti non sono interessati e torneranno accessibili alla ripresa del servizio (iTnews, aggiornamento del 19 ottobre). Sull’attribuzione, secondo The Register, l’azienda dichiara di non poter parlare.

Che cosa hanno osservato Huntress, Todyl e Microsoft

Queste sono osservazioni di società di sicurezza, ricavate dai log dei tenant che monitorano.

Huntress ricostruisce quattro momenti:

• 13 e 14 ottobre: password spraying da 144.172.64.128 contro quattro tenant di studi legali. Due account sono stati bloccati; Huntress non ha visto accessi utente riusciti da quell’indirizzo.
• 15 ottobre, dalle 01:58: in circa 50 tenant monitorati, i service principal delle app ConnectWise Cloud Management (Exchange Online, Teams, Graph) si assegnano ruoli di directory, soprattutto Exchange Administrator. L’user agent è kiota-dotnet, quello delle app del fornitore. Huntress lo considera indice di automazione del fornitore, ma non l’ha confermato con ConnectWise.
• 15 ottobre, dalle 03:44: in un tenant, l’app ConnectWise Cloud Management per Microsoft Teams si assegna il ruolo di Global Administrator. Poi uno script Python aggiunge nuovi client secret a due altre applicazioni, uno strumento di gestione per MSP e un’applicazione di Huntress. I secret scadono nel 2028.
• 15 ottobre, dalle 06:13 alle 08:34: l’identità di Cloud Backup ottiene token Microsoft Graph da 144.172.64.128, un indirizzo di hosting. L’attore percorre i tenant in ordine crescente di identificativo, a pochi secondi di distanza: indica uno script con un elenco di bersagli.
• 16 ottobre, ore 19:00: accessi non autorizzati confermati in 162 tenant.

Un aggiornamento del 17 ottobre aggiunge due dati. Huntress ha trovato quasi 1.000 tenant Entra con attività di accesso da quell’indirizzo, e oltre 300 sono riusciti. Dove il service principal dell’applicazione non esisteva, l’accesso è fallito.

Todyl osserva negli stessi tenant accessi del 15 ottobre tra le 07:11 e le 08:47. Non trova modifiche alla directory (nuovi secret, applicazioni, consensi o ruoli) riconducibili all’app di backup nei tenant che monitora. Gli accessi sono avvenuti anche in tenant senza un abbonamento di backup attivo.

Secondo la citazione riportata da The Hacker News, Microsoft parla di un attacco supply chain attivo contro l’applicazione OAuth di Cloud Backup. Microsoft indica come probabile l’abuso di permessi già concessi, tra cui Directory.ReadWrite.All. Segnala inoltre ricognizione tramite Graph e tentativi di aggiungere credenziali al service principal nei tenant bersaglio. Questa è una fonte secondaria: non ho letto il post originale di Microsoft.

Che cosa resta aperto

• Come l’attaccante abbia ottenuto la credenziale: ConnectWise non l’ha spiegato.
• L’impatto sui dati: Huntress non conferma accessi a posta o file. Le letture della directory tramite Graph non lasciano tracce di audit, quindi l’assenza di prove non è prova di assenza. Todyl aggiunge che nei tenant con backup attivo che ha esaminato i log delle attività Graph non erano raccolti, e che le letture dell’attaccante e quelle del servizio legittimo non si distinguono.
• L’attore: nessuna fonte lo identifica. Huntress segnala che le modifiche ai ruoli e alle applicazioni arrivano da spazio IPv6 privato di Azure, che non permette da solo di identificare chi operava, e che non ha collegato le due fasi allo stesso operatore.
• I conteggi: la pagina Huntress letta indica 162 tenant. Il dato di 173 compare su The Hacker News, attribuito a Huntress, ma non l’ho trovato nella pagina Huntress.
• Le app disabilitate: nell’aggiornamento del 17 ottobre alle 10:30 (ora della costa orientale degli Stati Uniti) Huntress scriveva che le app Cloud Management per Exchange Online, Teams e SharePoint Online non risultavano disabilitate da ConnectWise. Nel successivo aggiornamento, alle 17:15, riferisce che ConnectWise ha comunicato di averle disabilitate. ConnectWise indica le 07:00 UTC dello stesso giorno. L’azione del fornitore e l’impostazione nel singolo tenant sono due controlli distinti, come precisa lo stesso ConnectWise.
• Le segnalazioni esterne: Huntress riferisce di aver ricevuto da fuori della propria flotta segnalazioni di attività simili, anche con intervento manuale, e dichiara di non averle verificate.
• La causa tecnica: ConnectWise scrive che la ricerca ha individuato identità applicative compromesse, che non è stabilito se una vulnerabilità di prodotto abbia contribuito e che il modo in cui la credenziale è stata esposta resta sotto indagine.
• Le ricadute a valle: ConnectWise non ha identificato compromissioni confermate nei clienti, ma precisa che questo non garantisce l’assenza di attività non autorizzate. Non ha rilevato accessi dell’attaccante alla rete interna o agli endpoint.

Meccanica dell’abuso: identità applicativa, consenso OAuth, token Graph

Perché MFA e protezioni utente non intervengono

L’accesso è dell’applicazione, non di un utente. Il backup ha bisogno di leggere e ripristinare caselle, file, chat Teams e dati di directory, e il consenso amministrativo concesso in ciascun tenant gli dà questi permessi. Huntress spiega che la credenziale usata è una client assertion: vive nel tenant del fornitore, quindi nessuna azione del cliente può averla prodotta. Todyl aggiunge che nessun utente, dispositivo o richiesta MFA entra nel flusso, e che la politica di Conditional Access risulta non applicata nei log da lui osservati.

Perché la revoca lato fornitore non basta

Tre elementi, tutti documentati, spiegano perché il caso non si chiude con la rotazione del segreto.

• I token già emessi restano validi. ConnectWise lo dichiara; SpecterOps e Todyl indicano fino a 90 minuti dopo la disattivazione dell’app nel tenant.
• La disattivazione non toglie le credenziali già aggiunte. Lo scrive Huntress: occorre controllare le credenziali di tutte le applicazioni del tenant.
• Un’identità diversa può aver lasciato un accesso. Il caso dei secret aggiunti, validi fino al 2028, a uno strumento di gestione e a un’applicazione di sicurezza è un esempio di persistenza che sopravvive alla revoca originaria.

Huntress classifica la tecnica come aggiunta di credenziali cloud (MITRE ATT&CK T1098.001). Quando l’applicazione che riceve il secret è consentita nei tenant dei clienti di un MSP, il rischio può estendersi oltre il singolo tenant. Huntress dichiara di non aver visto che ciò sia accaduto.

Checklist per chi usa ConnectWise o qualunque app multi-tenant

Le indicazioni sono quelle pubblicate da Huntress, SpecterOps, Todyl e ConnectWise. Vanno adattate alle licenze Entra e alle politiche di ciascun tenant.

1. Disabilitare, senza cancellare, l’applicazione. Nel centro di amministrazione Entra, in Applicazioni aziendali, aprire le proprietà e impostare l’accesso a No. La cancellazione elimina il consenso e obbliga a riconsentire in fase di ripristino. Prima di intervenire conviene esportare i permessi concessi.
2. Cercare e disabilitare tutte le applicazioni ConnectWise e SkyKick presenti. ConnectWise elenca sette identificativi, quelli disabilitati il 17 ottobre alle 07:00. Vanno cercati per identificativo e non per nome, perché le installazioni più vecchie possono mostrare i nomi SkyKick Cloud Manager, e va verificata anche l’impostazione locale in ogni tenant e annotato l’Object ID:
   • Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae
   • Cloud Management: 2399d300-6fca-4e6a-a686-399fefe75b83
   • Cloud Management, MS Teams: 24205314-2b89-4e07-a2a4-579e898a5640
   • Cloud Management, Exchange Online: b78f6a77-d4e5-46fb-87e5-d1648bd02519
   • Cloud Management, MS Graph: 0de14c77-b9b0-4137-9360-34878a929827
   • Cloud Management, Partner Center: 412dcf96-176d-4b3a-a1b0-4981ad66971e
   • Cloud Management, SharePoint Online: b2b55f5b-7758-4719-8d8f-88ae172e6bdb
3. Consultare i log degli accessi dei service principal, non quelli degli utenti, filtrando per l’identificativo di Cloud Backup. Cercare indirizzi fuori dagli intervalli Microsoft e Azure, in particolare 144.172.64.128 (sistema autonomo AS14956, RouterHosting, secondo Huntress) e i due indirizzi aggiunti il 18 ottobre. Huntress consiglia di esaminare gli accessi dalle 01:00 UTC del 15 ottobre alle 02:00 UTC del 16 ottobre, e ConnectWise indica di partire dal 13 ottobre.
4. Controllare le credenziali, segreti e certificati, di tutte le applicazioni e registrazioni, in particolare strumenti di gestione e di sicurezza. Cercare quelle aggiunte dal 13 ottobre che nessuno ha creato.
5. Controllare i ruoli di directory assegnati a qualsiasi applicazione ConnectWise o SkyKick, in particolare Global Administrator e Privileged Authentication Administrator. Dopo la disattivazione, rimuovere i ruoli non concessi intenzionalmente.
6. Cercare nel registro di audit gli eventi “Add member to role”, “Update application” e “Add service principal credentials”. Huntress osserva che le app ConnectWise esaminate usano l’user agent kiota-dotnet, mentre le modifiche anomale usavano Python-urllib/3.12. Nessun user agent, da solo, è un indicatore affidabile.
7. Attivare i log di attività Microsoft Graph, se la licenza lo consente: non sono retroattivi. Chi ha Entra ID Free deve esportare subito i log, che si conservano sette giorni con Free e trenta con P1 e P2 (ConnectWise; Todyl indica sette giorni per Free).
8. Rivedere le esclusioni dai criteri di Conditional Access: se l’app è esclusa da un blocco per località, l’infrastruttura dell’attaccante non viene fermata.
9. Non riabilitare nulla finché ConnectWise non conferma il reset di tutte le credenziali e non pubblica le istruzioni di ripristino.

Una nota sull’esito: un registro pulito non esclude l’accesso. Huntress e Todyl lo ripetono, per i limiti di cui sopra.

Governance: il registro delle applicazioni di terze parti

Il caso ConnectWise Cloud Backup attacco supply chain mostra che ogni app di terzi con consenso amministrativo è un possibile percorso d’attacco. SpecterOps propone di mappare queste applicazioni, con permessi e percorsi verso gli asset più sensibili, usando AzureHound, strumento open source, e query BloodHound. Chi non usa SkyKick o Cloud Backup dovrebbe rimuovere il consenso. Le osservazioni di Todyl rendono il punto concreto: in nove tenant senza abbonamento di backup attivo l’identità ha comunque ottenuto token.

Le misure di contenimento che le fonti citano sono diverse e non equivalenti.

• Huntress indica politiche di gestione delle applicazioni, per limitare o bloccare i client secret e fissare una durata massima delle credenziali.
• Huntress indica anche di ridurre chi possiede i ruoli Application Administrator e Cloud Application Administrator, che possono aggiungere credenziali.
• Per il Conditional Access dei workload identity, Huntress precisa che serve una licenza aggiuntiva. Todyl scrive che il Conditional Access non si applica alle app multi-tenant di terzi, e che restano il consenso al minimo privilegio e la rimozione delle app inutilizzate.
• Huntress ha attivato App Instance Property Lock su tutte le proprie applicazioni per rilevare i tentativi di modifica.

Nessuna di queste misure sostituisce la revisione delle credenziali. Le fonti dicono che rendono più difficile usare un secret piantato o più facile notarlo.

Il quadro NIS2 per gli MSP italiani

Questa sezione si fonda su testi primari forniti dalla redazione: il D.Lgs. 138/2024 (versione di Normattiva vigente al 19 ottobre 2026), la Determinazione ACN 379907/2025 (parte dispositiva), la Determina 127434/2026, la determinazione sulla piattaforma NIS con l’articolo 18 sui fornitori rilevanti, il comunicato dell’ACN del 13 aprile 2026 e le risposte delle FAQ NIS dell’ACN sugli incidenti significativi. Aggiungo gli allegati 3 e 4 della Determinazione 379907/2025, che definiscono gli incidenti significativi di base, nel testo fornito dalla redazione.

Che cosa dicono le fonti primarie

I fornitori di servizi gestiti e di servizi di sicurezza gestiti compaiono nell’allegato I del decreto, settore 9 (gestione dei servizi TIC, business-to-business). Il decreto definisce il fornitore di servizi gestiti come il soggetto che installa, gestisce, fa funzionare o mantiene prodotti, reti, infrastrutture o applicazioni TIC, anche a distanza (articolo 2, comma 1, lettera iii). Sono soggetti essenziali se superano i massimali delle medie imprese, importanti se superano quelli delle piccole (articoli 3, comma 2, e 6).

Per un incidente significativo l’articolo 25, comma 5, prevede questi passaggi verso il CSIRT Italia:

• pre-notifica entro 24 ore da quando il soggetto è venuto a conoscenza dell’incidente, con l’indicazione, ove possibile, di un’origine illecita o malevola e di un impatto transfrontaliero;
• notifica entro 72 ore, con una valutazione iniziale di gravità e impatto e, se disponibili, gli indicatori di compromissione;
• relazione intermedia, se il CSIRT Italia la chiede;
• relazione finale entro un mese dalla notifica delle 72 ore, con descrizione, causa originale, misure adottate e impatto transfrontaliero; se l’incidente è ancora in corso, relazione mensile sui progressi e relazione finale entro un mese dalla conclusione.

Il comma 4 definisce significativo l’incidente che ha causato o può causare una grave perturbazione operativa o perdite finanziarie per il soggetto, oppure che ha avuto o può avere ripercussioni su altre persone con perdite considerevoli. Il comma 3 precisa che la notifica non espone il soggetto a una responsabilità maggiore di quella derivante dall’incidente. I commi 9 e 10 prevedono che, sentito il CSIRT Italia, il soggetto informi i destinatari dei servizi degli incidenti significativi e delle minacce significative, con le misure che possono adottare. L’articolo 26 consente a chiunque, anche fuori dal perimetro, di notificare in forma volontaria incidenti con impatto significativo, minacce e quasi-incidenti.

L’articolo 24, comma 2, lettera d, include fra le misure obbligatorie la sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori diretti e i fornitori di servizi. Il comma 3 chiede di tenere conto delle vulnerabilità specifiche di ogni fornitore e della qualità delle sue pratiche di sicurezza.

Quando parte il termine di 24 ore

Secondo la FAQ ISB.G.4 dell’ACN, il termine della pre-notifica decorre da quando il soggetto dispone, dopo un’analisi anche sommaria, di elementi oggettivi che indicano uno dei casi definiti negli allegati 3 (soggetti importanti) e 4 (soggetti essenziali) della Determinazione 379907/2025. L’ACN cita tre fonti di evidenza: segnalazioni esterne, come quelle del CSIRT Italia, segnalazioni interne, come quella di un utente al servizio di assistenza, ed eventi rilevati dal monitoraggio. La notifica completa segue senza ingiustificato ritardo e comunque entro 72 ore.

Gli incidenti significativi di base

Gli allegati 3 (soggetti importanti) e 4 (soggetti essenziali) elencano i casi in cui l’incidente è significativo. In tutti serve un’evidenza da parte del soggetto. Tre casi valgono per entrambe le categorie:

• IS-1: perdita di riservatezza, verso l’esterno, di dati digitali di proprietà del soggetto o sui quali esercita il controllo, anche parziale;
• IS-2: perdita di integrità di quei dati, con impatto verso l’esterno;
• IS-3: violazione dei livelli di servizio attesi dei servizi o delle attività, definiti secondo la misura DE.CM-01.

Solo per i soggetti essenziali l’allegato 4 aggiunge IS-4: evidenza di un accesso non autorizzato, o con abuso dei privilegi concessi, a dati digitali di proprietà del soggetto o sui quali esercita il controllo, anche parziale. La valutazione può basarsi anche sui parametri quali-quantitativi stabiliti con la misura DE.CM-01.

Chi notifica, tra cliente e fornitore

Le FAQ ISB.F.1, ISB.F.2 e ISB.F.3 distinguono tre casi, quando cliente e fornitore sono entrambi soggetti NIS.

• Incidente sui sistemi del cliente (ISB.F.1): l’obbligo è del cliente, che può poi coinvolgere il fornitore nella gestione. L’ACN fa l’esempio di un servizio di centro operativo di sicurezza o di servizi gestiti. Il cliente deve inoltre fare in modo, nei requisiti di fornitura (misura GV.SC-01), che il fornitore segnali subito gli eventi di sicurezza che toccano i suoi servizi.
• Incidente sui sistemi del fornitore (ISB.F.2): l’obbligo è del fornitore. È anche del cliente se l’incidente è significativo pure per i servizi e le attività del cliente. In quel caso notificano entrambi. L’ACN rinvia all’articolo 25, commi 9 e 10, per gli obblighi verso i destinatari dei servizi.
• Incidente sui sistemi del cliente, con servizio cloud del fornitore (ISB.F.3): notificano entrambi, salvo che il servizio sia IaaS o di hosting dell’infrastruttura del cliente. In quel caso l’obbligo è solo del cliente.

Nelle risposte lette le FAQ non usano la formula “non può essere delegato ai fornitori di servizi gestiti”, che ICT Security Magazine attribuisce alle FAQ nell’approfondimento su whistleblowing e NIS2. Per l’incidente sui sistemi del cliente, la sostanza coincide: l’obbligo resta al cliente, che può coinvolgere il fornitore nella gestione. Per l’incidente sui sistemi del fornitore, invece, le FAQ dicono che notifica il fornitore. La determinazione sulla piattaforma aggiunge che le notifiche le effettua il referente CSIRT, una persona fisica designata dal punto di contatto entro il 31 dicembre dell’anno di inserimento nell’elenco.

I termini dipendono dalla data di inserimento nell’elenco

La data del 15 gennaio 2026 è quella da cui si applica la Determinazione 379907/2025, non la scadenza dell’obbligo. L’articolo 3 della determinazione fissa i termini dalla ricezione della comunicazione di inserimento nell’elenco NIS: diciotto mesi per le misure di sicurezza di base e nove mesi per la notifica degli incidenti significativi di base. La FAQ ISB.G.3 conferma la regola. La Determina 127434/2026, in vigore dal 30 aprile 2026, stabilisce per i soggetti inseriti per la prima volta nel 2026 il 31 luglio 2027 per le misure e il 1° gennaio 2027 per la notifica. Per chi era in elenco nel 2025 e vi resta, i termini della 379907/2025 non cambiano.

I fornitori rilevanti e i contratti

La determinazione sulla piattaforma, in applicazione dal 15 aprile 2026, impone ai soggetti NIS di elencare i fornitori rilevanti nell’aggiornamento annuale, tra il 15 aprile e il 31 maggio. Per ciascuno vanno indicati denominazione, codice fiscale, Paese della sede legale, codici CPV delle forniture e criterio di rilevanza (articolo 18). I criteri sono due: la fornitura è riconducibile alle attività dell’allegato I, punti 8 e 9 del decreto, cioè infrastrutture digitali e servizi TIC, oppure la sua interruzione o compromissione ha un impatto significativo sulla capacità del soggetto di erogare i propri servizi (articolo 1, lettera ll). Il comunicato dell’ACN del 13 aprile 2026 colloca questa previsione nella Determinazione 127437/2026.

Per i contratti, la FAQ MSB.12 precisa che non è obbligatorio adeguare quelli già in essere. I requisiti di sicurezza sono obbligatori, salvo motivate e documentate ragioni, per i contratti stipulati, rinnovati o prorogati a partire dal termine per l’adozione delle misure. Per i soggetti in elenco entro il 31 dicembre 2025, il termine è di diciotto mesi dalla comunicazione di inserimento. La FAQ MSB.15 aggiunge che i requisiti vanno definiti solo per le forniture con potenziale impatto sulla sicurezza dei sistemi informativi.

Due punti restano di seconda mano. Il primo è la notifica al Garante entro 72 ore in caso di violazione di dati personali, riferita da ICT Security Magazine nell’approfondimento su whistleblowing e NIS2. Il secondo è il quadro generale degli adempimenti NIS2 del 2026, che qui è stato sostituito dai testi primari.

Che cosa ne segue per un MSP

Qui entra l’interpretazione. Un MSP italiano nel perimetro NIS che usa Cloud Backup ha due scenari distinti, secondo le FAQ. Se l’abuso della credenziale ha toccato il proprio tenant, vale il caso del fornitore (ISB.F.2): notifica l’MSP, e anche il cliente se l’incidente è significativo per i suoi servizi. Se ha toccato il tenant di un cliente, vale il caso del cliente (ISB.F.1): notifica il cliente, e l’MSP deve segnalargli subito ciò che rileva.

La valutazione spetta a ciascun ente e parte da elementi oggettivi, anche dopo un’analisi sommaria. Un’applicazione ConnectWise con consenso amministrativo, ad esempio, entra tra i fornitori da valutare per l’elenco dei fornitori rilevanti: a lettura nostra, una piattaforma di backup per Microsoft 365 erogata da un fornitore ICT è riconducibile al primo criterio. Spetta all’ente confermarlo. The Register osserva che gli MSP non sono tenuti a dichiarare le piattaforme che usano: i clienti finali possono non sapere di dipendere da ConnectWise.

Resta da applicare gli allegati al caso, ed è un’interpretazione. Per un MSP essenziale, un token Graph ottenuto con la credenziale abusata e usato per leggere dati del tenant può configurare IS-4, perché l’accesso non autorizzato a dati sotto il suo controllo basta, e non serve che i dati siano usciti. Per un MSP importante manca IS-4: contano IS-1, IS-2 e IS-3, e quindi serve l’evidenza di una perdita di riservatezza verso l’esterno, di una perdita di integrità o di un servizio sotto il livello atteso. Qui pesa il limite delle prove.

Huntress scrive che le letture della directory tramite Graph non lasciano tracce di audit e che nel tenant esaminato non si vede accesso a posta o file. L’assenza di evidenza, in quel caso, non equivale all’assenza di accesso. Se la sospensione del servizio di backup viola i livelli di servizio attesi dall’MSP verso i clienti, può scattare IS-3, per entrambe le categorie. Spetta all’ente stabilirlo caso per caso.

Sul piano contrattuale, ICT Security Magazine indica clausole su notifica tempestiva degli eventi, cooperazione nella risposta e diritto di audit. Per un’identità applicativa servono anche clausole specifiche: rotazione delle credenziali, avviso immediato di compromissione, elenco dei permessi concessi. Questa è una proposta redazionale, non un obbligo ricavato da una fonte.

Per i clienti senza obblighi di notifica, come molte piccole e medie imprese, resta la segnalazione volontaria al CSIRT Italia (articolo 26 del decreto). La guida dell’ACN alla notifica degli incidenti descrive il modulo online e consiglia di segnalare il prima possibile, ma riguarda il quadro precedente alla NIS2 e non va usata per le scadenze.

La seconda ondata del 15 ottobre e il perimetro dei bersagli

Huntress riferisce una seconda ondata, mirata, dello stesso indirizzo il 15 ottobre. Ha preso di mira, senza riuscirci, 16 tenant protetti da Huntress nei settori politica, sicurezza nazionale, commercio e materie prime critiche. La prima passata ha chiesto token Graph all’app SkyKick tra le 09:25 e le 12:35. La seconda, tra le 13:54 e le 14:20, è apparsa manuale e ha puntato su Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra e le API di gestione di Office 365. Quasi tutti questi tenant non usavano prodotti ConnectWise: dove l’applicazione non c’era, l’attacco è fallito.

Il profilo dei bersagli è un dato di Huntress. Che indichi spionaggio è un’interpretazione, e nessuna fonte lo afferma. ConnectWise dichiara di non poter discutere l’attribuzione, e iTnews scrive che non esiste alcuna attribuzione. Per sostenerla servirebbero elementi che oggi mancano: infrastruttura collegata, strumenti ricorrenti, un legame tra le fasi e un riscontro indipendente.

In breve

ConnectWise Cloud Backup attacco supply chain è un caso di identità applicativa legittima usata contro i clienti che l’avevano autorizzata. La revoca della credenziale del fornitore chiude solo una parte del problema. Restano i token già emessi, le credenziali aggiunte altrove e la domanda su quali dati siano stati letti. Per gli MSP italiani soggetti a NIS2 il caso mette alla prova tre cose: il registro delle applicazioni di terzi, la capacità di notificare senza attendere il fornitore e i contratti con chi gestisce identità e consensi.

https://www.ictsecuritymagazine.com/notizie/connectwise-cloud-backup-attacco-supply-chain/