Zaawansowana kampania ataków o nazwie SCARLETEEL kierowana jest na środowiska kontenerowe w celu kradzieży wrażliwych danych i tworzonego oprogramowania.
Z raportu Sysdig wiemy, iż atakujący wykorzystał podatność w konteneryzowanym workload, a następnie użył jej do eskalacji uprawnień na konto AWS w celu kradzieży danych i poświadczeń.
Zaawansowany atak w chmurze wiązał się również z wdrożeniem systemu do kopania kryptowalut, które było albo próbą generowania nielegalnych zysków, albo sztuczką mającą na celu odwrócenie uwagi obrońców i zbicie ich z tropu.
Początkowy wektor infekcji opierał się na wykorzystaniu podatnej na ataki usługi publicznej w samodzielnie zarządzanym klastrze Kubernetes, hostowanym na Amazon Web Services (AWS).
Po zdobyciu przyczółka uruchomiono koparkę kryptowalut XMRig i użyto skryptu bash w celu uzyskania poświadczeń, które można było wykorzystać do dalszego zagłębiania się w infrastrukturę chmury AWS i eksfiltracji wrażliwych danych.
Włamanie wyłączyło również dzienniki CloudTrail, aby zminimalizować ślady, uniemożliwiając firmie Sysdig dostęp do dodatkowych dowodów. W sumie umożliwiło to aktorowi dojście do ponad 1 TB danych, w tym skryptów klientów, narzędzi do rozwiązywania problemów i plików dziennika.
Atakujący próbowali również przełączyć się dzięki pliku stanu Terraform na inne połączone konta AWS, aby rozszerzyć swój zasięg w całej organizacji. Okazało się to jednak nieskuteczne z powodu braku uprawnień.
Schemat ataku
Poniższa infografika przedstawia główne etapy łańcucha KillChain opisywanego ataku.
Źródło: sysdig.comKrok 1: Atakujący uzyskał początkowy dostęp, wykorzystując usługę publiczną w samodzielnie zarządzanym klastrze Kubernetes, hostowanym w ramach konta w chmurze AWS.
Krok 2: Gdy haker zyskał dostęp, złośliwe oprogramowanie było w stanie wykonać dwie początkowe akcje podczas uruchomienia:
- wystartować koparkę kryptowalut w celu generowania zysku bądź odwrócenia uwagi,
- uzyskać dostęp do poświadczeń dzięki tymczasowych poświadczeń pracownika w Instance Metadata Service (IMDS) v1, aby wyliczać i zbierać informacje w jego imieniu przy użyciu uprawnień roli klastra. Ze względu na nadane uprawnienia, atakujący był w stanie:
- wylistować zasoby AWS,
- znaleźć poświadczenia innych użytkowników zarządzania tożsamością i dostępem (IAM), zarówno ustawionych jako zmienne środowiskowe Lambda, jak i przekazanych w postaci zwykłego tekstu do zasobników Amazon Simple Storage Service (S3).
Krok 3: Atakujący użył poświadczeń znalezionych w poprzednim kroku, aby przeskoczyć lateralnie po sieci. Skontaktował się bezpośrednio z interfejsem API AWS i przystąpił do zbierania informacji i eksfiltracji danych. Na tym etapie cyberprzestępcy byli w stanie:
- wyłączyć dzienniki CloudTrail, aby uniknąć wykrycia,
- kraść zastrzeżone oprogramowanie,
- znaleźć poświadczenia użytkownika IAM powiązane z innym kontem AWS, wykrywając pliki stanu Terraform w zasobnikach S3.
Krok 4: Atakujący użył nowych danych uwierzytelniających, aby ponownie przejść w bok, powtarzając atak i cały łańcuch z innego znalezionego konta AWS. Na szczęście w tym przypadku nie był w stanie enumerować zasobów, ponieważ wszystkie żądania API AWS, których próbował, zakończyły się niepowodzeniem z powodu braku uprawnień.
Podsumowanie
Na opisywanym przykładzie widzimy, iż nowe technologie nie mogą być uważane za bezpieczne. Przy projektowaniu nowych rozwiązań bezpieczeństwo powinno być jednym z priorytetów, gdyż hakerzy zawsze znajdą możliwość wykorzystania słabości środowiska.
