W 10 minut przejęli chmurę AWS. AI działa szybciej niż człowiek

Badacze z zespołu Threat Research w Sysdig ujawnili jeden z najszybszych i najbardziej niepokojących incydentów bezpieczeństwa w środowisku AWS, jaki dotąd zaobserwowano.

Cyfrowy intruz, wykorzystując wsparcie sztucznej inteligencji, przeszedł drogę od pierwszego dostępu do pełnych uprawnień administracyjnych w czasie krótszym niż dziesięć minut. Skala automatyzacji oraz charakter pozostawionych śladów wskazują na nową jakość zagrożeń, w których duże modele językowe stają się integralnym elementem ofensywnych operacji w chmurze.

Incydent został wykryty 28 listopada i od początku zwrócił uwagę badaczy nie tylko tempem działania, ale również spójnością kolejnych etapów ataku. Rozpoznanie, eskalacja uprawnień, ruch boczny, generowanie kodu oraz przejęcie dostępu do hostowanych modeli AI następowały po sobie w sposób sugerujący szerokie wykorzystanie automatyzacji opartej na LLM.

Chmura staje się polem testowym dla nowej generacji ataków wspomaganych przez sztuczną inteligencję.

Pierwszy krok: publiczny S3 jako furtka do chmury

Atak rozpoczął się od kradzieży prawidłowych danych uwierzytelniających, które znajdowały się w publicznie dostępnym kontenerze Amazon S3. Klucze należały do użytkownika IAM dysponującego rozbudowanymi uprawnieniami do usług AWS Lambda oraz ograniczonym dostępem do Amazon Bedrock. W tym samym kontenerze znajdowały się również dane Retrieval-Augmented Generation wykorzystywane przez modele AI, które później odegrały istotną rolę w dalszej fazie włamania.

Już na tym etapie widać było, że atakujący działał według wcześniej przygotowanego schematu. Po nieudanych próbach użycia typowych nazw kont administracyjnych intruz przeszedł do eskalacji uprawnień z użyciem wstrzyknięcia kodu do istniejącej funkcji Lambda.

Lambda jako narzędzie przejęcia administracji

Wykorzystując uprawnienia UpdateFunctionCode oraz UpdateFunctionConfiguration, atakujący trzykrotnie podmienił kod funkcji EC2-init, testując kolejne konta docelowe. Dopiero trzecia próba zakończyła się sukcesem i pozwoliła na przejęcie użytkownika z pełnymi uprawnieniami administracyjnymi. Cały proces odbył się w czasie, który w klasycznych scenariuszach ataku byłby praktycznie niemożliwy do osiągnięcia ręcznie.

Kod pozostawiony w funkcji Lambda zawierał rozbudowaną obsługę wyjątków, logikę kontroli limitów listowania zasobów oraz zmienione parametry czasu wykonania. Dla badaczy Sysdig był to wyraźny sygnał, że kod został wygenerowany lub przynajmniej istotnie wspomagany przez duży model językowy.

Ślady sztucznej inteligencji w kodzie atakującego

Szczególną uwagę zwróciły komentarze w języku serbskim, a także obecność nieistniejących identyfikatorów kont AWS oraz fikcyjnych repozytoriów GitHub. Wśród zbieranych identyfikatorów znalazły się ciągi liczbowe znane z dokumentacji i przykładów testowych, jak również jedno prawdziwe konto zewnętrzne. Tego rodzaju niespójności są powszechnie kojarzone z halucynacjami generatywnych modeli językowych.

Zdaniem badaczy takie artefakty stanowią jeden z najmocniejszych dowodów na wykorzystanie LLM w trakcie rzeczywistego ataku produkcyjnego, a nie jedynie w fazie przygotowań.

Dziewiętnaście tożsamości i pełny wgląd w dane

Po uzyskaniu dostępu administracyjnego intruz przejął łącznie dziewiętnaście tożsamości AWS, obejmujących użytkowników IAM oraz role wykorzystywane w różnych sesjach. W efekcie uzyskał dostęp do sekretów przechowywanych w Secrets Manager, parametrów SSM, logów CloudWatch, zdarzeń CloudTrail, kodu funkcji Lambda oraz wewnętrznych danych zapisanych w kontenerach S3.

Skala pozyskanych informacji otwierała drogę zarówno do dalszej eskalacji, jak i do wykorzystania środowiska ofiary w zupełnie innych celach.

LLMjacking i przejęcie mocy obliczeniowej

Kolejnym etapem było przejęcie dostępu do hostowanych modeli językowych w Amazon Bedrock. Atakujący wywoływał modele, które wcześniej nie były używane na danym koncie, w tym Claude, DeepSeek, Llama, Amazon Nova Premier, Titan Image Generator oraz Cohere Embed. Dla zespołów bezpieczeństwa jest to jeden z wyraźniejszych sygnałów nadużyć w środowiskach AI-as-a-Service.

Równolegle intruz rozpoczął rekonesans zasobów EC2, wyszukując obrazy maszyn przeznaczone do obciążeń związanych z uczeniem maszynowym. W kontenerach S3 pojawiły się skrypty sugerujące próby trenowania modeli, choć jeden z nich odwoływał się do repozytorium GitHub, które w rzeczywistości nie istnieje.

Na krótko uruchomiono również publicznie dostępny serwer JupyterLab na porcie 8888, który mógł pełnić funkcję tylnego wejścia do instancji obliczeniowej. Z nieznanych przyczyn instancja została wyłączona po kilku minutach.

Nowa era cyberataków wspomaganych przez AI

Choć badacze nie są w stanie jednoznacznie określić celu atakującego, scenariusze obejmują zarówno trenowanie własnych modeli, jak i odsprzedaż dostępu do kosztownych zasobów GPU. Incydent ten pokazuje rosnące możliwości wykorzystania sztucznej inteligencji na niemal każdym etapie łańcucha ataku.

Eksperci ds. bezpieczeństwa podkreślają, że agenci AI nie działają jeszcze w pełni autonomicznie, ale już teraz znacząco skracają czas potrzebny na przeprowadzenie złożonych operacji ofensywnych. Dla organizacji oznacza to konieczność radykalnego wzmocnienia kontroli tożsamości, ograniczenia uprawnień oraz monitorowania wykorzystania usług AI w chmurze.

AWS odpowiada: infrastruktura działała zgodnie z założeniami

Amazon, odnosząc się do raportu, podkreślił, że infrastruktura i usługi AWS nie były podatne na atak, a incydent wynikał z błędnej konfiguracji po stronie klienta. Firma przypomniała o konieczności stosowania najlepszych praktyk bezpieczeństwa, w tym nieudostępniania publicznego dostępu do kontenerów S3, zarządzania poświadczeniami oraz korzystania z usług monitorujących aktywność w chmurze.