AnswersPublished23 sources
Atak na ConnectWise Cloud Backup: co powinni sprawdzić administratorzy Microsoft 365
Huntress odnotował nieautoryzowane logowania do 173 środowisk Microsoft 365 z użyciem przejętych danych aplikacji ConnectWise Cloud Backup. Logowania odbywały się z wykorzystaniem tożsamości aplikacji, a nie kont użytkowników, dlatego uwierzytelnianie wieloskładnikowe użytkowników nie obejmowało tego procesu.
Opublikowane przezEdytowane za pomocą GPT-6 LunaObrazy wygenerowane za pomocą GPT Image 2
Research answer
Key takeaways
- Huntress odnotował nieautoryzowane logowania do 173 środowisk Microsoft 365 z użyciem przejętych danych aplikacji ConnectWise Cloud Backup.
- Logowania odbywały się z wykorzystaniem tożsamości aplikacji, a nie kont użytkowników, dlatego uwierzytelnianie wieloskładnikowe użytkowników nie obejmowało tego procesu.
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: What is known about the Microsoft 365 supply-chain attack that prompted ConnectWise to suspend customer access to Cloud Backup, formerly Sky. Article summary: The reported attack used a compromised ConnectWise Cloud Backup application credential to enter customers’ Microsoft 365 tenants through an already-trusted integration, rather than by compromising individual user account. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fa
Przejęte dane dostępowe aplikacji ConnectWise Cloud Backup, wcześniej znanej jako SkyKick, posłużyły do uzyskania tokenów Microsoft Graph w wielu środowiskach klientów Microsoft 365. Huntress potwierdził nieautoryzowane logowania w 173 tenantach partnerów i klientów. Nie oznacza to jednak, że kradzież danych potwierdzono we wszystkich 173. Pełna skala incydentu i źródło przejęcia pierwotnych danych dostępowych pozostają nieznane. 1
6
9
Jak doszło do ataku
Microsoft określił incydent jako atak na łańcuch dostaw, w którym naruszono zaufaną aplikację OAuth. Klienci wcześniej zgodzili się na działanie wielodostępnej aplikacji Cloud Backup w swoich środowiskach. Według śledczych napastnik wykorzystał przyznane jej uprawnienia, by uzyskać tokeny dostępu w wielu tenantach. Obejmowały one szeroki dostęp do katalogu, między innymi uprawnienie Directory.ReadWrite.All. 9
15
Liczba potwierdzonych nieautoryzowanych logowań zgłoszonych przez Huntress wzrosła ze 162 o godz. 19:00 UTC 16 października do 173 w późniejszej aktualizacji. To liczba tenantów, w których wykryto logowania — nie ostateczna liczba poszkodowanych organizacji ani dowód, że w każdym z tych środowisk doszło do wykradzenia informacji. 1
6
9
Oś czasu i adres IP
Huntress zaobserwował, że aplikacja uzyskiwała tokeny Microsoft Graph z adresu 144.172.64[.]128 15 października, między 06:13 a 08:34 UTC. Szybkie przechodzenie między tenantami wskazywało na zautomatyzowane działanie. Z tego samego adresu 13 i 14 października podejmowano również nieudane próby password sprayingu wobec czterech tenantów kancelarii prawnych. Nie dowodzi to jednak, że właśnie tak przejęto dane aplikacji Cloud Backup. 1
5
20
Dlaczego MFA użytkowników nie zatrzymało logowań
Dostęp uzyskiwano jako aplikacja — jej tożsamość w Microsoft Entra nazywana jest również jednostką usługi — a nie jako konkretny użytkownik. Dlatego uwierzytelnianie wieloskładnikowe użytkownika nie było częścią tego procesu logowania. To inna sytuacja niż obejście MFA na przejętym koncie użytkownika. 7
11
Uprawnienia aplikacji mogły potencjalnie umożliwić dostęp do takich zasobów Microsoft 365 jak poczta, OneDrive, SharePoint, Teams i dane katalogowe. Sam zakres uprawnień nie dowodzi jednak, że wszystkie te dane zostały odczytane. Todyl wykrył nieautoryzowane logowania w dziewięciu analizowanych tenantach, ale ten ograniczony zakres obserwacji nie przesądza o tym, co wydarzyło się w pozostałych. 6
19
29
Ślady utrzymania dostępu
Huntress zgłosił przypadki samodzielnego przypisywania sobie ról w katalogu w niemal 50 tenantach. W jednym z zaobserwowanych przypadków aplikacja do zarządzania Teams nadała sobie rolę Administratora globalnego, a następnie dodała poświadczenia do innych aplikacji — w tym narzędzia zarządzającego używanego przez dostawcę usług IT oraz aplikacji Huntress. Takie dodatkowe poświadczenia mogły tworzyć ścieżki dostępu niezależne od pierwotnej integracji Cloud Backup. 1
9
Dlatego samo wyłączenie integracji dostawcy może nie wystarczyć, jeśli podczas włamania zmieniono też inne aplikacje. Administratorzy powinni sprawdzić, czy nie dodano nieznanych sekretów aplikacji ani nieoczekiwanych przypisań ról. 1
13
Co wiadomo o kopiach zapasowych
ConnectWise przekazał, że nie ma wskaźników świadczących o dostępie do danych w kopiach zapasowych partnerów oraz że istniejące archiwa będą dostępne po przywróceniu usługi. To zapewnienie dotyczy archiwów kopii zapasowych — nie potwierdza, że dane klientów w Microsoft 365 pozostały nietknięte. W opisywanej aktualizacji nie podano terminu przywrócenia usługi. 4
19
W aktualizacji z 17 października ConnectWise poinformował o unieważnieniu certyfikatów używanych w objętych incydentem połączeniach aplikacyjnych oraz wspólnych danych dostępowych Cloud Backup. Przerwa w działaniu usługi i unieważnienie poświadczeń to działania ograniczające skutki incydentu, a nie jego ostateczny bilans. 3
Dostępne informacje nie określają całkowitej liczby poszkodowanych organizacji, skali ewentualnej kradzieży danych ani źródła przejęcia pierwotnych danych aplikacji. Firmy zajmujące się cyberbezpieczeństwem analizowały różne zestawy tenantów, dlatego ustaleń jednej z nich nie należy traktować jako pełnego obrazu sytuacji we wszystkich środowiskach. 1
9
19
Co powinni zrobić administratorzy Microsoft 365
- Wyłączyć objęte incydentem aplikacje, ale zachować materiał do analizy. Huntress zalecił organizacjom, których dotyczy incydent, wyłączenie aplikacji. Przed jej usunięciem warto sprawdzić logowania, przypisania ról i zmiany poświadczeń; przed ponownym włączeniem należy kierować się aktualnymi zaleceniami dostawcy i zespołu reagowania na incydenty.
9
13
- Sprawdzić także inne aplikacje. Poszukajcie nieoczekiwanych sekretów lub poświadczeń dodanych od 13 października oraz nieznanych przypisań ról. Rotacja danych dostępowych dostawcy ani zawieszenie usługi nie usuwają automatycznie poświadczeń, które napastnik mógł dodać do innych aplikacji.
1
- Analizować logowania aplikacji osobno od logowań użytkowników. Ponieważ atak wykorzystywał tożsamość aplikacji, sam przegląd zdarzeń MFA użytkowników nie wystarczy do oceny incydentu.
7
- Nie traktować braku wpisów w audycie jako dowodu braku dostępu. Niektóre operacje odczytu katalogu przez Microsoft Graph mogą nie pozostawić śladu w dzienniku audytu katalogu. Brak takich zdarzeń nie przesądza więc, że nie doszło do rozpoznania lub dostępu.
Najważniejszy wniosek: zaufana integracja może mieć szeroki dostęp do środowisk wielu klientów. W tym przypadku potwierdzone logowania aplikacji i zgłoszone oznaki utrzymywania dostępu uzasadniają dochodzenie nawet tam, gdzie kradzieży danych nie potwierdzono. 9
15
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "Atak na ConnectWise Cloud Backup: co powinni sprawdzić administratorzy Microsoft 365"?
Huntress odnotował nieautoryzowane logowania do 173 środowisk Microsoft 365 z użyciem przejętych danych aplikacji ConnectWise Cloud Backup.
What are the key points to validate first?
Huntress odnotował nieautoryzowane logowania do 173 środowisk Microsoft 365 z użyciem przejętych danych aplikacji ConnectWise Cloud Backup. Logowania odbywały się z wykorzystaniem tożsamości aplikacji, a nie kont użytkowników, dlatego uwierzytelnianie wieloskładnikowe użytkowników nie obejmowało tego procesu.