Wprowadzenie do problemu / definicja
Incydent dotyczący ConnectWise pokazuje, jak poważnym zagrożeniem dla środowisk chmurowych stała się kompromitacja tożsamości aplikacyjnych. W tym modelu atakujący nie muszą przejmować kont użytkowników ani omijać mechanizmów MFA. Wystarczy uzyskanie dostępu do poświadczeń aplikacji zintegrowanej z Microsoft 365, aby działać w granicach przyznanych jej uprawnień.
To szczególnie niebezpieczne w usługach SaaS i modelach partnerskich, gdzie jedna aplikacja może obsługiwać wielu klientów jednocześnie. Naruszenie zaufanej integracji może więc prowadzić do incydentu o charakterze wielotenantowym.
W skrócie
ConnectWise czasowo wyłączył wybrane usługi chmurowe i zawiesił działanie Cloud Backup po wykryciu incydentu bezpieczeństwa związanego z przejęciem tożsamości aplikacyjnych. Firma unieważniła certyfikaty oraz dezaktywowała siedem identyfikatorów aplikacyjnych powiązanych z usługami Cloud Backup i Cloud Management.
Z dostępnych informacji wynika, że atakujący mogli uwierzytelniać się jako zaufana aplikacja w tenantach Microsoft 365 klientów. Taki scenariusz umożliwia pobieranie tokenów dostępu i wykonywanie operacji zgodnych z wcześniej nadanymi uprawnieniami, a także potencjalne próby utrwalania dostępu poprzez dodawanie nowych sekretów lub rozszerzanie przywilejów.
Kontekst / historia
Incydent został wykryty w połowie października 2026 roku w ramach działań monitoringu bezpieczeństwa. W odpowiedzi uruchomiono procedury reagowania, zaangażowano zespoły wewnętrzne i zewnętrzne oraz odłączono wskazane tożsamości aplikacyjne odpowiedzialne za integracje z usługami Microsoft 365.
W centrum problemu znalazły się aplikacje posiadające szerokie uprawnienia administracyjne oraz dostęp do funkcji zarządzania chmurą i tworzenia kopii zapasowych. Takie integracje są powszechnie wykorzystywane przez dostawców MSP, dlatego ich kompromitacja może przełożyć się na ekspozycję wielu organizacji jednocześnie.
Dodatkowy kontekst zapewniły obserwacje badaczy bezpieczeństwa, którzy wskazywali na fale złośliwych logowań i prób dostępu do tenantów Microsoft Entra. Nie we wszystkich przypadkach prowadziło to do pełnego przejęcia środowiska, jednak sam mechanizm wykorzystania poświadczeń aplikacyjnych potwierdził wysokie ryzyko dla klientów korzystających z podobnych integracji.
Analiza techniczna
Technicznie incydent nie przypomina klasycznego phishingu ani przejęcia hasła użytkownika. Kluczowym elementem były poświadczenia aplikacyjne, takie jak sekrety klienta, certyfikaty lub inne materiały wykorzystywane przez aplikację do komunikacji z Entra ID i Microsoft 365.
Jeżeli napastnik przejmie taki element uwierzytelniający, może występować jako legalna aplikacja i pobierać tokeny dostępu zgodne z uprawnieniami przypisanymi do service principal. W praktyce może to oznaczać dostęp do danych w Exchange Online, SharePoint, OneDrive, Teams czy Microsoft Graph, a także możliwość wykonywania działań administracyjnych.
Największe ryzyko pojawia się wtedy, gdy przejęta aplikacja działa w modelu partner-managed services i ma dostęp do wielu tenantów klientów. W takim przypadku jedno naruszenie może mieć skutki łańcuchowe i obejmować wiele organizacji bez konieczności kompromitowania ich kont użytkowników osobno.
Istotne jest również to, że samo wyłączenie aplikacji lub unieważnienie certyfikatu nie musi automatycznie usunąć wszystkich skutków ataku. Jeśli napastnik zdążył wcześniej wprowadzić zmiany utrwalające dostęp, incydent może trwać także po wdrożeniu pierwszych działań naprawczych.
- dodanie nowych sekretów do istniejących rejestracji aplikacji,
- utworzenie nowych aplikacji i nadanie im zgód administracyjnych,
- modyfikacja ról katalogowych i przywilejów,
- przypisanie aplikacji do ról uprzywilejowanych,
- zmiana relacji zaufania lub elementów konfiguracji federacyjnej.
W analizowanym przypadku pojawił się także problem operacyjny związany z zatrzymaniem zaplanowanych kopii zapasowych oraz czasową niedostępnością funkcji odtwarzania. Nawet jeśli istniejące archiwa pozostały zaszyfrowane i odizolowane, sama utrata części zdolności backupowych w czasie incydentu stanowi istotne ryzyko dla ciągłości działania.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją kompromitacji tożsamości aplikacyjnej jest możliwość obejścia klasycznych zabezpieczeń kont użytkowników. Organizacja może poprawnie stosować MFA, polityki dostępu warunkowego i monitoring logowań pracowników, a mimo to pozostawać narażona, jeśli zaufana aplikacja została przejęta.
Skutki takiego incydentu mogą obejmować zarówno nieautoryzowany dostęp do danych, jak i długotrwałe utrwalenie obecności napastnika w środowisku. Problem jest trudniejszy do wykrycia, ponieważ aktywność często wygląda jak legalne uwierzytelnienie aplikacyjne.
- dostęp do skrzynek pocztowych i reguł przekazywania wiadomości,
- odczyt lub modyfikację danych w SharePoint i OneDrive,
- dostęp do zasobów i komunikacji w Microsoft Teams,
- rozpoznanie struktury katalogu i ról w Entra ID,
- eskalację uprawnień do poziomu administracyjnego,
- ustanowienie trwałości przez nowe sekrety i aplikacje,
- utrudnienie wykrycia ze względu na pozornie legalny charakter działań.
Dla dostawców usług zarządzanych oznacza to ryzyko łańcuchowe. Naruszenie jednego partnera technologicznego może uruchomić konieczność weryfikacji bezpieczeństwa po stronie wielu klientów, także tych działających w sektorach regulowanych lub krytycznych.
Rekomendacje
Organizacje korzystające z integracji ConnectWise oraz podobnych narzędzi powinny potraktować ten incydent jako sygnał do natychmiastowego przeglądu bezpieczeństwa tożsamości aplikacyjnych. Kluczowe jest nie tylko wyłączenie potencjalnie zagrożonych połączeń, ale również pełna analiza zmian wykonanych w tenantach.
- zweryfikować wszystkie aplikacje partnerskie i usługowe z dostępem do Microsoft 365,
- przeanalizować logi logowania i audytu od 13 października 2026 roku,
- zabezpieczyć oraz zarchiwizować logi przed rozpoczęciem działań naprawczych,
- przeprowadzić audyt rejestracji aplikacji, service principal, zgód administracyjnych, właścicieli oraz nowych sekretów i certyfikatów,
- sprawdzić role uprzywilejowane, w tym Application Administrator, Cloud Application Administrator i Global Administrator,
- zweryfikować zmiany w Exchange Online, takie jak forwarding, inbox rules, transport rules i delegacje skrzynek,
- przeszukać tenant pod kątem nowych aplikacji, połączeń OAuth i nietypowych zmian polityk,
- przeprowadzić rotację sekretów, certyfikatów i innych materiałów uwierzytelniających,
- ograniczyć możliwość tworzenia długowiecznych sekretów klienta,
- wdrożyć polityki bezpieczeństwa dla tożsamości workload i monitorowanie ryzykownych service principal.
Z perspektywy strategicznej warto wdrażać zasadę najmniejszych uprawnień i regularnie przeglądać zgody administracyjne nadane aplikacjom. Integracje backupowe i zarządcze często otrzymują zbyt szeroki zakres dostępu, który z czasem przestaje być kontrolowany z należytą starannością.
Podsumowanie
Przypadek ConnectWise potwierdza, że tożsamości aplikacyjne stały się jednym z najważniejszych celów współczesnych ataków na środowiska chmurowe. Przejęcie zaufanej aplikacji może dać napastnikowi szeroki dostęp do wielu tenantów bez potrzeby łamania kont użytkowników.
Nawet szybkie wyłączenie usług i unieważnienie poświadczeń nie gwarantuje pełnego usunięcia skutków incydentu, jeśli wcześniej doszło do utrwalenia dostępu. Dla zespołów bezpieczeństwa oznacza to konieczność prowadzenia pełnego dochodzenia obejmującego logi, role, zgody, sekrety oraz wszystkie zmiany wykonane w środowisku Microsoft 365.