ConnectWise sospende il backup cloud dopo la compromissione delle identità applicative che colpisce i tenant di Microsoft 365

ConnectWise ha sospeso Cloud Backup dopo l'accesso non autorizzato alle identità applicative usate per entrare nei tenant Microsoft 365. Indagine in corso.

Aggiungi CyberWorldOpsalle tue fonti preferite su Google
ConnectWise sospende il backup cloud dopo la compromissione delle identità applicative che colpisce i tenant di Microsoft 365
Cloud Security

Immagine illustrativa generata con AI

ConnectWise ha sospeso il servizio Cloud Backup dopo che alcuni aggressori non identificati hanno ottenuto accesso non autorizzato alle sue identità applicative e le hanno usate per entrare nei tenant di Microsoft 365.

L'azienda afferma di aver rilevato il problema il 14 ottobre 2026 attraverso il proprio monitoraggio della sicurezza, avviando subito un'indagine. Secondo il resoconto di ConnectWise riportato da The Hacker News, alle 07:00 UTC del 17 ottobre l'azienda ha disattivato sette identità applicative e revocato i certificati che supportavano le connessioni interessate.

Un altro rapporto indica che ConnectWise ha annunciato l'interruzione di Cloud Backup alle 05:01 UTC del 17 ottobre. I due orari si riferiscono rispettivamente all'azione di mitigazione segnalata e all'annuncio del servizio, e non vanno quindi trattati come un unico riferimento temporale.

La sospensione impedisce nuove autenticazioni attraverso le connessioni interessate, ma non rimuove le credenziali, i permessi o gli altri meccanismi di persistenza che gli aggressori potrebbero aver già creato all'interno dei tenant dei clienti.

Servizi di backup e gestione messi offline

Cloud Backup, precedentemente noto come SkyKick Cloud Backup, offre backup e ripristino per Microsoft 365 e Google Workspace. ConnectWise ha inoltre sospeso temporaneamente SaaS Security e Cloud Management mentre verifica l'incidente.

I backup pianificati non sono in esecuzione e i clienti non possono al momento usare gli archivi di backup interessati né le funzioni di ripristino. ConnectWise afferma che gli archivi esistenti restano cifrati, isolati e conservati. L'azienda non ha riscontrato prove che i backup archiviati o i dati di backup dei partner siano stati acceduti o compromessi.

ConnectWise ha dichiarato che le credenziali condivise di Cloud Backup coinvolte nell'incidente non sono più valide. Tuttavia, i token di accesso emessi prima della revoca possono restare utilizzabili fino alla loro scadenza o fino a un'invalidazione separata. Anche disattivare la connessione originale non neutralizza le credenziali o i permessi inseriti tramite altre identità applicative.

L'azienda ha elencato le sette identità disattivate:

Nome applicazione ID applicazione (client)
ConnectWise Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83
ConnectWise Cloud Management - MS Teams 24205314-2b89-4e07-a2a4-579e898a5640
ConnectWise Cloud Management - Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519
ConnectWise Cloud Management - MS Graph 0de14c77-b9b0-4137-9360-34878a929827
ConnectWise Cloud Management - Partner Center 412dcf96-176d-4b3a-a1b0-4981ad66971e
ConnectWise Cloud Management - SharePoint Online b2b55f5b-7758-4719-8d8f-88ae172e6bdb

Nei tenant più vecchi, alcune applicazioni di Cloud Management possono comparire con il nome SkyKick Cloud Manager.

ConnectWise non ha ancora stabilito se una vulnerabilità in uno dei suoi prodotti abbia contribuito alla compromissione. Il meccanismo con cui le credenziali delle applicazioni sono state esposte è ancora oggetto di indagine.

Le credenziali delle applicazioni aggirano l'autenticazione degli utenti

L'attacco non richiedeva la password di un utente di Microsoft 365. Secondo i ricercatori, l'attaccante si è autenticato come applicazione di backup presentando il suo segreto a Microsoft Entra ID e richiedendo token con permessi che i clienti avevano già concesso.

Trattandosi di autenticazione basata su applicazione e non di un accesso interattivo di un utente, l'MFA degli utenti non si applicava. Revocare le sessioni utente, da sola, non interromperebbe l'accesso dell'applicazione.

Questi permessi già esistenti erano molto ampi. Secondo Todyl, l'applicazione poteva tecnicamente leggere e scrivere email e allegati, file di OneDrive e SharePoint e chat di Teams. Ciò descrive quanto consentiva l'autorizzazione, non la prova che tutti quei tipi di dati siano stati effettivamente acceduti.

Anche i permessi di gestione più ampi hanno aperto percorsi verso la persistenza. Huntress ha osservato service principal associati a ConnectWise Cloud Management che si assegnavano ruoli di directory in quasi 50 tenant monitorati, più spesso con il ruolo Exchange Administrator. In un tenant, il service principal Cloud Management - MS Teams si è assegnato il ruolo Global Administrator e ha aggiunto credenziali a un'applicazione di gestione di un MSP e all'applicazione di Huntress. Secondo Huntress, la sequenza è durata circa cinque minuti.

Secondo quanto riportato da BleepingComputer, Microsoft ha descritto l'operazione come un attacco attivo alla supply chain e ha valutato che l'attore abbia probabilmente abusato dei permessi esistenti, tra cui Directory.ReadWrite.All. Stando alle informazioni disponibili, Microsoft avrebbe osservato una backdoor dopo un'autenticazione riuscita del service principal, seguita da ricognizione su Microsoft Graph e tentativi di aggiungere credenziali.

L'attività di accesso e la compromissione confermata sono misure diverse

Huntress ha rilevato attività di accesso dall'indirizzo IP dell'attaccante su quasi 1.000 tenant Entra. Di questi accessi, 300 sono riusciti, ma un'autenticazione riuscita non sempre dava accesso al tenant: in alcuni casi, il service principal richiesto non era presente.

Nel proprio ambiente, i ricercatori di Huntress hanno individuato almeno 162 tenant compromessi. Questo dato è distinto dai quasi 1.000 tenant con attività di accesso e dai 300 accessi riusciti.

Altri risultati riguardano campioni più ristretti:

  • Todyl ha esaminato nove tenant e vi ha trovato solo attività di accesso. In quei tenant non ha individuato creazioni di account, modifiche di permessi o password, né persistenza tramite l'applicazione di backup.
  • Huntress ha confermato l'abuso dell'applicazione Teams in un tenant.
  • Quasi 50 tenant monitorati da Huntress hanno mostrato auto-assegnazioni di ruoli di directory che coinvolgevano service principal di ConnectWise Cloud Management.
  • Una seconda ondata mirata ha scelto 16 tenant nei settori delle politiche pubbliche, della sicurezza nazionale, del commercio e delle materie prime critiche, ma secondo Huntress quei tentativi sono falliti.

Huntress ha collegato i tentativi automatizzati che usavano curl/7.88.1 al 13 e 14 ottobre 2026. ConnectWise ha rilevato il problema più ampio il 14 ottobre.

Il 15 ottobre, Huntress ha registrato l'ultimo accesso malevolo dall'indirizzo originale alle 08:45 UTC. Una successiva scansione mirata ai token Graph associati all'applicazione SkyKick è stata eseguita tra le 09:25:04 e le 12:35:50 UTC. Una seconda scansione, apparentemente manuale, contro gli stessi 16 tenant si è svolta tra le 13:54:39 e le 14:20:24 UTC, prendendo di mira le API di Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra e Office 365 Management.

Huntress ha dichiarato di non aver individuato nuove attività malevole dopo il 15 ottobre. Anche ConnectWise ha affermato di non aver rilevato attività riuscite negli ambienti che monitora dall'applicazione delle proprie misure di mitigazione, avvertendo però di non poter osservare direttamente gli ambienti dei clienti a valle.

Indicatori e verifiche sui tenant

L'indicatore di rete principale è:

  • Indirizzo IP: 144.172.64[.]128

Tra gli user agent associati all'attività figurano:

  • python-urllib/3.12
  • python-requests/2.31
  • python-requests/2.34.2
  • curl/7.88.1

I partner di ConnectWise dovrebbero esaminare sia i propri ambienti Microsoft 365 sia ogni tenant cliente gestito, incluse le connessioni SkyKick inattive. Le verifiche consigliate includono:

  1. Cercare nei log di accesso dei service principal di Entra i sette ID applicazione e gli indirizzi di origine inattesi, in particolare 144.172.64[.]128.
  2. Controllare gli accessi di tutte le identità dal 13 ottobre 2026 in poi.
  3. Conservare i log di accesso e di audit prima che le azioni di contenimento modifichino le prove disponibili.
  4. Verificare le credenziali, i segreti e i certificati delle applicazioni per individuare aggiunte non autorizzate effettuate dal 13 ottobre.
  5. Esaminare le concessioni di consenso OAuth, i ruoli di directory, i proprietari delle applicazioni, le trust di federazione e le modifiche recenti alle policy.
  6. Cercare credenziali di recente aggiunta su altre applicazioni attendibili, non solo sull'identità originale di ConnectWise.
  7. Controllare in Exchange eventuali inoltri, regole della casella o regole di trasporto non autorizzate e l'accesso delegato alle caselle.
  8. Esaminare le altre integrazioni di Cloud Management e indagare sulle identità modificate o usate durante l'attività sospetta.

Huntress raccomanda inoltre di limitare chi detiene i ruoli Application Administrator e Cloud Application Administrator, di usare le policy di gestione delle applicazioni per limitare i client secret e la durata delle credenziali e di applicare l'Accesso condizionale per le identità dei carichi di lavoro, ove lo consentano le licenze. Anche Microsoft Entra ID Protection può identificare service principal a rischio.

Questi controlli non sostituiscono la revisione delle credenziali. La revoca di ConnectWise interrompe le nuove autenticazioni attraverso le connessioni interessate, ma ogni tenant deve ancora accertare se l'attaccante abbia creato un percorso separato che sopravvive alla rimozione della credenziale originale.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Torna alla home

Ultime notizie di cybersecurity

Tutte le notizie di cybersecurity →