Nadużycie zaufanego dostępu Qubole do AWS umożliwiło przejęcie ról IAM i kradzież danych klientów

Wprowadzenie do problemu / definicja

Incydent związany z Qubole ujawnia istotne ryzyko wynikające z relacji zaufania między dostawcą SaaS a środowiskiem klienta w AWS. W tym przypadku napastnik wykorzystał konto AWS powiązane z usługą Qubole do przejmowania ról IAM skonfigurowanych przez klientów w modelu cross-account access, co otworzyło drogę do dostępu do zasobów wielu organizacji bez konieczności bezpośredniego naruszania ich własnych mechanizmów logowania.

W skrócie

Według ustaleń badaczy aktywność atakującego była obserwowana od 14 do 26 października 2026 roku. Po uzyskaniu dostępu do ról IAM zaufanych przez klientów napastnik prowadził rozpoznanie środowisk, odczytywał sekrety z AWS Secrets Manager i AWS Systems Manager Parameter Store, pobierał zmienne środowiskowe funkcji Lambda, testował pozyskane poświadczenia oraz kopiował dane z zasobów Amazon S3.

Wektor wejścia opierał się na zaufaniu do konta AWS używanego przez Qubole.
Atak objął także nieużywane już integracje, jeśli relacje zaufania nadal pozostawały aktywne.
Napastnik koncentrował się zarówno na sekretach, jak i na możliwej eksfiltracji danych.

Kontekst / historia

Qubole funkcjonuje jako platforma analityczna i przetwarzania danych, która uzyskuje dostęp do środowisk AWS klientów poprzez role IAM tworzone po stronie organizacji. Standardowy model integracyjny zakłada, że klient konfiguruje rolę z polityką zaufania umożliwiającą dostawcy wykonanie operacji STS AssumeRole. Często dodatkowo stosowany jest External ID, który ma ograniczać ryzyko nadużycia dostępu przez podmiot trzeci.

W tym incydencie właśnie ten model zaufania stał się wektorem ataku. Szczególnie niebezpieczne okazały się role pozostawione po dawnych integracjach, które formalnie nadal akceptowały żądania AssumeRole. Badacze odnotowali również osobną falę aktywności z okresu 8–11 października 2026 roku, podczas której wykorzystywano klucze dostępowe AWS należące do klientów i powiązane z integracją Qubole, choć nie połączono jej bezpośrednio z późniejszym nadużyciem ról IAM.

Analiza techniczna

Mechanizm ataku był oparty na przejęciu możliwości wykonywania AssumeRole wobec ról IAM zaufanych przez konto AWS używane przez Qubole. Jeżeli polityka trust relationship dopuszczała konto dostawcy jako principal oraz spełniony był warunek External ID, operacja kończyła się powodzeniem. Kluczowe jest to, że External ID nie jest sekretem kryptograficznym i nie powinien być traktowany jako samodzielne zabezpieczenie. Gdy atakujący uzyska kontrolę nad właściwą tożsamością po stronie dostawcy, sam External ID nie stanowi skutecznej bariery.

Po uzyskaniu tymczasowych poświadczeń STS napastnik wykonywał szerokie rozpoznanie środowiska. Obejmowało ono między innymi identyfikację bucketów S3, zasobów obliczeniowych, baz danych, ról IAM oraz kluczy KMS. Szczególną uwagę poświęcono miejscom przechowywania sekretów i konfiguracji:

zmiennym środowiskowym funkcji AWS Lambda,
AWS Secrets Manager,
AWS Systems Manager Parameter Store.

Pozyskane poświadczenia były następnie walidowane. Badacze wskazali użycie narzędzia TruffleHog do sprawdzania poprawności kluczy AWS, sekretów aplikacyjnych Entra ID oraz poświadczeń klientów Okta. Taki schemat działania sugeruje, że celem atakującego było nie tylko jednorazowe pobranie danych, ale również rozszerzenie dostępu na kolejne systemy i usługi.

W obszarze eksfiltracji danych działania miały charakter oportunistyczny. Zamiast szukać wyłącznie pojedynczych obiektów, napastnik pobierał dane z bucketów dostępnych dla przejętej roli, a w części przypadków ściągał całe zasoby S3 w trakcie jednej sesji. Z punktu widzenia dochodzenia powłamaniowego ma to istotne znaczenie, ponieważ standardowe CloudTrail management events rejestrują operacje typu AssumeRole i wybrane działania administracyjne, ale bez aktywnych S3 data events lub access logs organizacja może nie ustalić precyzyjnie, które obiekty zostały odczytane.

Wśród wskaźników kompromitacji i elementów przydatnych w polowaniu na zagrożenia wskazano:

zdarzenia AssumeRole pochodzące z konta 805246085872,
nietypowe adresy IP spoza infrastruktury AWS,
principal ID powiązane z podejrzaną aktywnością,
nazwy sesji roli rozpoczynające się od prefiksu „quiam-”,
wywołania GetCallerIdentity z user-agentem narzędzia TruffleHog.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją tego typu incydentu jest przełamanie granicy zaufania między klientem a dostawcą usługi. Jeżeli integracyjna rola IAM posiada szerokie uprawnienia, kompromitacja po stronie dostawcy może niemal natychmiast przełożyć się na dostęp do danych, konfiguracji i sekretów w wielu niezależnych środowiskach.

Ryzyko operacyjne obejmuje kilka warstw. Wyciek sekretów z Lambda, Secrets Manager i SSM Parameter Store może prowadzić do dalszych kompromitacji aplikacji, systemów lokalnych, tożsamości uprzywilejowanych i innych kont chmurowych. Eksfiltracja danych z S3 może z kolei oznaczać naruszenie poufności danych analitycznych, biznesowych, telemetrycznych lub regulowanych. Dodatkowym utrudnieniem jest fakt, że użycie tymczasowych poświadczeń STS komplikuje analizę incydentu, jeśli organizacja nie zapewniła pełnego pokrycia logowaniem we wszystkich kontach i regionach.

Szczególnie niebezpieczne są tzw. martwe relacje zaufania, czyli nieużywane, lecz nadal aktywne integracje. Takie konfiguracje stają się ukrytą podatnością organizacyjną i znacząco zwiększają powierzchnię ataku.

Rekomendacje

Organizacje, które obecnie korzystają lub w przeszłości korzystały z integracji Qubole w AWS, powinny pilnie przeprowadzić przegląd ról cross-account oraz zdarzeń CloudTrail co najmniej od 1 października 2026 roku. W praktyce warto wdrożyć następujące działania:

Zidentyfikować wszystkie role IAM ufające zewnętrznym kontom dostawców i potwierdzić ich aktualną potrzebę biznesową.
Usunąć nieużywane role integracyjne albo usunąć konto dostawcy z polityki zaufania.
Ograniczyć principal w trust policy z poziomu całego konta do konkretnej tożsamości IAM, jeśli dostawca dopuszcza taki model.
Dodać warunki aws:SourceIp lub aws:SourceVpce, aby ograniczyć AssumeRole do znanych zakresów sieciowych dostawcy.
Traktować External ID jako dodatkowy warunek logiczny, a nie jako pełnoprawny sekret bezpieczeństwa.
Zweryfikować uprawnienia ról dostawców zgodnie z zasadą najmniejszych uprawnień, zwłaszcza w obszarze S3, Lambda, Secrets Manager i SSM.
Włączyć centralne logowanie CloudTrail dla wszystkich kont i regionów oraz aktywować S3 data events lub access logs dla bucketów z danymi wrażliwymi.
Przeprowadzić rotację wszystkich sekretów, parametrów i poświadczeń, do których przejęta rola mogła mieć dostęp.
Unieważnić aktywne sesje roli, ponieważ sama rotacja poświadczeń nie kończy już wydanych sesji tymczasowych.
Zbudować detekcje dla AssumeRole wykonywanych z nietypowych sieci, usług VPN, serwerów VPS i innych lokalizacji niewystępujących wcześniej w ruchu dostawcy.

Z perspektywy architektury bezpieczeństwa incydent ten potwierdza, że dostęp third-party do chmury powinien być stale inwentaryzowany, ograniczany i monitorowany z taką samą rygorystycznością jak własne konta uprzywilejowane organizacji.

Podsumowanie

Sprawa Qubole i AWS stanowi przykład ataku na łańcuch zaufania w chmurze, a nie klasycznego włamania do pojedynczego konta klienta. Napastnik wykorzystał relacje zapisane w politykach IAM, aby przejmować role w wielu środowiskach i uzyskiwać dostęp do sekretów oraz danych. Najważniejszy wniosek dla zespołów bezpieczeństwa jest jednoznaczny: każda relacja cross-account z dostawcą SaaS stanowi uprzywilejowany kanał dostępu, który musi podlegać ciągłemu przeglądowi, zasadzie najmniejszych uprawnień, restrykcjom sieciowym i pełnemu monitoringowi.