ConnectWise: gdy aplikacja do kopii zapasowych staje się napastnikiem, a MFA nic nie daje

17 października 2026 roku firma ConnectWise odcięła klientom dostęp do usługi Cloud Backup (dawniej SkyKick Cloud Backup) i wyłączyła siedem tożsamości aplikacji, po tym jak napastnicy wykorzystali je do logowania się do klienckich tenantów Microsoft 365.

W komunikacie bezpieczeństwa firma poinformowała, że „wykryła nieautoryzowany dostęp do tożsamości aplikacji w środowisku ConnectWise Cloud Backup". Usługi Cloud Backup, SaaS Security oraz Cloud Management pozostają zawieszone.

To atak na łańcuch dostaw i Microsoft Threat Intelligence określił go jako atak aktywny. Ważniejszy od samej etykiety jest jednak mechanizm, bo omija on dwa zabezpieczenia, na których opiera się większość organizacji:

• Nie skradziono żadnych haseł. Napastnik uwierzytelnił się jako aplikacja, używając jej własnego sekretu.

• MFA nie miało tu zastosowania. Logowania odbywały się wyłącznie w trybie aplikacyjnym, wykonywane przez automatyczny skrypt. Brak logowania użytkownika oznacza brak drugiego składnika do potwierdzenia.

Dwie rzeczy z pierwotnego opisu tematu wymagają korekty. Zakres jest szerszy niż sam Cloud Backup. Aplikacje ConnectWise Cloud Management dla Teams, Exchange Online, Graph, SharePoint i Partner Center również są objęte incydentem, a to właśnie tam zaobserwowano najgroźniejsze zachowania. Liczba ofiar zależy natomiast w dużym stopniu od tego, kto liczy.

Co się wydarzyło

Kalendarium

Ile było ofiar

Tu doniesienia się rozchodzą i warto być precyzyjnym:

• Huntress zidentyfikował co najmniej 162, a później 173 skompromitowane tenanty w obrębie własnego monitorowanego środowiska.

• Niezależnie od tego Huntress odnotował próby logowania z adresu napastnika wobec blisko 1000 tenantów Microsoft 365, z czego ponad 300 zakończyło się powodzeniem.

To dwa różne pomiary, a nie dane sprzeczne. Pierwszy pokazuje, co widzi jeden dostawca bezpieczeństwa u swoich klientów, drugi opisuje stosunek prób do sukcesów. Rzeczywista suma w skali wszystkich partnerów ConnectWise pozostaje nieznana. BleepingComputer odnotował, że liczba ofiar i skala kradzieży danych są wciąż niejasne.

Do czego napastnik mógł dotrzeć

Ponieważ aplikacja miała już szerokie uprawnienia nadane przez klientów dawno temu, logowania dawały napastnikowi techniczną możliwość odczytu i zapisu poczty wraz z załącznikami, plików OneDrive i SharePoint oraz czatów Teams, zgodnie z analizą firmy Todyl.

Microsoft ocenił, że napastnik najprawdopodobniej nadużył istniejących uprawnień, w tym Directory.ReadWrite.All, czyli mniej więcej najsilniejszego uprawnienia, jakie można nadać.

Rozpoznanie i utrwalanie dostępu

W tym miejscu relacje różnią się w sposób bardzo pouczający.

Todyl przeanalizował dziewięć tenantów i znalazł wyłącznie aktywność logowania: żadnych utworzonych kont, dodanych uprawnień, zmienionych haseł ani utrwalonego dostępu przez aplikację backupową.

Huntress zaobserwował coś gorszego na około 50 tenantach: service principals aplikacji ConnectWise Cloud Management (Exchange Online, Teams, Microsoft Graph) same przypisywały sobie role katalogowe, najczęściej Exchange Administrator.

W jednym tenancie Huntress zaobserwował pełne utrwalenie dostępu w czasie około pięciu minut. Aplikacja Cloud Management – MS Teams przyznała sobie rolę Global Administrator, a następnie dodała poświadczenia do narzędzia zarządzania MSP oraz do własnej aplikacji Huntress.

Microsoft niezależnie zaobserwował utrwalanie dostępu przez tylną furtkę po udanym uwierzytelnieniu service principal, a potem rozpoznanie przez Microsoft Graph API i próby dodania kolejnych poświadczeń.

Wniosek z tej rozbieżności jest prosty: czysta próbka to nie to samo co czyste konto. Zachowanie napastnika różniło się między tenantami. Dziewięć tenantów bez śladów nie oznacza, że Twój tenant jest czysty.

Czego wciąż nie wiadomo

• W jaki sposób napastnik zdobył poświadczenia dostawcy. ConnectWise informuje, że dokładny mechanizm ujawnienia poświadczeń jest analizowany i nie jest jasne, czy przyczyniła się do tego podatność w produkcie.

• Pełna liczba ofiar i to, czy z poszczególnych tenantów faktycznie wyprowadzono dane.

• Kto za tym stoi i jaki miał motyw.

ConnectWise podaje, że istniejące archiwa kopii zapasowych pozostają zaszyfrowane i odizolowane, bez przesłanek świadczących o ich naruszeniu, oraz podkreśla, że zawieszenie usług nie powinno być odczytywane jako dowód naruszenia konkretnego środowiska partnera.

Jak działa ten atak

Service principal w uproszczeniu

Gdy organizacja podłącza do Microsoft 365 narzędzie firmy trzeciej, narzędzie otrzymuje w tym tenancie własną tożsamość, zwaną service principal (jednostka usługi). To konto nieosobowe, które przechowuje uprawnienia zatwierdzone przez klienta przy konfiguracji i może odczytywać oraz zapisywać dane bez logowania się przez kogokolwiek.

Takie rozwiązanie jest całkowicie normalne i konieczne. Narzędzie do kopii zapasowych musi działać o trzeciej w nocy, gdy nikogo nie ma przy klawiaturze.

Dlaczego jeden skradziony sekret otworzył setki tenantów

Kluczowy szczegół brzmi: poświadczenie było współdzielone. Ten sam sekret działał w każdej organizacji, która udzieliła aplikacji dostępu do swojego Microsoft 365. Ktokolwiek go posiadał, mógł zalogować się jako usługa backupu do dowolnego z tych tenantów i odziedziczyć dokładnie taki dostęp, jaki każdy klient wcześniej zatwierdził.

To definicyjna cecha ataków na łańcuch dostaw wymierzonych w integracje SaaS. Napastnik w ogóle nie musi kompromitować Ciebie. Kompromituje coś, czemu raz zaufałeś, lata temu, w okienku zgody.

Dlaczego Twoje zabezpieczenia nie zadziałały

• MFA: nie ma zastosowania. Uwierzytelnianie wyłącznie aplikacyjne nie angażuje użytkownika, więc nie ma o co poprosić.

• Polityka haseł: bez znaczenia. Żadne hasło nie zostało użyte.

• Dostęp warunkowy: w większości tenantów polityki obejmują użytkowników, a nie tożsamości obciążeń. Ograniczenie, skąd aplikacja może się logować, wymaga dostępu warunkowego dla tożsamości obciążeń, a to dodatkowa licencja.

• Wykrywanie ryzykownych logowań i „niemożliwych podróży": nastrojone na ludzi. Microsoft Entra ID Protection potrafi oznaczać ryzykowne service principals, ale wiele organizacji nigdy tego nie włączyło ani nie przeglądało.

Dlaczego samo wyłączenie nie wystarcza

To fragment, który większość doniesień traktuje po macoszemu, a jest najważniejszy operacyjnie:

1. Poświadczenia już umieszczone w Twoim tenancie przetrwają. Jeśli napastnik dodał sekret lub certyfikat do rejestracji aplikacji w Twoim środowisku, to poświadczenie jest teraz Twoje, a wyłączenie aplikacji ConnectWise nic z nim nie robi.

2. Wydane wcześniej tokeny pozostają ważne. Todyl ostrzega, że wyłączenie aplikacji zatrzymuje wydawanie nowych tokenów, ale wcześniejsze działają do czasu wygaśnięcia.

3. Unieważnienie sesji użytkowników nie kończy dostępu aplikacyjnego. Standardowy odruch, czyli reset haseł i wylogowanie sesji, w ogóle tego nie dotyka.

ConnectWise sam to przyznał: nieautoryzowane poświadczenia, uprawnienia lub inne formy dostępu ustanowione przez odrębne tożsamości wymagają dodatkowego przeglądu i usunięcia.

Dlaczego to ma znaczenie

MSP zwielokrotniają wszystko. ConnectWise sprzedaje głównie dostawcom usług zarządzanych, którzy obsługują wiele tenantów klienckich. Jedno skompromitowane poświadczenie dostawcy rozchodzi się przez MSP do każdego obsługiwanego klienta. Ponad 300 udanych logowań to organizacje, z których wiele nie ma bezpośredniej relacji z ConnectWise i może nawet nie wiedzieć, że taki produkt istnieje.

Uśpione integracje to żywe ryzyko. Najbardziej mrożący krew szczegół to administrator, który dostał alert PIM o service principalu SkyKick podnoszącym sobie uprawnienia, w tenancie, gdzie aplikacji nie używano od lat. Zgoda wciąż obowiązywała. Uprawnienia wciąż były nadane. Nikt do tego nie wrócił. Większość organizacji ma listę aplikacji przedsiębiorstwa, której nikt nie przeglądał od momentu instalacji.

Tożsamości nieosobowe to martwe pole. Firmy przez dekadę utwardzały logowanie ludzi: MFA, dostęp warunkowy, uwierzytelnianie bezhasłowe. Service principals w dużej mierze umknęły tej uwadze, choć często mają szersze uprawnienia niż którykolwiek pracownik.

Rozrost uprawnień przy instalacji staje się zasięgiem rażenia później. Nikt nie czyta ekranu zgody. Uprawnienie Directory.ReadWrite.All nadane w 2021 roku, żeby backup w ogóle zadziałał, to dokładnie to, co napastnik odziedziczył w 2026.

Łańcuch dostaw jest dziś preferowanym sposobem dostarczenia ataku. Bez phishingu, bez złośliwego oprogramowania, bez podatności po Twojej stronie.

Kogo to dotyczy

• Dostawców usług zarządzanych (MSP) korzystających z ConnectWise Cloud Backup, Cloud Management lub SaaS Security, a za ich pośrednictwem także ich klientów.

• Każdego tenanta Microsoft 365, który kiedykolwiek wyraził zgodę na jedną z siedmiu wskazanych aplikacji, łącznie z tenantami, gdzie integracja jest uśpiona. W starszych tenantach aplikacje mogą figurować jako „SkyKick Cloud Manager".

• Organizacji polegających na ConnectWise w zakresie kopii zapasowych, które od 17 października nie mają ani zaplanowanych kopii, ani możliwości odtwarzania. Jeśli właśnie teraz dotknie Cię inny incydent, Twoja ścieżka odzyskiwania jest niedostępna.

• Małych i średnich firm, typowych odbiorców backupu dostarczanego przez MSP, które o sprawie dowiedzą się raczej od swojego dostawcy niż bezpośrednio.

Co powinny zrobić organizacje

Sprawdź, czy jesteś narażony

1. Przejrzyj aplikacje przedsiębiorstwa w Microsoft Entra ID pod kątem tych siedmiu identyfikatorów:

2. Przefiltruj logi logowań service principals według tych identyfikatorów i poszukaj nietypowych adresów źródłowych, w szczególności 144.172.64[.]128, oraz user agentów curl/7.88.1, python-urllib/3.12, python-requests/2.31 i python-requests/2.34.2.

3. Sprawdź każdy obsługiwany tenant klienta, nie tylko własny, łącznie ze środowiskami z uśpionymi połączeniami SkyKick.

Przeprowadź prawidłową remediację

4. Zaudytuj poświadczenia i certyfikaty wszystkich aplikacji pod kątem nieautoryzowanych wpisów dodanych od 13 października i usuń wszystko, czego sam nie dodałeś. To jest krok, który faktycznie usuwa napastnika.

5. Przejrzyj przypisania ról katalogowych, zwłaszcza Exchange Administrator i Global Administrator nadane service principals. Aplikacja do kopii zapasowych nie potrzebuje roli Global Administrator.

6. Sprawdź zgody OAuth i ostatnią aktywność Microsoft Graph pod kątem wzorców rozpoznania.

7. Zbadaj każdą inną tożsamość zmienioną lub użytą w podejrzanym oknie czasowym i potraktuj skompromitowany service principal jako incydent obejmujący cały tenant, a nie problem jednej aplikacji.

8. Pamiętaj, że unieważnienie sesji użytkowników nie zatrzymuje dostępu aplikacji. Wydane wcześniej tokeny działają do wygaśnięcia.

Zapytaj dostawcę

9. Jeśli Twoim Microsoft 365 zarządza MSP, zapytaj go pisemnie, czy korzysta z ConnectWise Cloud Backup albo którejkolwiek z siedmiu wyłączonych tożsamości, co ustalił i co z tym zrobił. Poproś o potwierdzenie, a nie o zapewnienia.

Napraw problem strukturalny

10. Zinwentaryzuj każdą aplikację firmy trzeciej z dostępem do Twojego tenanta i zapisz, jakie ma uprawnienia oraz kiedy była ostatnio używana. Odbierz zgody wszystkim uśpionym. To zapomniana integracja Cię zaboli.

11. Stosuj zasadę minimalnych uprawnień już na etapie wyrażania zgody. Kwestionuj każde żądanie uprawnień typu Directory.ReadWrite.All i wybieraj wąsko określone zakresy, nawet jeśli jest to mniej wygodne.

12. Włącz dostęp warunkowy dla tożsamości obciążeń tam, gdzie pozwala na to licencja, ograniczając lokalizacje, z których aplikacja może się logować, oraz uruchom Entra ID Protection, by oznaczał ryzykowne service principals.

13. Monitoruj logowania service principals i przypisania ról jako stały mechanizm kontrolny. Alert PIM w tym incydencie zadziałał: ktoś został poinformowany, że aplikacja podniosła sobie uprawnienia. Taki alert powinien istnieć wszędzie.

14. Miej plan awaryjny na wypadek awarii dostawcy kopii zapasowych. Kilkaset organizacji od kilku dni nie ma działającego backupu.

Podsumowanie i kluczowa lekcja

Najbardziej niewygodne w tym incydencie jest to, jak niewiele ofiary mogły zrobić w momencie ataku. Nie było maila phishingowego do wychwycenia, złośliwego załącznika do zablokowania ani podatności do załatania. Aplikacja, którą organizacje świadomie zatwierdziły, zalogowała się i zrobiła dokładnie to, na co jej pozwolono, tyle że dla kogoś innego.

Lekcja: realną powierzchnią ataku Twojego tenanta Microsoft 365 jest lista aplikacji, na które wyraziłeś zgodę, a prawie nikt tej listy nie utrzymuje. Każda integracja firmy trzeciej to stały, bezhasłowy i zwolniony z MFA dostęp do Twoich danych, w rękach firmy, której bezpieczeństwa nie możesz zaudytować. Jedna z nich została skompromitowana. Pozostałe wciąż tam są.

Druga lekcja dotyczy odruchów w reagowaniu na incydenty. W przypadku skompromitowanych poświadczeń instynkt każe zresetować hasła i unieważnić sesje. Wobec skompromitowanego service principal oba te działania są teatrem. Liczy się audyt sekretów i certyfikatów aplikacji pod kątem wpisów, których nie dodałeś. Jeśli napastnik umieścił taki wpis w Twoim tenancie, wyłączenie usługi przez dostawcę w niczym mu nie przeszkodziło.

Dwa pytania na ten tydzień: ile aplikacji ma obecnie prawo zapisu do Twojej poczty i plików oraz kiedy ktokolwiek ostatni raz zajrzał na tę listę?