Wprowadzenie do problemu / definicja
Najnowszy incydent związany z AWS pokazuje, iż zagrożenie dla bezpieczeństwa chmury nie zawsze wynika z luki w samej platformie. W tym przypadku kluczową rolę odegrało nadużycie relacji zaufania pomiędzy organizacjami a zewnętrznym dostawcą usług, co pozwoliło atakującym uzyskać dostęp do środowisk klientów przy użyciu legalnych mechanizmów cross-account access.
To klasyczny przykład ryzyka łańcucha dostaw w modelu cloud. Gdy partner technologiczny zostaje skompromitowany, jego uprawnienia i istniejące relacje zaufania mogą stać się furtką do wielu niezależnych środowisk jednocześnie.
W skrócie
Napastnicy przejęli dwa konta IAM powiązane z dostawcą usług i wykorzystali je do przejmowania ról w środowiskach klientów, które ufały wskazanemu kontu AWS. Kampania miała trwać od 14 do 26 października 2026 roku i objąć dziesiątki organizacji.
Po uzyskaniu tymczasowych poświadczeń atakujący prowadzili rozpoznanie zasobów, odczytywali sekrety z usług zarządzania tajemnicami, analizowali zmienne środowiskowe funkcji serverless, walidowali znalezione poświadczenia i pobierali dane z dostępnych bucketów S3. Nic nie wskazuje na kompromitację samego AWS — wykorzystano prawidłowo działające mechanizmy delegacji uprawnień i zaufania.
Kontekst / historia
W środowiskach AWS integracje z partnerami często opierają się na rolach IAM skonfigurowanych do zaufania zewnętrznemu kontu. Dzięki temu dostawca może użyć operacji AssumeRole i uzyskać tymczasowe poświadczenia do wykonania określonych działań w koncie klienta.
Model ten jest bezpieczny wyłącznie wtedy, gdy zakres zaufania jest ściśle ograniczony, regularnie audytowany i przez cały czas uzasadniony biznesowo. W opisywanym incydencie problemem okazały się historyczne lub rzadko używane role, które przez cały czas ufały kontu zewnętrznego dostawcy. Po przejęciu poświadczeń po stronie partnera stały się one bezpośrednią ścieżką wejścia do środowisk klientów.
Zdarzenie dobrze wpisuje się w szerszy trend ataków na zależności chmurowe. Coraz częściej przeciwnik nie atakuje bezpośrednio ofiary końcowej, ale szuka słabego punktu w relacjach federacyjnych, integracyjnych i operacyjnych.
Analiza techniczna
Techniczny rdzeń ataku opierał się na modelu cross-account IAM w AWS. jeżeli konto klienta posiada rolę z polityką zaufania dopuszczającą konkretne konto zewnętrzne, podmiot mający odpowiednie uprawnienia po stronie tego konta może wywołać AssumeRole i uzyskać tymczasowe poświadczenia do działania w środowisku ofiary.
Uprawnienia sesji są formalnie ograniczone polityką roli, ale w praktyce choćby umiarkowany dostęp może wystarczyć do rozpoznania infrastruktury, odczytu sekretów oraz pobierania danych. Według opisu incydentu atakujący najpierw identyfikowali dostępne zasoby, następnie sprawdzali zawartość bucketów i zakres możliwych akcji.
Kolejnym etapem było pobieranie sekretów z usług takich jak Secrets Manager i SSM Parameter Store, a także odczyt zmiennych środowiskowych funkcji Lambda. To szczególnie niebezpieczne, ponieważ sekrety aplikacyjne często umożliwiają dalszą eskalację i otwierają drogę do systemów SaaS, baz danych, środowisk CI/CD lub usług tożsamości.
Z dostępnych informacji wynika również, iż napastnicy używali narzędzia TruffleHog do walidacji znalezionych poświadczeń. Sugeruje to, iż odczyt sekretów był jedynie etapem budowy szerszego łańcucha dostępu, a celem było szybkie odróżnienie danych nieaktualnych od aktywnych kluczy i tokenów.
Charakter działań wskazuje na model oportunistyczny. jeżeli konkretna rola umożliwiała odczyt sekretów lub dostęp do zasobów S3, atakujący wykorzystywali tę możliwość bez konieczności precyzyjnego profilowania każdej ofiary. Taki schemat jest typowy dla kampanii nastawionych na maksymalizację korzyści przed wykryciem incydentu.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tego typu naruszenia jest możliwość cichej kompromitacji wielu środowisk jednocześnie bez łamania natywnych zabezpieczeń AWS. Z perspektywy zespołów SOC część aktywności może wyglądać jak legalne użycie zaufanej integracji, ponieważ operacje wykonywane są z użyciem prawidłowych mechanizmów STS i ról IAM.
Ryzyko obejmuje kilka warstw:
- eksfiltrację danych z bucketów S3, w tym danych wrażliwych i własności intelektualnej,
- kradzież sekretów umożliwiających lateral movement poza AWS,
- uzyskanie dostępu do systemów tożsamości, środowisk developerskich i usług SaaS,
- potencjalną utratę integralności konfiguracji lub procesów operacyjnych.
Dodatkowym problemem jest dług techniczny związany z nieużywanymi integracjami. Role pozostawione „na wszelki wypadek” tworzą martwe strefy zaufania, które mogą przez długi czas pozostać niewidoczne dla organizacji.
Rekomendacje
Organizacje korzystające z AWS powinny rozpocząć od pełnego przeglądu wszystkich ról cross-account oraz ich polityk zaufania. Każda relacja zewnętrzna powinna mieć przypisanego właściciela biznesowego, jasne uzasadnienie operacyjne i określony termin ważności.
Należy również stosować zasadę least privilege. Role zaufane zewnętrznym dostawcom nie powinny mieć szerokiego dostępu do Secrets Manager, SSM, S3 ani zasobów administracyjnych, jeżeli nie jest to bezwzględnie konieczne.
Warto wdrożyć dodatkowe zabezpieczenia w trust policy i monitoringu:
- stosowanie ExternalId,
- ograniczanie dostępu do konkretnych ARN i akcji,
- kontrola źródłowych adresów IP tam, gdzie to możliwe,
- monitorowanie nazw sesji i nietypowych wzorców AssumeRole,
- budowanie reguł korelacyjnych w CloudTrail dla ciągu działań po przejęciu roli.
W przypadku podejrzenia naruszenia organizacja powinna:
- przeanalizować logi CloudTrail od co najmniej początku października 2026 roku,
- zidentyfikować wszystkie role ufające kontom zewnętrznym,
- unieważnić aktywne sesje i tymczasowe poświadczenia,
- obrócić wszystkie sekrety dostępne dla potencjalnie nadużytych ról,
- sprawdzić buckety S3 pod kątem nieautoryzowanych odczytów,
- zweryfikować, czy skradzione sekrety nie umożliwiły dalszego dostępu do systemów tożsamości i usług SaaS.
Podsumowanie
Incydent z wykorzystaniem zaufanych ról AWS pokazuje, iż bezpieczeństwo chmury zależy nie tylko od konfiguracji własnego konta, ale również od jakości kontroli nad relacjami zewnętrznymi. Przejęcie poświadczeń IAM po stronie partnera może przełożyć się na dostęp do wielu środowisk klientów, jeżeli role cross-account są zbyt szerokie, nieużywane lub niewłaściwie monitorowane.
Najważniejsza lekcja płynąca z tego zdarzenia jest jasna: organizacje muszą stale przeglądać trust policy, ograniczać uprawnienia i rozwijać detekcję skoncentrowaną na nadużyciach legalnych mechanizmów federacyjnych. W nowoczesnym środowisku cloud to właśnie zaufanie bywa jednym z najcenniejszych, ale też najbardziej ryzykownych zasobów.
Źródła
- BleepingComputer – Hackers exploit trusted AWS access to breach multiple cloud environments — https://www.bleepingcomputer.com/news/security/hackers-exploit-trusted-aws-access-to-breach-multiple-cloud-environments/
- AWS Security Token Service API Reference – AssumeRole — https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
