Operacja Shai Hulud 2.0, wykryta 24 listopada 2025 roku, szybko przerosła początkowe opisy prostego ataku typu npm supply chain, który miał jedynie zalewać platformę GitHub spamowymi repozytoriami. Nowa analiza wykazała, że była to wysoce zaawansowana operacja. Wektor infekcji wykorzystywał naruszone pakiety npm, w których złośliwe skrypty były wykonywane na etapie „preinstall”.

Prawdziwym celem nie były repozytoria kodu, ale środowiska wykonawcze ofiar: punkty końcowe deweloperów, chmurowe serwery kompilacji oraz samodzielnie hostowane runnery CI/CD. Kampania dowiodła, że każde środowisko, w którym jest wykonywany kod, stanowi potencjalne zagrożenie.

‍

Kluczową cechą Shai Hulud 2.0 było to, że zamiast jedynie ekstrahować pliki statyczne, złośliwe oprogramowanie przechwytywało pełne środowiska wykonawcze. Z powodzeniem eksfiltrowało poufne dane z pamięci roboczej (runtime memory) oraz aktywne poświadczenia głęboko z firmowych potoków Continuous Integration/Continuous Delivery (CI/CD).

‍

Malware generowało artefakty, takie jak pliki environment.json, zawierające podwójnie zakodowane w base64 migawki pamięci. Pozwalało to atakującym na dokładne odtworzenie stanu skompromitowanych maszyn, uzyskując tym samym dostęp do sekretów przechowywanych w pamięci (in-memory secrets), które nigdy nie znajdowały się w repozytoriach kodu. Tysiące kontrolowanych przez atakujących repozytoriów GitHub służyły wyłącznie jako warstwa zbierająca na potrzeby tej szeroko zakrojonej kradzieży.

‍

Skala kompromitacji jest znacząca. Atak naruszył bezpieczeństwo niemal 1200 organizacji, w tym dużych instytucji finansowych, organów rządowych oraz korporacji technologicznych z listy Fortune 500. Badacze z Entro zidentyfikowali 1195 różnych organizacji dotkniętych incydentem, przy czym sektor technologiczny i SaaS ucierpiał najbardziej, stanowiąc ponad połowę zidentyfikowanych ofiar.

‍

Konsekwencją ataku jest ujawnienie krytycznych sekretów środowiska wykonawczego, takich jak aktywne Osobiste Tokeny Dostępu GitHub (Personal Access Tokens), klucze tajne AWS, tokeny produkcyjne blockchain czy klucze API Slack. Pomimo działań mających na celu usunięcie złośliwych repozytoriów, skradzione poświadczenia pozostają w rękach atakujących, a co najważniejsze, kontrole przeprowadzone po kilku dniach wykazały, że część tych kluczy była nadal ważna i nie została odwołana.

‍

Wobec ryzyka dalszego wykorzystania aktywnych sekretów, organizacje muszą podjąć natychmiastowe kroki ograniczające. Przedsiębiorstwa są pilnie wzywane do rotacji wszystkich tożsamości niebędących ludźmi (non-human identities). Należy założyć, że środowiska wykonawcze, w których operacje miały miejsce, są w pełni skompromitowane. Atak Shai Hulud 2.0 stanowi analogię do włamania do banku nie przez sam sejf (repozytoria kodu), ale przez główny system operacyjny (potoki CI/CD), co pozwoliło na kradzież aktywnych kluczy dostępu. Natychmiastowa zmiana wszystkich poświadczeń i przegląd zabezpieczeń są niezbędne.

‍

Strategie szybkiej rotacji tożsamości

Aby efektywnie zarządzać szybką rotacją tożsamości w środowiskach chmurowych, kluczowe jest wdrożenie mechanizmów Just-in-Time (JIT) oraz wykorzystanie dedykowanych rozwiązań do zarządzania sekretami. Zamiast statycznych kluczy, należy stosować krótko żyjące poświadczenia, wydawane dynamicznie na czas trwania konkretnego zadania CI/CD. Narzędzia takie jak HashiCorp Vault, AWS Secrets Manager, Azure Key Vault lub Google Cloud Secret Manager pozwalają na centralne przechowywanie, dostęp i automatyczną rotację sekretów.

‍

Systemy te integrują się bezpośrednio z potokami CI/CD i umożliwiają mechanizmy Identity and Access Management (IAM) oparte na rolach, które automatycznie generują tymczasowe poświadczenia na podstawie tożsamości runnnerów CI/CD. Dzięki temu, nawet w przypadku kradzieży, klucz jest aktywny tylko przez kilka minut, co minimalizuje okno czasowe dla ataku.

Weryfikacja Standardów Dostawców Usług ICT

Odnośnie do ataku typu supply chain, kluczowym krokiem jest natychmiastowy audyt i renegocjacja standardów bezpieczeństwa z dostawcami usług ICT (Information and Communications Technology) oraz wszystkimi partnerami, którzy mają dostęp do naszego łańcucha dostaw kodu. Organizacje powinny wymagać od dostawców (szczególnie tych świadczących usługi CI/CD, hosting repozytoriów czy dostarczających krytyczne pakiety i biblioteki) udokumentowania, w jaki sposób wdrożyli zasadę najmniejszego przywileju (Least Privilege) w swoich własnych środowiskach wykonawczych oraz w jaki sposób zarządzają i rotują poświadczeniami.

‍

Należy bezwzględnie egzekwować stosowanie przez dostawców krótko żyjących, dynamicznych tokenów oraz weryfikację integralności wszystkich pakietów zewnętrznych. Ponadto, konieczne jest uzyskanie formalnych oświadczeń dotyczących podjętych środków zaradczych i procedur w przypadku podobnych incydentów. Współpraca musi opierać się na wzajemnym zaufaniu i audytowalnej przejrzystości praktyk bezpieczeństwa dostawców.

Nowy standard bezpieczeństwa 

Chociaż incydent Shai Hulud 2.0 ujawnił dotkliwe luki w łańcuchu dostaw oprogramowania, stanowi on również bezcenną lekcję dla całej branży. Atak ten, choć wyrafinowany, nie jest końcem historii, lecz wezwaniem do wzmożonej czujności i adaptacji.

‍

Przestawienie się z ochrony repozytoriów na zabezpieczanie środowisk wykonawczych jest nowym, nieuniknionym standardem.

‍

Pamiętajmy, że cyberbezpieczeństwo to nie tylko kosztowna bariera, ale ciągły proces, który z każdą udaremnioną próbą ataku czyni nasze systemy silniejszymi i bardziej odpornymi. Wdrażając dynamiczne zarządzanie sekretami i traktując każdy element potoku CI/CD z należytą ostrożnością, organizacje mogą przekształcić to zagrożenie w impuls do budowy architektury, której podstawą jest zaufanie i niezawodność, skutecznie minimalizując ryzyko w przyszłości.

‍