15 października 2026 ktoś użył poświadczenia aplikacji ConnectWise Cloud Backup, dawniej SkyKick, do zalogowania się do tenantów Microsoft 365 jej klientów. Nie było tu hasła użytkownika ani MFA do obejścia: aplikacja miała zgodę na czytanie poczty, plików i katalogu w każdym tenancie, w którym ją zainstalowano. Napastnik odziedziczył te uprawnienia. W części tenantów inna aplikacja ConnectWise nadała sobie Global Administrator i podrzuciła sekrety innym aplikacjom. 21 października Microsoft przypisał atak grupie Storm-0940, która używała agentowego frameworka ARTEX. CVE nie ma i nie będzie. Vendor odciął swoje połączenia i od 17.10 trzyma backup wyłączony. Podrzucone sekrety, role i luka w kopiach zostają jednak w Twoim tenancie i to Ty musisz je usunąć.
Przebieg
| Czas (UTC) | Zdarzenie | Źródło |
|---|---|---|
| 10–14.10.2026 | Password spray z 144.172.64[.]99 na konta Microsoft 365 i Exchange Online (Microsoft: 327 kont w 8 organizacjach, bez udanego logowania) | Microsoft, Huntress |
| 14.10.2026 | ConnectWise wykrywa problem i uruchamia procedury IR (FAQ advisory) | ConnectWise |
| 15.10, ok. 03:44–03:49 | W jednym tenancie aplikacja Cloud Management - MS Teams nadaje sobie Global Administrator i dodaje sekrety do dwóch innych aplikacji (w tym aplikacji Huntress). Ruch z prywatnej przestrzeni IPv6 Azure, nie z 144.172.64[.]128. Później Huntress znalazł drugi tenant z tym samym schematem | Huntress |
| 15.10, 06:13–08:34 | Tożsamość aplikacji Cloud Backup loguje się z 144.172.64[.]128 do tenantów klientów i dostaje tokeny Microsoft Graph, w kolejności GUID. Ostatnie udane logowanie widziane przez Huntress: 08:44 | Huntress |
| 15.10, 09:25–14:20 | Druga fala na 16 tenantów (polityka, bezpieczeństwo narodowe, handel, surowce krytyczne), w większości bez produktów ConnectWise, nieudana | Huntress |
| 16.10, 17:47 | Pierwsze advisory ConnectWise: IOC 144.172.64.128, user agenty Python | ConnectWise |
| 17.10, 05:00–07:00 | Początek mitygacji (05:00), zawieszenie Cloud Backup (komunikat 05:01), wyłączenie siedmiu tożsamości aplikacyjnych (07:00), unieważnienie certyfikatów | ConnectWise |
| 18.10, 01:00 | Technical workflow dla MSP i lista siedmiu Application ID. Zawieszone też SaaS Security i Cloud Management | ConnectWise |
| 19.10 | Pełny reset kont i poświadczeń w środowisku Cloud Backup (komunikat z 20.10 19:00) | ConnectWise |
| 21.10, 12:45 | Początek etapowego przywracania usług, „several days” | ConnectWise |
| 21.10 | Microsoft przypisuje atak grupie Storm-0940 (China-state aligned), która używała frameworka agentowego ARTEX | Microsoft, ConnectWise (21.10 22:00) |
| 22.10, 13:00 | Ostatni komunikat w chwili publikacji: przywracanie etapami trwa, połączenia mają pozostać wyłączone do formalnych instrukcji, następny komunikat do 23.10 01:00 | ConnectWise |
Dwa szczegóły z osi czasu są ważne dla huntingu. Po pierwsze, nadanie Global Administrator i podrzucenie sekretów nastąpiło ok. 03:45 UTC, czyli dwie i pół godziny przed pierwszymi logowaniami z 144.172.64[.]128, i to z prywatnej przestrzeni IPv6 Azure. Z tej samej przestrzeni łączy się też legalny ruch vendora. Huntress pisze, że nie powiązał obu faz z tym samym operatorem. Kto szuka tylko po IP, tę fazę przeoczy. Po drugie, Huntress zaleca przegląd logowań aplikacji od ok. 01:00 UTC 15.10 do 02:00 UTC 16.10, a ConnectWise i Microsoft każą zaczynać od 13.10, a w miarę możliwości od 1.10.
Dlaczego skaner nic nie pokaże
Nie ma podatnej wersji, pakietu ani CPE. Jednostką ryzyka jest service principal aplikacji zewnętrznej ze zgodą w Twoim tenancie i uprawnienia, które ta zgoda daje. Backup M365 z natury ma szeroki odczyt poczty, OneDrive, SharePoint, Teams i katalogu, a zwykle też zapis, żeby móc odtwarzać. Dostęp jest app-only, więc nie obejmują go polityki MFA i Conditional Access dla użytkowników. ConnectWise przypomina, że Conditional Access dla workload identities obejmuje tylko jednodzierżawowe service principale zarejestrowane w tenancie, a nie aplikacje wielodostępne dostawców.
Dla VM oznacza to, że rejestr musi znać takie byty. Jeśli Twój inwentarz kończy się na hostach, obrazach i pakietach, to tego incydentu w nim nie ma. Ten sam problem opisywaliśmy przy WPSplinter i AOMEI/UNC7017: zagrożenie bez CVE trzeba wpisać do rejestru ręcznie, inaczej nie ma właściciela.
Odcięcie u vendora to nie remediacja w tenancie
ConnectWise wyłączył siedem tożsamości aplikacyjnych, unieważnił certyfikaty i zresetował poświadczenia w swoim środowisku. Sam też pisze, czego to nie załatwia:
- „it does not reverse changes previously made inside a tenant”: role, właściciele, zgody i zmiany polityk zostają.
- „Previously issued access tokens may remain usable until they expire or are otherwise invalidated.”
- Sekrety podrzucone innym aplikacjom w tenancie działają niezależnie od aplikacji ConnectWise. Huntress widział je w aplikacji zarządzającej MSP i w aplikacji narzędzia bezpieczeństwa, z ważnością do 2028. Aplikacja MSP zwykle ma zgody w tenantach klientów, więc taki sekret może sięgać dalej niż jeden tenant.
- Odczyty katalogu przez Graph nie zostawiają śladu w audycie. Huntress ujmuje to jako „tokens issued, nothing visible taken”, co nie znaczy, że nic nie wzięto.
Wyłącz aplikację lokalnie („Enabled for users to sign-in? = No”), ale jej nie usuwaj. Usunięcie niszczy konfigurację i dowody, a przy przywracaniu i tak trzeba będzie ją ponownie autoryzować. Zapisz lokalny Object ID i czas. Pamiętaj o retencji: logi Entra w wersji Free trzymają 7 dni, P1/P2 30 dni. Logów z 15.10 w tenancie Free już nie ma, a późniejszy upgrade licencji ich nie odzyska. Zapisz w rejestrze, jakie okno faktycznie przejrzałeś.
Którą listę aplikacji i IOC przyjąć
Źródła różnią się w szczegółach, a te różnice przekładają się na zapytania SIEM.
| Aplikacja (wg ConnectWise) | Application (client) ID |
|---|---|
| ConnectWise Cloud Backup (dawniej SkyKick Backup) | 506e08f9-6e9a-4da4-942b-a099a03644ae |
| ConnectWise Cloud Management | 2399d300-6fca-4e6a-a686-399fefe75b83 |
| Cloud Management - MS Teams | 24205314-2b89-4e07-a2a4-579e898a5640 |
| Cloud Management - Exchange Online | b78f6a77-d4e5-46fb-87e5-d1648bd02519 |
| Cloud Management - MS Graph | 0de14c77-b9b0-4137-9360-34878a929827 |
| Cloud Management - Partner Center | 412dcf96-176d-4b3a-a1b0-4981ad66971e |
| Cloud Management - SharePoint Online | b2b55f5b-7758-4719-8d8f-88ae172e6bdb |
ConnectWise podaje siedem aplikacji. Huntress z wysoką pewnością wskazuje nadużycie sześciu (bez osobnej wzmianki o „Cloud Management”). Microsoft w tekście mówi o „four application IDs”, a w zapytaniach hunting ma trzy: Cloud Backup, MS Teams i MS Graph. Przyjmij listę siedmiu od vendora i dopasowuj po Application ID, nie po nazwie wyświetlanej. W starszych tenantach aplikacje mogą nazywać się „SkyKick Cloud Manager”. Przejrzyj też wszystkie inne aplikacje ConnectWise i SkyKick, także z nieużywanych od lat integracji.
| Wskaźnik | ConnectWise | Huntress (19.10) | Microsoft (21.10) | Wniosek dla huntingu |
|---|---|---|---|---|
| 144.172.64[.]128 | IOC od 16.10 | Jedyny adres z logowaniami aplikacji (poza zakresami Microsoft) w ponad 10 000 tenantów | Logowania i aktywność Graph w tenantach z aplikacjami ConnectWise | Główny wskaźnik dla Service principal sign-ins |
| 144.172.64[.]99 | IOC od 18.10 | Nieudany password spray na użytkowników, 10–14.10 | Ta sama infrastruktura, spray 10–14.10 | Szukaj w logowaniach użytkowników, nie aplikacji |
| 144.172.64[.]60 | IOC od 18.10 | Kilka nieudanych logowań użytkowników, 18.10 | Na liście IOC | Jak wyżej |
| 144.172.94[.]243 | brak | Szeroki, trwający spray na wiele organizacji | brak | Kontekst, nie dowód związku z incydentem |
| 187.15.88[.]186, 187.15.90[.]217, 187.15.89[.]186 | brak | brak | Adresy VPN z dostępem do Graph przez przejęte aplikacje, istotne dla 15–16.10 | Tylko w oknie 15–16.10, adresy przejściowe |
| Python-urllib/3.12, python-requests, curl/7.88.1, azure-toolkit/1.0 | Python-urllib i python-requests | Python przy zmianach aplikacji, curl przy sprayu. Aplikacje vendora używają kiota-dotnet | Lista user agentów | Pojedynczy UA niczego nie dowodzi. Liczy się kombinacja: aplikacja + operacja + UA |
ConnectWise podaje trzy adresy jako równorzędne IOC. Huntress i Microsoft przypisują im różne role: tylko .128 logował się jako aplikacja, a .99 i .60 to nieudane logowania użytkowników. Trafienie na .99 w logach użytkowników to sygnał sprayu, który warto sprawdzić pod kątem zablokowanych kont, ale nie dowód, że ktoś wszedł przez aplikację backupu. Trafienie na .128 w Service principal sign-ins dla jednej z siedmiu aplikacji to już finding incydentowy. I odwrotnie: brak tych adresów nic nie wyklucza, bo faza z Global Administratorem przyszła z przestrzeni Azure.
Ponowne włączenie to nowa decyzja o zgodzie
ConnectWise przywraca usługi etapami i zapowiada instrukcje ponownego podłączenia, w tym ewentualną reautoryzację. Dla VM i IAM to moment, w którym organizacja ponownie daje zewnętrznej aplikacji szeroki dostęp do całego M365. Potraktuj to jak nową zgodę, nie jak przywrócenie stanu sprzed incydentu. Sprawdź, jakich uprawnień aplikacja żąda i czy wszystkie są potrzebne. Zapytaj vendora o przyczynę wycieku poświadczenia, której na 22.10 nadal nie podał. Ustal też, kto i jak będzie monitorował logowania tej aplikacji. Do tego czasu kopie M365 nie powstają od 17.10. To osobny finding dostępności: zmierz czas od ostatniego udanego punktu odtworzenia i zdecyduj, czy potrzebujesz kopii zastępczej.
Co powinien zrobić VE
- Załóż finding bez CVE: „ConnectWise Cloud Backup / SkyKick: przejęte poświadczenie aplikacji wielodostępnej”, z właścicielem po stronie IAM/IR i listą tenantów (własny, a dla MSP każdy klienta, także z wygasłymi umowami SkyKick).
- Per tenant: obecność każdej z siedmiu aplikacji (po Application ID), lokalny Object ID, stan wyłączenia, data i osoba. Bez usuwania.
- Logi: eksport audytu Entra, czterech kategorii logowań (w tym
Service principal sign-ins) i Purview od 13.10 (lub 1.10). Zapisz faktyczne pokrycie retencji. - Trwałość dostępu: przejrzyj „Add member to role”, „Add service principal credentials”, „Update application – Certificates and secrets management”, nowych właścicieli, zgody i zmiany Conditional Access. Szukaj aplikacji ConnectWise jako inicjatora i jako celu. Sprawdź poświadczenia na wszystkich aplikacjach w tenancie, a przede wszystkim na narzędziach MSP i bezpieczeństwa. Napastnik dobierał je według tego, czy są zarejestrowane w tenancie, a nie według uprawnień.
- Exchange i zasoby: reguły skrzynek (także ukryte), przekierowania, uprawnienia Full Access i Send As, reguły transportowe, a tam, gdzie licencja pozwala,
MailItemsAccessed. - Klasyfikacja wyników osobno: próba, udane logowanie, zmiana konfiguracji, dostęp do danych. Udane logowanie aplikacji to nie dowód eksfiltracji, a brak wpisów nie dowodzi, że jej nie było.
- Kryteria zamknięcia (wszystkie): aplikacje zinwentaryzowane i wyłączone; okno logów przejrzane i udokumentowane; nieautoryzowane role, sekrety, zgody i właściciele usunięte po zabezpieczeniu dowodów; decyzja IR co do kompromitacji; luka w backupie zmierzona i pokryta; przy ponownym włączeniu przegląd uprawnień i potwierdzenie udanego backupu i odtworzenia. Komunikat vendora o braku nowej aktywności nie jest kryterium zamknięcia.
Powiązane na blogu
- Broadcom WPS „WPSplinter”: jak śledzić zagrożenie, którego nie widzi skaner, SBOM ani KEV
- AOMEI Backupper i AnyViewer: łańcuch dostaw bez CVE i bez poprawionej wersji
- Unblu Spark CVE-2026-9589: cross-tenant w SaaS jako sprawa TPRM
- Google Cloud Shell CVE-2026-85267: „fixed by provider”, ale okno ekspozycji zostaje
- ScreenConnect 26.6.5: inny produkt ConnectWise, inna lekcja o tym, gdzie kończy się remediacja
Źródła
- ConnectWise Trust Center — Cloud Backup (formerly known as SkyKick) Service Interruption (16.10–22.10.2026, technical workflow z 18.10, lista siedmiu aplikacji, FAQ) — connectwise.com
- Huntress — ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks (16.10.2026, aktualizacje 17.10 i 19.10) — huntress.com
- Microsoft Security Blog — AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise (21.10.2026, Storm-0940, IOC, hunting) — microsoft.com
- Microsoft Learn — Conditional Access for workload identities (zakres: jednodzierżawowe service principale) — learn.microsoft.com
- Microsoft Learn — Incident response playbook: compromised and malicious applications — learn.microsoft.com
- Microsoft Learn — Disable user sign-in for an enterprise application — learn.microsoft.com
Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 17.10.2026 (aktualizowanego do 20.10) i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 19:15 CEST). 22 października 2026 (ok. 22:40 CEST) ponownie przeczytałem advisory ConnectWise (komunikaty do 22.10 13:00 UTC, w tym etapowe przywracanie od 21.10 i komunikat o sprawcy z 21.10 22:00 UTC), blog Huntress (aktualizacje 17.10 i 19.10) i nowy wpis Microsoft z 21.10 o Storm-0940 i ARTEX. Względem szkicu poprawiłem godziny komunikatów ConnectWise z 17.10 (05:01 i 17:00 UTC), rolę adresów 144.172.64.99 i .60 (według Huntress i Microsoft nieudane logowania użytkowników, nie logowania aplikacji) i skalę (Huntress: ponad 300 udanych logowań, Microsoft: próby w ponad 2250 tenantach). Dodałem datę wykrycia (14.10), reset poświadczeń (19.10), przywracanie usług i atrybucję. Nie potwierdziłem: liczby 173 tenantów z relacji The Hacker News (strona niedostępna), łącznej liczby dotkniętych tenantów, tego, czy dane zostały wyniesione, jak wyciekło poświadczenie vendora, daty pełnego przywrócenia usług ani niezależnie atrybucji do Storm-0940. Oś czasu pochodzi z telemetrii Huntress i Microsoft, która nie obejmuje wszystkich tenantów. Model findingu bez CVE, interpretacja IOC i kryteria zamknięcia to oceny autora.