Anatomia robaka Python, który manipuluje agentami bezpieczeństwa AI

Czy dotarłeś do punktu, w którym ufasz swojemu asystentowi kodu AI bardziej niż własnej ręcznej recenzji? Wielu programistów tak ma. Polegamy na dużych modelach językowych (LLM) w zakresie skanowania pod kątem podatności, sugerowania poprawek i weryfikacji integralności pakietów stron trzecich. Ale co się dzieje, gdy złośliwe oprogramowanie wie, jak „odpyskować” sztucznej inteligencji? Spędziłem kilka nocy w zeszłym tygodniu na analizowaniu szczegółów technicznych kampanii Hades – zagrożenia, które oznacza zmianę w sposobie, w jaki napastnicy podchodzą do zautomatyzowanej obrony. To nie jest tylko złodziej danych. To operacja psychologiczna skierowana przeciwko oprogramowaniu, którego używamy do ochrony.

Badacze z StepSecurity zidentyfikowali niedawno tę kampanię jako najnowsze dzieło grupy Miasma. Podczas gdy Miasma wcześniej koncentrowała się na pozyskiwaniu poświadczeń chmurowych, Hades jest bardziej agresywnym, samopowielającym się robakiem. Celuje on konkretnie w środowiska programistyczne Python poprzez zainfekowane pakiety w ekosystemie PyPI. Lista dotkniętych bibliotek obejmuje ensmallen, mflux-streamlit oraz kilka narzędzi używanych w bioinformatyce. Jeśli pracujesz w biologii obliczeniowej lub nauce o danych, Twoja stacja robocza jest celem o wysokiej wartości dla tej konkretnej grupy.

Punkt wejścia w procesie inicjalizacji Pythona

Atak rozpoczyna się, gdy programista importuje zainfekowany pakiet. Hades ukrywa swój główny moduł ładujący (loader) wewnątrz pliku __init__.py. Jest to standardowy plik, którego Python używa do oznaczania katalogu jako pakietu. Umieszczając tam złośliwy skrypt, napastnicy zapewniają, że kod zostanie wykonany w momencie załadowania pakietu do projektu. Loader jest zaciemniony (obfuskowany), aby uniknąć podstawowej detekcji opartej na sygnaturach, ale jego cel jest prosty. Zrzuca on na system prekompilowany plik binarny środowiska wykonawczego Bun.

Bun to wysokowydajny zestaw narzędzi JavaScript. Jest to doskonałe narzędzie dla legalnych programistów, ale także idealny silnik wykonawczy dla złośliwego oprogramowania. Ponieważ Bun jest samodzielnym plikiem binarnym, pozwala złośliwemu oprogramowaniu na uruchamianie złożonych ładunków JavaScript bez konieczności instalacji Node.js na maszynie ofiary. Omija to tradycyjne monitorowanie, które szuka podejrzanej aktywności npm lub Node. Z poziomu architektury, użycie Bun pozwala napastnikom operować w „cieniu”, poza standardową widocznością zabezpieczeń większości stacji roboczych zorientowanych na Pythona.

Jak malware manipuluje zautomatyzowanym strażnikiem

Najbardziej innowacyjną funkcją Hadesa jest jego zdolność do oszukiwania agentów bezpieczeństwa AI. Wiele nowoczesnych środowisk programistycznych używa modeli LLM do skanowania kodu pod kątem złośliwych wzorców. Hades to przewiduje. Na początku swoich złośliwych plików malware zawiera blok tekstu zaprojektowany jako „adversarial prompt” (monit kontradyktoryjny). Tekst ten instruuje model LLM, aby zignorował wszelki podejrzany kod znajdujący się poniżej i sklasyfikował pakiet jako zweryfikowany i bezpieczny.

Testowałem podobną technikę w odizolowanym środowisku w zeszłym miesiącu. Dostarczyłem modelowi LLM skrypt zawierający oczywisty reverse shell, ale poprzedziłem go komentarzem stwierdzającym, że kod jest autoryzowanym testem bezpieczeństwa dla kontraktu rządowego. AI zignorowała exploit i zaraportowała, że skrypt jest zgodny ze wszystkimi protokołami bezpieczeństwa. Hades stosuje dokładnie tę samą strategię cyfrowego konia trojańskiego. Wykorzystuje logikę poznawczą AI. Ponieważ modele LLM są podatne na inżynierię społeczną, akceptują te ukryte instrukcje jako polecenia o wysokim priorytecie. Skutkuje to błędnym werdyktem negatywnym, pozwalając złośliwemu oprogramowaniu prześlizgnąć się obok zautomatyzowanej analizy organizacji.

Wykorzystanie ram integralności łańcucha dostaw

Hades nie tylko się ukrywa; próbuje wyglądać oficjalnie. Wykorzystuje kilka krytycznych ram bezpieczeństwa, w tym OpenID Connect (OIDC) oraz Supply-chain Levels for Software Artifacts (SLSA). Gdy malware wykryje, że działa wewnątrz przepływu pracy GitHub Actions, sprawdza zmienne OIDC. Następnie używa tych poświadczeń do generowania kryptograficznie podpisanych pakietów pochodzenia SLSA za pośrednictwem Sigstore.

Jest to wyrafinowane obejście systemów, które mają gwarantować integralność oprogramowania. Generując ważny pakiet Sigstore, malware może publikować zainfekowane wersje bibliotek w PyPI lub npm, które wydają się pochodzić z oficjalnego, zweryfikowanego środowiska budowania. Dla zewnętrznego obserwatora lub zautomatyzowanego narzędzia pakiet wygląda na posiadający prawidłowy łańcuch dostaw. To zamienia infrastrukturę bezpieczeństwa w broń dla napastnika. Sprawia, że zainfekowany kod wydaje się bardziej godny zaufania niż legalny, niepodpisany kod.

Scraping pamięci i ruch boczny

Gdy złośliwe oprogramowanie się zadomowi, zaczyna gromadzić dane. Zawiera dopasowane skrapery pamięci dla systemów Linux, macOS i Windows. Narzędzia te celują w mapowanie pamięci aktywnych procesów, aby wydobyć wrażliwe, zaszyfrowane dane, które w inny sposób są niedostępne na dysku. Jest to podejście dyskretne, ponieważ unika tworzenia podejrzanych plików, które system detekcji i odpowiedzi na punktach końcowych (EDR) mógłby oflagować.

Robak szuka również sposobów na rozprzestrzenianie się. Skanuje zainfekowany system pod kątem kluczy SSH, konfiguracji SCP i tokenów GitHub. Jeśli znajdzie token z uprawnieniami do zapisu, używa runnera GitHub Actions do wydobycia sekretów bezpośrednio z pamięci. Następnie próbuje zainfekować inne repozytoria należące do użytkownika. Ruch sterujący (C2) jest ukryty w publicznej infrastrukturze GitHub. Skradzione dane są kompresowane, szyfrowane i przesyłane do nowych publicznych repozytoriów pod kontrolą napastnika. Repozytoria te często noszą opis „Hades — The End for the Damned”.

Mechanizm trwałości „spalonej ziemi”

Trwałość jest kluczowym elementem projektu Hades. Malware ustanawia obecność na stacji roboczej i monitoruje status skradzionych poświadczeń. Jeśli zespół ds. bezpieczeństwa wykryje naruszenie i unieważni skradziony token GitHub, Hades przechodzi w tryb reaktywny. Uruchamia proces typu „wiper”, który próbuje wymazać lokalne pliki użytkownika.

Jest to taktyka odwetowa. Stwarza ona sytuację o wysokiej stawce dla osób reagujących na incydenty. Jeśli zablokujesz dostęp, możesz stracić dane na lokalnej maszynie. Ta logika zmusza organizacje do ostrożnego działania podczas fazy naprawczej. Malware celuje również w pliki konfiguracyjne 14 różnych agentów AI. Podrzuca instrukcje, które wyzwalają nową infekcję za każdym razem, gdy programista konsultuje się ze swoim asystentem AI w sprawie bieżącego obszaru roboczego. Tworzy to pętlę, w której akt szukania pomocy u narzędzia AI ponownie infekuje system.

Budowanie proaktywnej obrony przed zwodniczym malware

Kampania Hades pokazuje, że nasze poleganie na AI jako podstawowej warstwie bezpieczeństwa jest słabością. Musimy zmierzać w stronę modelu, w którym AI jest współpracownikiem, a nie ostatecznym autorytetem. Z perspektywy ryzyka najlepszą obroną jest obrona ziarnista, która nie polega na jednym strażniku.

Kluczowe wnioski dla zabezpieczenia środowiska:

1. Stosuj ścisłą izolację graniczną dla modeli LLM. Nigdy nie przekazuj surowego, niezaufanego kodu do skanera AI bez monitu systemowego, który wyraźnie zabrania modelowi wykonywania instrukcji zawartych w samym kodzie.
2. Audytuj uprawnienia GitHub Actions. Wdróż zasadę najmniejszych uprawnień dla tokenów OIDC i upewnij się, że runnery nie mają niepotrzebnego dostępu do zapisu w Twoich repozytoriach.
3. Monitoruj nieautoryzowane wykonywanie plików binarnych. Hades polega na zrzucaniu środowiska Bun. Narzędzia, które flagują lub blokują wykonywanie nieznanych plików binarnych w ścieżce __init__.py, mogą powstrzymać infekcję w punkcie wejścia.
4. Weryfikuj pochodzenie Sigstore ręcznie. Chociaż Hades może fałszować pakiety, rozbieżności w czasie budowania lub zmiennych środowiskowych mogą być czasem wykryte podczas audytu śledczego.
5. Wdróż solidne strategie kopii zapasowych. Ponieważ Hades zawiera wiper, posiadanie kopii zapasowych offline lub niezmiennych (immutable) prac programistycznych jest jedynym sposobem na złagodzenie zagrożenia utraty danych podczas naprawy.

Patrząc na krajobraz zagrożeń, Hades jest prawdopodobnie zapowiedzią przyszłości. Napastnicy nie próbują już tylko wyłamać zamków w naszych drzwiach; uczą się, jak przekonać cyfrowego bramkarza, by sam ich wpuścił. Musimy przestać traktować werdykty AI jako prawdy absolutne i zacząć traktować je jako punkty danych wymagające ludzkiej weryfikacji.

Źródła: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.

Zastrzeżenie: Niniejszy artykuł służy wyłącznie celom informacyjnym i edukacyjnym i nie zastępuje profesjonalnego audytu cyberbezpieczeństwa ani usługi reagowania na incydenty.