Studium przypadku: Jak nasz klient utracił kontrolę nad swoim środowiskiem chmurowym.

Projekt bez nazwy

Współczesny świat IT jest bardziej złożony niż kilka lat temu. Chmura stała się nieodłącznym elementem działalności większości firm, przynosząc ze sobą nowe wyzwania związane z bezpieczeństwem. Trwa nieustająca walka między ekspertami ds. bezpieczeństwa a cyberprzestępcami, którzy wykorzystują powstałą złożoność, luki czy zaniedbania administratorów do zdobycia informacji, pieniędzy lub realizacji innych swoich celów. 

 

Niedawno jeden z naszych klientów stał się celem zaawansowanego ataku. W jego wypadku był to tak zwany Crypto Jacking. Atak  polegający na wykorzystywaniu mocy obliczeniowej do wydobywania kryptowalut. Prowadzi to do strat finansowych dla organizacji, które ponoszą koszty związane z nadużyciem zasobów. 

 

W naszym przypadku była to, w kilkanaście godzin, kwota około 10.000 Euro. Znamy też przypadki, klientów, którzy stracili dziesiątki tysięcy Euro zanim zrozumieli, że coś jest nie tak.

 

 

Jak zauważyliśmy incydent? 

 

Nasz zespół wsparcia zauważył gwałtowny wzrost kosztów, korzystając z logów Azure oraz analizując ostrzeżenia z systemu. Limity kosztów jeszcze nie zostały osiągnięte, ale wzrost był bardzo dynamiczny. Po szybkiej reakcji, zidentyfikowaliśmy konta administracyjne oraz próby logowania z różnych miejsc. 

Po zidentyfikowaniu problemu podjęliśmy natychmiastowe działania: zablokowaliśmy konto wytypowanego admina oraz usunęliśmy uprawnienia Global Administratora. Mimo działającego mechanizmu MFA (uwierzytelnienie wieloskładnikowe) podejrzane konto globalnego admina nie było nim objęte. Wymusiliśmy ponowną rejestrację uwierzytelniania wieloskładnikowego. Następnie nasz zespół administracyjny zaczął logować się do podejrzanych zasobów w Azure, usunęliśmy wszystkie zasoby, które zostały utworzone w celu zatrzymania generowania dodatkowych kosztów. Nie było to proste, bo skrypt wykonywał się bardzo szybko i działał w kilku centrach danych Azure. Musieliśmy w pewnym momencie usunąć całą skompromitowaną maszynę, aby ten atak powstrzymać.

Konto użytkownika – blokada dostępu

 

Po zidentyfikowaniu problemu natychmiast zablokowaliśmy, także możliwość logowania się na konto i zresetowaliśmy wszystkie aktywne sesje, aby odciąć atakującego. 

Zauważyliśmy, że użytkownik zalogował się do portalu Azure z Europy i USA. Te cztery próby pozwoliły hakerowi uruchomić skrypt wdrażający, który tworzył zasoby w Azure. Atakujący mogli wykorzystać techniki phishingowe lub inne metody socjotechniczne, aby zdobyć dane uwierzytelniające. 

 

 

Próby logowania – identyfikacja adresów

 

Zidentyfikowaliśmy różne próby logowania, zarówno udane, jak i nieudane, do różnych usług, takich jak Azure Portal czy Microsoft Azure CLI. W szczególności zwróciliśmy uwagę na próby logowania z wybranych podejrzanych adresów IP. Nie stwierdziliśmy logowania na inne konta niż urlopującego się w tym czasie administratora. Być może ten administrator pozostawił gdzieś swoje dane do logowania, włącznie z ujawnionym hasłem.

 Mimo stwierdzenia, że organizacja ma wdrożone uwierzytelnienie wieloskładnikowe, udało się atakującym obejść to logowanie i wykorzystać zdobyte poświadczenia do prawidłowego logowania. Być może działał potem jakiś skrypt lub celem był tylko cryptojacking, ponieważ nasz zespół nie zauważył innych logowań oraz innych aktywności.

Kroki incydentu – co robił skrypt atakującego? 

 

 

Zidentyfikowane konto miało uprawnienia globalnego administratora. Stanowiło to bardzo duże ryzyko. Potwierdziliśmy, że użytkownik-administrator, z którego konta wykonywane były działania, jest ostatni dzień na urlopie. W momencie ataku był w podróży, warto tu podkreślić, że atak był przemyślany i prawdopodobnie osoba, która atakowała wiedziała, że użytkownik nie będzie w stanie podjąć działań. Będzie miał bardzo ograniczony dostęp do informacji o swoim działaniu, w tym np. wyskoczenie alertu logowania z innej lokalizacji, prośba o autoryzację w aplikacji itp. 

 

Po udanym logowaniu haker użył skryptu do tworzenia zasobów we wszystkich centrach danych Azure. Skrypt był zaprogramowany tak, aby działać dyskretnie i unikać wykrycia przez standardowe mechanizmy monitorowania. Tworzył cztery zasoby w każdej lokalizacji: Application Insights, Key Vault, Storage Account oraz Machine Learning workspace. Te zasoby generowały koszty rzędu 20000 Euro na 24h.

Wprowadzone zmiany przez ISCG.

 
Po konsultacji z CIO Grupy usunęliśmy wszystkie zbędne konta z grupy administracyjnej. Przeprowadziliśmy rekonfigurację usługi uwierzytelnienia MFA, oraz przeprowadziliśmy szkolenia dla pracowników na temat bezpiecznego korzystania z chmury i jak unikać potencjalnych zagrożeń. 

 

 

 

Dodatkowe kontrole przeprowadzone przez ISCG 

 

 

Przeprowadziliśmy szereg dodatkowych kontroli, aby upewnić się, że środowisko jest bezpieczne. Zidentyfikowaliśmy również ryzykowne konta użytkowników w organizacji, które wymagają dalszej analizy.

 

 Po wykryciu i upewnieniu się, że mamy zabezpieczony materiał dowodowy, usunęliśmy stworzone zasoby z subskrypcji. Wymusiliśmy na każdym globalnym administratorze i każdej roli uprzywilejowanej MFA. 

 

 

Aktualne role administratora

 

 

Przeprowadziliśmy przegląd wszystkich ról administratora w środowisku klienta, aby upewnić się, że tylko zaufane konta mają odpowiednie uprawnienia.

Działania podjęte przez klienta 

 

Klient podjął szereg działań, w tym zgłoszenie ataku na lokalnej policji, informowanie CFO i działu prawnego. 

 

Rekomendacje dotyczące bezpieczeństwa

 

Na podstawie naszej analizy przedstawiliśmy klientowi szereg rekomendacji dotyczących poprawy bezpieczeństwa ich środowiska chmurowego. W szczególności zaleciliśmy wdrożenie uwierzytelniania wieloskładnikowego dla wszystkich kont z uprawnieniami oraz przeprowadzenie szczegółowej oceny bezpieczeństwa. Według raportu z 2022 roku, ataki na środowiska chmurowe wzrosły o 300% w ciągu ostatnich dwóch lat, co podkreśla wagę regularnych przeglądów bezpieczeństwa i aktualizacji. 

Chociaż nie znaleźliśmy śladów operacji na innych kontach, ani operacji w lokalnym AD, scenariusze kompromitacji wielu kont i kompromitacji lokalnego AD są prawdopodobne. W ramach naszej współpracy z Microsoft wystąpiliśmy o anulowanie wygenerowanego rachunku. W tym wypadku udało się cofnąć 100% kosztów. Microsoft publikuje tutaj artykuł, który opisuje ścieżkę oraz warunki anulowania opisywanych kosztów: Nonpayment, fraud, and misuse – Partner Center | Microsoft Learn

Pomoc w poprawie bezpieczeństwa firmy 

 

Jeśli czujesz, że potrzebujesz dodatkowego wsparcia w zakresie bezpieczeństwa, skontaktuj się z naszym zespołem. Wykonujemy zarówno okresowy przegląd bezpieczeństwa, jak również środowiska naszych klientów obejmujemy pełnym wsparciem 24h zarówno od strony zarządzania, jak również bezpieczeństwa. Mamy do tego dedykowaną usługę, którą często rozszerzamy o Microsoft Sentinel, pozwalającym nam na szybsze generowanie odpowiedzi, jeśli Twoja infrastruktura jest atakowana.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *