Wprowadzenie do problemu / definicja
ConnectWise poinformował o incydencie bezpieczeństwa związanym z nieautoryzowanym dostępem do tożsamości aplikacyjnych używanych przez usługę Cloud Backup, wcześniej funkcjonującą pod marką SkyKick. Tego typu zdarzenie dotyczy jednego z najważniejszych obszarów współczesnego bezpieczeństwa chmury, czyli ochrony kont usługowych i aplikacji posiadających szerokie uprawnienia w środowiskach Microsoft 365.
W praktyce przejęcie poświadczeń aplikacyjnych może umożliwić wykonywanie operacji w tenantach klientów bez udziału użytkownika końcowego. To odróżnia taki incydent od klasycznego przejęcia konta pracownika, ponieważ aplikacje działające w modelu app-only często mają wysoki poziom zaufania i dostęp do wielu krytycznych zasobów.
W skrócie
- ConnectWise zresetował konta i poświadczenia w środowisku Cloud Backup objętym incydentem.
- Usługi Cloud Backup, SaaS Security i Cloud Management pozostają tymczasowo zawieszone.
- Firma twierdzi, że nie potwierdziła skutecznej aktywności napastnika we własnym monitorowanym środowisku po wdrożeniu działań ograniczających.
- Każdy potencjalnie dotknięty tenant Microsoft 365 wymaga jednak indywidualnej analizy.
- Istniejące archiwa kopii zapasowych mają pozostawać zaszyfrowane, odizolowane i nienaruszone.
Kontekst / historia
Incydent został publicznie opisany w październiku 2026 roku. Działania ograniczające rozpoczęto 17 października 2026 roku o godzinie 05:00 UTC, a kolejne komunikaty wskazywały na stopniowe odłączanie połączeń aplikacyjnych, zawieszenie usług powiązanych z Cloud Backup oraz zaangażowanie zewnętrznych ekspertów od reagowania na incydenty i analizy śledczej.
Sprawa ma szczególne znaczenie dla dostawców usług zarządzanych oraz organizacji korzystających z narzędzi zintegrowanych z Microsoft 365. Aplikacje backupowe i administracyjne bardzo często otrzymują rozległe uprawnienia do danych poczty, plików, Teams, Entra ID oraz mechanizmów przywracania. W efekcie kompromitacja jednej tożsamości aplikacyjnej może mieć skutki wykraczające poza pojedyncze konto użytkownika i obejmować wiele środowisk klientów.
Analiza techniczna
Z technicznego punktu widzenia incydent dotyczy nadużycia poświadczeń aplikacyjnych. W modelu app-only aplikacja uwierzytelnia się wobec Microsoft Entra ID za pomocą sekretu klienta lub certyfikatu, a następnie działa zgodnie z nadanymi wcześniej uprawnieniami. Taki mechanizm nie wymaga interakcji użytkownika, nie wywołuje monitów MFA i może być wykorzystywany z różnych lokalizacji sieciowych.
Według ujawnionych informacji zaobserwowano aktywność związaną z logowaniami aplikacyjnymi oraz zachowania sugerujące próbę utrwalenia dostępu. W co najmniej jednym analizowanym przypadku aplikacja miała samodzielnie uzyskać uprawnienia Global Administrator, a następnie dodać nowe sekrety do innych aplikacji w tenantcie. To scenariusz zgodny ze znanymi technikami persistence w środowiskach chmurowych, gdzie przejęta tożsamość aplikacyjna służy do rozszerzania dostępu i budowania dodatkowych ścieżek wejścia.
Dodatkowym wyzwaniem jest ograniczona widoczność telemetryczna. Operacje odczytu wykonywane przez Microsoft Graph nie zawsze pozostawiają pełny ślad pozwalający precyzyjnie ustalić zakres odczytanych danych. W rezultacie brak jednoznacznego dowodu eksfiltracji nie musi oznaczać, że do niej nie doszło. Publicznie wskazane adresy IP i wzorce aktywności mogą pomóc w polowaniu na ślady incydentu, ale nie powinny być traktowane jako jedyne kryterium detekcji.
Całe zdarzenie podkreśla ryzyko związane z uprzywilejowanymi aplikacjami SaaS. Jeśli aplikacja backupowa lub zarządzająca ma szerokie zgody administracyjne, przejęcie jej sekretu może zapewnić atakującemu dostęp odpowiadający realnym uprawnieniom tej aplikacji w każdym tenantcie, który wcześniej ją autoryzował.
Konsekwencje / ryzyko
Najpoważniejszym zagrożeniem jest możliwość uzyskania szerokiego, trudnego do zauważenia dostępu do zasobów Microsoft 365. W zależności od nadanych zgód może to obejmować pocztę w Exchange Online, dane z OneDrive i SharePoint, informacje z Teams, zasoby katalogowe Entra ID, a nawet operacje administracyjne.
Jeżeli aplikacja posiadała możliwość nadawania ról katalogowych lub modyfikowania innych aplikacji, skala problemu rośnie z prostego nadużycia poświadczeń do potencjalnej pełnej kompromitacji warstwy tożsamości. To szczególnie niebezpieczne, ponieważ atakujący może utrzymać dostęp nawet po początkowej rotacji sekretów.
Nie można też pominąć skutków operacyjnych. Wstrzymanie Cloud Backup oznacza brak nowych kopii zapasowych, ograniczony dostęp do archiwów przez interfejs usługi oraz brak możliwości przywracania danych do czasu bezpiecznego odtworzenia środowiska. Dla części organizacji przekłada się to bezpośrednio na wzrost ryzyka dla ciągłości działania.
W modelu MSP zagrożenie nabiera dodatkowego wymiaru. Jedna skompromitowana aplikacja dostawcy może stać się pomostem do wielu tenantów klientów, co czyni ten incydent przykładem ryzyka w łańcuchu dostaw usług zarządzanych.
Rekomendacje
Organizacje korzystające z ConnectWise Cloud Backup lub powiązanych integracji powinny utrzymać wyłączone połączenia aplikacyjne do momentu otrzymania formalnych instrukcji producenta dotyczących bezpiecznego przywrócenia usługi. Jednocześnie nie należy usuwać aplikacji pochopnie, jeśli mogłoby to utrudnić późniejsze odzyskanie prawidłowej konfiguracji lub analizę śledczą.
Konieczna jest pełna weryfikacja tenantów Microsoft 365 i Entra ID, obejmująca zarówno logi, jak i konfigurację aplikacji. W szczególności warto:
- przeanalizować logi logowań aplikacyjnych oraz dzienniki audytowe,
- zidentyfikować aplikacje ConnectWise i historycznie powiązane z marką SkyKick,
- sprawdzić, czy aplikacje posiadają role uprzywilejowane, zwłaszcza Global Administrator,
- przejrzeć wszystkie sekrety klienta i certyfikaty dodane od połowy października 2026 roku,
- zbadać zdarzenia związane z dodawaniem członków do ról, aktualizacjami aplikacji oraz dodawaniem poświadczeń do service principal i app registration.
Z perspektywy obronnej warto również wzmocnić zabezpieczenia dla workload identities:
- ograniczyć liczbę ról mogących zarządzać aplikacjami i ich poświadczeniami,
- skrócić czas życia sekretów i preferować certyfikaty tam, gdzie to możliwe,
- przejrzeć wyjątki Conditional Access dotyczące aplikacji usługowych,
- monitorować nietypowe logowania service principal spoza oczekiwanej infrastruktury,
- regularnie audytować nadane uprawnienia aplikacyjne zgodnie z zasadą najmniejszych uprawnień.
Dla zespołów SOC i IR kluczowe jest zachowanie materiału dowodowego przed wprowadzaniem zmian. Dopiero po zabezpieczeniu logów, ocenie zakresu zdarzenia i potwierdzeniu wpływu operacyjnego należy usuwać nieautoryzowane sekrety, role oraz modyfikacje aplikacji.
Podsumowanie
Incydent ConnectWise pokazuje, że tożsamości aplikacyjne stały się jednym z najważniejszych wektorów ryzyka w ekosystemie Microsoft 365 i usługach zarządzanych. Sam reset poświadczeń oraz czasowe zawieszenie usług ograniczają zagrożenie natychmiastowe, ale nie rozwiązują automatycznie problemu po stronie tenantów, w których mogło dojść do nadużycia zgód aplikacyjnych lub utrwalenia dostępu.
Dla organizacji i partnerów MSP najważniejsze pozostają obecnie: szczegółowa analiza logów, przegląd aplikacji uprzywilejowanych, kontrola nowych sekretów oraz bardzo ostrożne przywracanie integracji dopiero po pełnej walidacji bezpieczeństwa.
Źródła
- ConnectWise Resets Credentials as Cloud Backup Remains Offline After Security Incident — https://thehackernews.com/2026/10/connectwise-resets-credentials-as-cloud.html
- ConnectWise Trust Center: October 20, 2026 Cloud Backup Service Interruption Advisory — https://www.connectwise.com/company/trust/advisories
- ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks — https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access