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, że 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 oprogramowania 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ę za pomocą 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
Krok 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ń za pomocą 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ń.
Zródło: https://sysdig.com/blog/cloud-breach-terraform-data-theft/
