HalluSquatting, slopsquatting i phantom squatting: nowy wzorzec ataku na agentów AI

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Rozwój agentów AI wykorzystywanych do pisania kodu, automatyzacji zadań deweloperskich i obsługi procesów DevOps stworzył nową klasę ryzyk dla łańcucha dostaw oprogramowania. Istota problemu polega na tym, że modele językowe potrafią generować wiarygodnie brzmiące, lecz nieistniejące nazwy pakietów, domen, repozytoriów lub rozszerzeń, a następnie systemy automatyzacji traktują je jak prawdziwe i zaufane zasoby.

W efekcie napastnik może przejąć inicjatywę, rejestrując przewidywaną nazwę zanim zrobi to legalny podmiot. Gdy agent AI spróbuje pobrać taki zasób, organizacja może nieświadomie wprowadzić do środowiska złośliwy komponent.

W skrócie

HalluSquatting, slopsquatting i phantom squatting opisują ten sam podstawowy mechanizm nadużycia: wykorzystanie nazw wygenerowanych przez AI bez ich wcześniejszej weryfikacji. Różnice dotyczą przede wszystkim rodzaju przejmowanego zasobu.

Slopsquatting dotyczy głównie pakietów i bibliotek.
Phantom squatting koncentruje się na domenach internetowych.
HalluSquatting obejmuje repozytoria, rozszerzenia i komponenty używane przez agentów kodujących.

Z punktu widzenia bezpieczeństwa to jeden problem architektoniczny: zaufanie do identyfikatora wygenerowanego przez model bez sprawdzenia jego autentyczności, reputacji i integralności.

Kontekst / historia

Wraz z popularyzacją narzędzi AI dla programistów badacze zaczęli obserwować sytuacje, w których modele podpowiadały nazwy nieistniejących pakietów. Część z nich była zlepkiem nazw realnych projektów, przez co wyglądały przekonująco zarówno dla użytkownika, jak i dla zautomatyzowanego pipeline’u.

Następnie uwagę zwrócono na podobny wzorzec w obszarze domen internetowych. Modele językowe mogły sugerować adresy, które nie istniały, ale dało się je łatwo przewidzieć i zarejestrować. To otworzyło drogę do phishingu, dystrybucji malware oraz przejmowania ruchu generowanego przez użytkowników i agentów AI.

Kolejne analizy rozszerzyły ten sam schemat na repozytoria i komponenty instalowane automatycznie przez agentów programistycznych. W ten sposób powstały różne nazwy opisujące to samo zjawisko, które dziś coraz częściej traktowane jest jako nowy wariant zagrożenia dla software supply chain.

Analiza techniczna

Techniczny fundament ataku opiera się na probabilistycznym działaniu modeli językowych. LLM nie potwierdza istnienia pakietu czy domeny w sposób deterministyczny, lecz generuje odpowiedź statystycznie dopasowaną do kontekstu. Jeśli dana nazwa brzmi prawdopodobnie, model może ją zwrócić mimo braku rzeczywistego artefaktu.

Drugim elementem jest niebezpieczny wariant tzw. late binding. Agent AI najpierw generuje nazwę zasobu, a następnie narzędzie automatycznie próbuje go pobrać, zainstalować lub uruchomić. Jeśli walidacja następuje dopiero po pobraniu, napastnik ma wystarczająco dużo czasu, by przygotować złośliwy pakiet, repozytorium lub domenę.

Atak nie wymaga klasycznego przełamania zabezpieczeń modelu. Wystarczy, że model zwróci nazwę na tyle przewidywalną, aby można ją było wcześniej zarejestrować. Gdy takie halucynacje są powtarzalne dla podobnych promptów, przeciwnik może skalować działania i budować pułapki dla wielu narzędzi jednocześnie.

Szczególnie groźne są środowiska, w których agent ma uprawnienia do:

instalowania nowych zależności,
uruchamiania skryptów post-install,
modyfikowania repozytoriów,
dostępu do sekretów, tokenów i kluczy API,
inicjowania procesów CI/CD.

Dodatkowe ryzyko wynika z zależności przechodnich. Nawet jeśli główny pakiet wygląda wiarygodnie, złośliwy komponent może zostać ukryty kilka poziomów niżej w drzewie zależności, co utrudnia wykrycie i analizę incydentu.

Konsekwencje / ryzyko

Ryzyko związane z tym wzorcem ataku jest wysokie, ponieważ eliminuje on potrzebę klasycznej socjotechniki. Użytkownik nie musi kliknąć linku ani popełnić literówki. To sam system, kierowany wynikiem modelu, inicjuje kontakt ze złośliwym zasobem.

Dla organizacji oznacza to realne zagrożenie kompromitacją środowisk deweloperskich, buildów oraz całego łańcucha dostaw. Skutki mogą obejmować wdrożenie backdoora, kradzież tokenów dostępowych, eksfiltrację kodu źródłowego, skażenie artefaktów produkcyjnych i dalszą propagację ataku do klientów lub partnerów.

Najbardziej narażone są firmy, które wdrażają agentów AI z szerokimi uprawnieniami i zbyt dużym poziomem automatyzacji. Im mniej ręcznej kontroli nad pobieraniem i uruchamianiem nowych komponentów, tym większe prawdopodobieństwo skutecznego nadużycia.

Rekomendacje

Podstawową zasadą powinno być odejście od modelu, w którym agent AI może samodzielnie pobierać i wykonywać niezweryfikowane zasoby z publicznych rejestrów lub internetu. Weryfikacja musi następować przed pobraniem i przed wykonaniem, a nie dopiero po fakcie.

Ograniczyć uprawnienia agentów zgodnie z zasadą najmniejszych uprawnień.
Zablokować automatyczną instalację pakietów, rozszerzeń i repozytoriów spoza zatwierdzonej listy.
Korzystać z wewnętrznych mirrorów i zarządzanych repozytoriów zależności.
Weryfikować istnienie, reputację i integralność każdego nowego zasobu przed użyciem.
Objąć kontrolą również zależności przechodnie oraz skrypty instalacyjne.
Monitorować działania agentów i nietypowe próby pobierania nieznanych artefaktów.
Uruchamiać agentów kodujących w izolowanych środowiskach wykonawczych.
Wymuszać akceptację człowieka dla operacji wysokiego ryzyka, takich jak instalacja nowych zależności czy publikacja zmian.

Warto również zaktualizować modele zagrożeń dla AI-assisted development. Agent, który działa w imieniu użytkownika, powinien być traktowany jak uprzywilejowany operator automatyczny, a nie jedynie narzędzie pomocnicze do generowania tekstu.

Podsumowanie

HalluSquatting, slopsquatting i phantom squatting nie są trzema całkowicie odrębnymi technikami, lecz różnymi nazwami tego samego błędu projektowego: wykonywania działań na podstawie nazw wymyślonych przez model AI bez potwierdzenia ich autentyczności. To istotna zmiana w krajobrazie cyberzagrożeń, ponieważ punkt ataku przenosi się z użytkownika na warstwę automatyzacji.

Dla zespołów bezpieczeństwa kluczowy wniosek jest prosty: identyfikatory generowane przez AI nie mogą być traktowane jako zaufane, dopóki nie przejdą formalnej walidacji. W praktyce bezpieczeństwo łańcucha dostaw zaczyna się dziś już nie po pobraniu pakietu, lecz na etapie decyzji, co w ogóle wolno pobrać.