W aktualizacji z 17 października 2026 r. ConnectWise informuje o unieważnieniu certyfikatów używanych przez objęte incydentem połączenia aplikacyjne oraz wspólnych danych dostępowych Cloud Backup. W tej aktualizacji firma podaje, że zaszyfrowane archiwa są zachowane i odizolowane, ale dostęp do nich oraz przywracanie kopii są niedostępne. ConnectWise nie może też ustalić, czy w konkretnych tenantach klientów doszło do nieautoryzowanej aktywności. Komunikat ConnectWise
To dwa odrębne obszary: archiwa kopii przechowywane przez dostawcę i dane w działających środowiskach Microsoft 365 klientów. Logowania aplikacji zostały zaobserwowane, ale część odczytów nie dawała się przypisać do konkretnego działania.
Logowania aplikacji w Microsoft 365
ConnectWise Cloud Backup, wcześniej znany jako SkyKick Backup, logował się do Microsoft 365 jako aplikacja, a nie użytkownik. Uwierzytelnianie app-only pozwala aplikacji korzystać z wcześniej przyznanych jej uprawnień bez logowania pracownika i jego monitu MFA. Huntress podaje, że wykorzystane dane obejmowały tajemnicę API przechowywaną po stronie dostawcy.
Do logowań doszło 15 października. Huntress zaobserwował je między 06:13 a 08:34 UTC, a Todyl odnotował logowania między 07:11 a 08:47 UTC w monitorowanych przez siebie tenantach. Do 19:00 UTC 16 października Huntress odnotował nieautoryzowane logowania w 162 tenantach objętych jego obserwacją. Ustalenia Huntress
Administratorzy Microsoft 365 mogą szukać tych zdarzeń w Microsoft Entra ID w kategorii Service principal sign-ins i filtrować je według identyfikatora aplikacji Cloud Backup: 506e08f9-6e9a-4da4-942b-a099a03644ae. ConnectWise wskazuje, że domyślna zakładka User sign-ins nie pokazuje tego rodzaju uwierzytelniania.
Microsoft Threat Intelligence określa aktywność jako trwający atak na łańcuch dostaw. Oryginalny wpis jest po angielsku.
Osobna aplikacja zmieniała uprawnienia
ConnectWise Cloud Management - MS Teams to inna aplikacja niż Cloud Backup. Huntress zaobserwował, że aplikacje Cloud Management przypisywały role katalogowe w blisko 50 monitorowanych tenantach, najczęściej Exchange Administrator. W jednym tenantcie aplikacja MS Teams nadała sobie rolę Global Administrator, a następnie dodała tajne klucze klienta do dwóch innych aplikacji, w tym do aplikacji Huntress przypisanej do tego tenanta. Cała sekwencja trwała około pięciu minut. Szczegółowy opis Huntress
Todyl nie odnotował zmian katalogowych przypisanych aplikacji Cloud Backup w tenantach, które badał. Jego ustalenie dotyczyło tej aplikacji i tej grupy tenantów; obserwacja Huntress dotyczyła odrębnej aplikacji zarządzającej i jednego tenanta.
Dlaczego części odczytów nie dało się przypisać
W tenantach z aktywną subskrypcją kopii zapasowych ta sama tożsamość aplikacji obsługiwała prawidłowe zadania backupu i aktywność nieautoryzowaną. Todyl podaje, że nie zbierano tam dzienników aktywności Microsoft Graph zawierających adres IP dla każdego żądania. Odczytów nie można więc było wiarygodnie rozdzielić na działania usługi i intruza. Analiza Todyl
W tenantach bez aktywnej subskrypcji Todyl nie znalazł po wydaniu tokenu zapisów odczytu skrzynek pocztowych ani plików; nie miał też dowodów na masowe kopiowanie w tych środowiskach. ConnectWise z kolei nie ma bezpośredniego wglądu w aktywność w tenantach klientów. Te ograniczenia pozostawiają odczyty bez przypisanego źródła poza możliwością rozstrzygnięcia, które działania należały do backupu, a które do atakującego.
Skutek przerwy dla kopii zapasowych
W aktualizacji z 17 października ConnectWise podaje, że podczas przerwy nie działały zaplanowane zadania kopii zapasowych. Nowe lub zmienione dane mogły więc nie trafić do istniejących punktów odzyskiwania.
