Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla organizacji rozwijających aplikacje w modelu chmurowym. Incydent przypisywany grupie UNC6426 pokazuje, że kompromitacja pojedynczego pakietu w ekosystemie npm może stać się początkiem pełnego przejęcia środowiska deweloperskiego, repozytoriów kodu oraz infrastruktury AWS.
W opisywanym scenariuszu punktem wejścia była wcześniejsza kompromitacja pakietu nx. Złośliwy komponent doprowadził do kradzieży poświadczeń dewelopera, a następnie umożliwił atakującym eskalację dostępu przez GitHub i CI/CD aż do roli administratora w chmurze.
W skrócie
Atak rozpoczął się od zainfekowanego pakietu nx w rejestrze npm, który uruchamiał złośliwy kod na stacji roboczej dewelopera. Napastnicy przechwycili token GitHub, przeprowadzili rekonesans w repozytoriach i pipeline’ach, a następnie pozyskali sekrety wykorzystywane w procesach automatyzacji.
Kolejnym etapem było nadużycie federacji GitHub-AWS opartej o OIDC. Dzięki zbyt szerokim uprawnieniom roli powiązanej z CloudFormation atakujący utworzyli nową rolę IAM z polityką AdministratorAccess, uzyskując pełną kontrolę nad środowiskiem AWS w czasie krótszym niż 72 godziny.
- wejście przez kompromitację pakietu npm,
- kradzież tokena GitHub i sekretów CI/CD,
- wykorzystanie OIDC do uzyskania tymczasowych poświadczeń AWS,
- eskalacja do pełnych uprawnień administratora,
- eksfiltracja danych i działania destrukcyjne w środowisku produkcyjnym.
Kontekst / historia
Tłem incydentu była kompromitacja pakietu nx npm z sierpnia 2025 roku. Ustalenia wskazują, że napastnicy mieli wykorzystać podatny workflow typu pull_request_target, co pozwoliło im uzyskać podwyższone uprawnienia w procesie CI/CD i doprowadzić do publikacji złośliwych wersji pakietu.
Zainfekowane wydania zawierały skrypt postinstall, który po instalacji rozpoczynał zbieranie danych środowiskowych oraz poświadczeń. To istotny przykład tego, jak naruszenie lokalnego narzędzia developerskiego może bardzo szybko przełożyć się na kompromitację systemów budowania, repozytoriów oraz zasobów chmurowych.
Incydent łączy w sobie trzy krytyczne obszary ryzyka: bezpieczeństwo łańcucha dostaw oprogramowania, ochronę tożsamości oraz błędną konfigurację uprawnień w środowisku cloud-native. W praktyce oznacza to, że nawet pozornie ograniczony incydent na endpointcie dewelopera może stać się początkiem pełnoskalowego naruszenia organizacji.
Analiza techniczna
Złośliwy pakiet miał osadzać skrypt postinstall uruchamiający narzędzie do kradzieży poświadczeń określane jako QUIETVAULT. Mechanizm ten zbierał zmienne środowiskowe, informacje o systemie oraz cenne tokeny, w tym GitHub Personal Access Tokens. Dodatkowo wykorzystywał lokalnie dostępne narzędzia oparte na modelach językowych do przeszukiwania systemu pod kątem wrażliwych danych.
W analizowanym przypadku wykonanie złośliwego komponentu miało nastąpić w trakcie korzystania z edytora kodu używającego wtyczki Nx Console. Aktualizacja lub aktywacja komponentu doprowadziła do przejęcia tokena dewelopera, co otworzyło drogę do dalszych działań w środowisku GitHub.
Po uzyskaniu tokena PAT grupa UNC6426 przeprowadziła działania rozpoznawcze i wykorzystała narzędzie open source Nord Stream do wydobycia sekretów z pipeline’ów CI/CD. W ten sposób pozyskano poświadczenia konta serwisowego GitHub, a następnie użyto mechanizmu pobierania tymczasowych tokenów AWS STS dla roli powiązanej z GitHub Actions i CloudFormation.
Kluczową słabością okazały się nadmierne uprawnienia roli federowanej z GitHub. Po przejęciu dostępu do roli Actions-CloudFormation atakujący wdrożyli nowy stos CloudFormation z możliwością tworzenia zasobów IAM. Następnie utworzyli nową rolę i przypisali do niej politykę AdministratorAccess, uzyskując pełne uprawnienia administracyjne w AWS.
Po eskalacji rozpoczęła się faza post-exploitation. Obejmowała ona odczyt i eksfiltrację danych z koszyków S3, działania wymierzone w instancje EC2 i bazy RDS, odszyfrowywanie kluczy aplikacyjnych oraz ingerencję w repozytoria GitHub, które zostały przemianowane i ustawione jako publiczne.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją tego typu ataku jest błyskawiczne przejście od kompromitacji pojedynczego urządzenia deweloperskiego do pełnego naruszenia środowiska chmurowego. Skutki mogą obejmować utratę poufności danych, zniszczenie zasobów produkcyjnych, przejęcie repozytoriów oraz ujawnienie sekretów aplikacyjnych.
Incydent pokazuje również, że skrypty postinstall w pakietach npm nadal stanowią realny problem bezpieczeństwa. W połączeniu z szerokimi tokenami PAT, źle zabezpieczonymi sekretami CI/CD i nadmiarowymi uprawnieniami IAM tworzą one bardzo skuteczną ścieżkę eskalacji.
Rosnące znaczenie ma także ryzyko związane z narzędziami AI używanymi lokalnie przez programistów. Jeżeli takie komponenty mają dostęp do plików, tokenów i aktywnych sesji, ich kompromitacja może zwiększyć zasięg ataku i utrudnić wykrycie nieautoryzowanych działań.
Rekomendacje
Organizacje powinny ograniczać wykonywanie skryptów postinstall wszędzie tam, gdzie jest to możliwe. Jeśli całkowite wyłączenie nie wchodzi w grę, warto wdrożyć sandboxing procesów instalacyjnych, kontrolę integralności zależności oraz monitorowanie anomalii podczas instalacji pakietów.
Niezbędne jest również ścisłe stosowanie zasady najmniejszych uprawnień wobec kont serwisowych, ról federowanych przez OIDC i zasobów CloudFormation. Role używane przez GitHub Actions nie powinny mieć możliwości tworzenia nowych ról IAM ani dołączania polityk administracyjnych bez dodatkowych zabezpieczeń i wyraźnego uzasadnienia biznesowego.
W obszarze zarządzania tożsamością należy stosować krótkotrwałe i precyzyjnie ograniczone tokeny GitHub PAT, regularnie rotować sekrety oraz monitorować ich wykorzystanie. Szczególną uwagę powinny zwracać nietypowe użycia STS, tworzenie nowych ról IAM, dołączanie polityki AdministratorAccess oraz nagłe operacje na S3, EC2 i RDS.
- blokowanie lub ograniczanie skryptów postinstall,
- ochrona workflow GitHub Actions przed nadużyciem pull_request_target,
- segmentacja uprawnień między środowiskiem developerskim i produkcyjnym,
- monitorowanie IAM, STS, CloudFormation, S3, EC2 i RDS,
- wdrożenie procedur szybkiego unieważniania tokenów i izolacji stacji deweloperskich,
- analiza działań narzędzi AI operujących na endpointach programistów.
Podsumowanie
Przypadek UNC6426 stanowi modelowy przykład wieloetapowego ataku łączącego kompromitację łańcucha dostaw npm, kradzież tożsamości deweloperskiej, nadużycie sekretów CI/CD oraz eskalację uprawnień w AWS. Najważniejszy wniosek jest jednoznaczny: pozornie lokalny incydent związany z pakietem developerskim może w bardzo krótkim czasie doprowadzić do przejęcia całej infrastruktury chmurowej.
Dla zespołów bezpieczeństwa oznacza to konieczność jednoczesnej ochrony zależności software’owych, tokenów dostępowych, pipeline’ów automatyzacji i federacji między GitHub a AWS. Bez ograniczania uprawnień oraz ciągłego monitorowania ścieżek zaufania podobne incydenty będą coraz trudniejsze do powstrzymania.
Źródła
- The Hacker News — UNC6426 Exploits nx npm Supply-Chain Attack to Gain AWS Admin Access in 72 Hours — https://thehackernews.com/2026/03/unc6426-exploits-nx-npm-supply-chain.html
- Google Cloud — Cloud Threat Horizons Report, H1 2026 — https://cloud.google.com/
- Praetorian — pull_request_target workflow security research — https://www.praetorian.com/
- Endor Labs — Pwn Request / GitHub Actions workflow abuse analysis — https://www.endorlabs.com/
- Socket — Analysis of AI-assisted software supply chain abuse — https://socket.dev/