Wprowadzenie do problemu / definicja
Incydent związany z ConnectWise pokazuje, jak poważnym zagrożeniem stały się tożsamości aplikacyjne oraz uprzywilejowane integracje w środowiskach chmurowych. W tego typu modelu bezpieczeństwa aplikacja dostawcy usług może posiadać szeroki dostęp do zasobów klientów, co oznacza, że przejęcie jednego elementu infrastruktury może otworzyć drogę do wielu dzierżaw jednocześnie.
W omawianym przypadku nie chodziło o klasyczne przełamanie zabezpieczeń po stronie pojedynczej organizacji, lecz o wykorzystanie poświadczenia powiązanego z usługą dostawcy. To właśnie dlatego incydent ma szczególne znaczenie dla partnerów MSP, zespołów SOC oraz administratorów Microsoft 365.
W skrócie
- ConnectWise czasowo wyłączył wybrane usługi chmurowe po wykryciu nieautoryzowanego dostępu.
- Incydent dotyczył tożsamości aplikacyjnych używanych do obsługi środowisk Microsoft 365 klientów.
- Działania ochronne objęły usługi Cloud Backup, a następnie także SaaS Security oraz Cloud Management.
- Publicznie opisane ustalenia wskazują na nadużycie skompromitowanego poświadczenia służącego do uzyskiwania tokenów dostępowych.
- Ryzyko obejmuje nie tylko niedostępność usług, ale również możliwość zmian konfiguracji i utrwalenia dostępu w tenantach klientów.
Kontekst / historia
ConnectWise poinformował o wykryciu podejrzanej aktywności w środowisku Cloud Backup i zdecydował się na ograniczenie działania usługi. Według dostępnych informacji Cloud Backup została wyłączona 17 października 2026 roku, około 12 godzin po rozpoczęciu analizy incydentu. Następnie, 18 października 2026 roku, firma rozszerzyła działania zapobiegawcze na kolejne usługi, w tym SaaS Security oraz Cloud Management.
Zdarzenie wpisuje się w szerszy trend ataków wymierzonych w dostawców usług zarządzanych i aplikacje wielodzierżawne. W modelu MSP zaufane integracje często posiadają szerokie uprawnienia administracyjne do Microsoft Graph, Exchange Online, Teams czy SharePoint Online. To sprawia, że kompromitacja sekretu, certyfikatu lub innej formy poświadczenia może pozwolić napastnikowi na poruszanie się między środowiskami klientów bez konieczności przełamywania zabezpieczeń każdej organizacji oddzielnie.
Analiza techniczna
Publicznie opisane ustalenia wskazują, że atak opierał się na wykorzystaniu skompromitowanego poświadczenia przypisanego do usługi Cloud Backup. W logach Microsoft 365 obserwowano logowania z użyciem mechanizmu client assertion, co sugeruje użycie poświadczenia kontrolowanego po stronie dostawcy. To istotny szczegół, ponieważ oznacza, że poprawne uwierzytelnienie nie musiało wynikać z błędu konfiguracji po stronie klienta.
Według ujawnionych informacji aktywność objęła 162 dzierżawy Microsoft 365 w dniach 15–16 października 2026 roku. Charakter działań sugerował operację zautomatyzowaną: przechodzenie przez kolejne tenanty, uzyskiwanie tokenów Microsoft Graph i wykonywanie operacji według przygotowanej listy celów. Taki schemat jest typowy dla kampanii nastawionych na skalę, w których przejęcie jednej zaufanej integracji daje szeroki efekt operacyjny.
W analizach zwrócono również uwagę na aktywność powiązaną z adresem IP, który wcześniej miał być wykorzystywany w atakach typu password spraying. W co najmniej jednym przypadku zaobserwowano zachowanie aplikacji Cloud Management dla Microsoft Teams polegające na przypisaniu sobie roli Global Administrator, a następnie wykonaniu skryptu dodającego nowe client secrets do aplikacji używanych w środowisku MSP. Taki łańcuch czynności może wskazywać na próbę utrwalenia dostępu, rozszerzenia uprawnień oraz przygotowania zaplecza do dalszych działań.
Jednocześnie warto podkreślić, że samo udane logowanie nie zawsze oznaczało pełny dostęp operacyjny. W części środowisk brak odpowiedniego service principal mógł ograniczać możliwość wykonania działań. Mimo to skala aktywności pokazuje, jak niebezpieczny jest model oparty na szeroko delegowanych uprawnieniach aplikacyjnych.
Konsekwencje / ryzyko
Najbardziej bezpośrednim skutkiem incydentu były zakłócenia w działaniu kluczowych usług. Klienci mogli odczuć wpływ na harmonogramy backupu, dostęp do archiwów, procesy odtwarzania danych, monitoring bezpieczeństwa SaaS oraz funkcje zarządzania użytkownikami i licencjami. W praktyce oznacza to wzrost ryzyka przestojów i ograniczenie zdolności do szybkiego reagowania na inne incydenty.
Poważniejsze zagrożenie dotyczy jednak integralności konfiguracji tenantów Microsoft 365. Jeśli napastnik uzyskał skuteczne tokeny aplikacyjne lub uprzywilejowany dostęp do wybranych środowisk, mógł potencjalnie nadawać role administracyjne, dodawać sekrety do aplikacji, modyfikować ustawienia Entra ID lub wdrażać inne mechanizmy trwałości. Takie zmiany mogą pozostać niezauważone nawet po przywróceniu usług przez dostawcę.
Dla całego sektora MSP incydent jest również ostrzeżeniem przed koncentracją uprawnień. Im więcej klientów obsługuje pojedyncza aplikacja lub tożsamość usługowa, tym większą wartość przedstawia ona dla atakujących. Naruszenie po stronie dostawcy może więc bardzo szybko przybrać charakter incydentu typu supply chain.
Rekomendacje
Organizacje korzystające z integracji MSP i aplikacji wielodzierżawnych powinny niezwłocznie przeprowadzić przegląd logów Entra ID, Microsoft 365 oraz Microsoft Graph. Szczególną uwagę warto zwrócić na nietypowe logowania aplikacyjne, użycie mechanizmu client assertion, tworzenie nowych client secrets oraz zmiany w uprawnieniach aplikacji. Kluczowy okres analizy obejmuje dni od 13 do 17 października 2026 roku.
Weryfikacja powinna objąć wszystkie enterprise applications i app registrations powiązane z usługami zewnętrznymi, zwłaszcza te posiadające dostęp do Exchange Online, Teams, SharePoint Online i Microsoft Graph.
- Sprawdzenie listy przyznanych uprawnień aplikacyjnych i delegowanych.
- Kontrola nowych lub zmodyfikowanych sekretów oraz certyfikatów.
- Weryfikacja przypisań ról administracyjnych.
- Przegląd zmian w consentach administracyjnych.
- Identyfikacja nietypowych service principals utworzonych lub aktywowanych w badanym okresie.
W środowiskach objętych ryzykiem warto rozważyć rotację sekretów aplikacyjnych, ponowne zatwierdzenie zaufanych integracji oraz unieważnienie aktywnych tokenów tam, gdzie jest to możliwe operacyjnie. Dobrym krokiem jest także porównanie bieżącej konfiguracji tenantu ze stanem referencyjnym, aby wykryć subtelne zmiany, które nie musiały wywołać klasycznych alertów bezpieczeństwa.
W dłuższej perspektywie organizacje powinny ograniczać uprawnienia aplikacyjne zgodnie z zasadą najmniejszych uprawnień, segmentować integracje pomiędzy klientami, rozwijać monitoring zachowań aplikacji oraz regularnie audytować tożsamości nieosobowe. Niezbędne są także playbooki reagowania na incydenty dotyczące aplikacji SaaS i service principals, ponieważ tradycyjne procedury skupione wyłącznie na kontach użytkowników są w takich przypadkach niewystarczające.
Podsumowanie
Incydent ConnectWise to kolejny sygnał, że tożsamości aplikacyjne i zaufane integracje chmurowe stały się jednym z kluczowych obszarów ryzyka w nowoczesnych środowiskach IT. Czasowe wyłączenie usług było działaniem ochronnym, ale z perspektywy klientów najważniejsze pozostaje ustalenie, czy w ich tenantach Microsoft 365 doszło do zmian konfiguracji, rozszerzenia uprawnień lub ustanowienia trwałości.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: pełna widoczność nad aplikacjami uprzywilejowanymi, sekretami i service principals musi być dziś traktowana tak samo poważnie jak monitoring kont użytkowników. Bez tego nawet poprawne logowanie aplikacji może ukrywać aktywny incydent o dużej skali.
Źródła
- https://www.securityweek.com/connectwise-suspends-cloud-services-in-response-to-cyberattack/
- https://status.connectwise.com/
- https://www.connectwise.com/
- https://www.huntress.com/
- https://learn.microsoft.com/en-us/entra/