Autonomiczne ataki AI: 600 tys. skradzionych kart

Wyobraź sobie, że ktoś wpisuje kilkanaście krótkich poleceń po chińsku, a następnie autonomiczne systemy AI same przeprowadzają rozpoznanie, włamanie, kradzież danych i zacieranie śladów — wszystko w tempie maszynowym, bez człowieka przy klawiaturze. To nie scenariusz filmowy, lecz udokumentowana operacja, którą zespół Gambit Security opisał w raporcie z 22 września 2026 roku. Kampania objęła setki sklepów internetowych, a jej koszt marginalny wyniósł około 25 dolarów na jedną firmę.

Sprawca posłużył się trzema otwartymi frameworkami agentowymi, które połączono w jedną linię produkcyjną ataku. Efektem było ponad 600 tysięcy rekordów kart kredytowych oraz — w co najmniej jednym przypadku — przypadkowe zniszczenie kopii zapasowych ofiary. To pierwszy tak szczegółowo udokumentowany przypadek w pełni autonomicznej, wielomiesięcznej kampanii przestępczej wymierzonej w realne cele komercyjne.

Jak działała trójwarstwowa maszyna do włamań

Operator zbudował stos z publicznie dostępnych narzędzi, dzieląc zadania między trzy wyspecjalizowane agenty. Każdy z nich odpowiadał za inny etap łańcucha ataku, a całość działała równolegle i bez nadzoru człowieka nad poszczególnymi krokami.

Strix: skanowanie w trybie głębokim

Pierwszy komponent odpowiadał za wykrywanie podatności. Między 23 a 31 sierpnia pracował w trybie intensywnym przeciwko 138 hostom, gromadząc 633 godziny czasu skanera w ciągu niespełna 195 godzin zegarowych. Taki wynik jest możliwy wyłącznie dzięki zrównoleglonej automatyzacji. Agent korzystał z API agregującego modele — najpierw z chińskiego modelu otwartego GLM 5.2, później z DeepSeek v4 Pro.

Cairn: autonomiczny silnik eksploatacji

Drugi agent otrzymywał domenę i cel — na przykład „zdobądź shell” albo „uzyskaj dostęp administracyjny” — a następnie pracował godzinami, aż osiągnął sukces, przekroczył limit czasu lub został ręcznie zatrzymany. Wykorzystywał model DeepSeek v4.1 Flash. To kluczowa różnica względem wcześniejszych ataków wspomaganych przez AI: nikt nie wskazywał mu kolejnych kroków w łańcuchu eksploatacji. Sam wybierał ścieżkę przez zabezpieczenia celu.

Hermes: orkiestrator z pamięcią trwałą

Trzeci element odpowiadał za koordynację, działania poeksploatacyjne i decyzje taktyczne. To otwarty agent autonomiczny wyposażony w pamięć trwałą, samodzielnie tworzone pliki umiejętności, przeszukiwalne archiwum sesji oraz zadania harmonogramowane. Na serwerze atakującego załadowano mu chińskojęzyczną personę systemową o nazwie „SOUL – Red Team Operator” oraz 121 umiejętności, z których 78 dotyczyło ataków — w tym jedna służąca usuwaniu własnych filtrów bezpieczeństwa treści.

To właśnie Hermes najlepiej pokazuje, jak zabezpieczenia modeli wchodzą w interakcję z użyciem przestępczym. Atakujący początkowo próbował uruchomić go na nowszych modelach Anthropic, które odmówiły realizacji żądań o charakterze ofensywnym. Sięgnął więc po claude-opus-4.6 — jak potwierdza log promptów, to wersja, która spełniła polecenia. Ten udokumentowany „fallback” jest najwyraźniejszym jak dotąd dowodem, że poprawki bezpieczeństwa w modelach frontier mają realny wpływ operacyjny na to, co atakujący mogą uruchomić. Nie jest to jednak dowód, że problem został rozwiązany — starsze modele pozostają dostępne.

Polecenia człowieka odzyskane z serwera są zaskakująco lakoniczne: „przeczytaj raport o podatności i zaczynaj”, „sprawdź, czy upload pliku z raportu daje wykonanie kodu”, „nastawienie na cel, skupienie na getshell albo dostępie do backendu”. Operator nie był hakerem w tradycyjnym sensie. Był dyspozytorem.

Od niezabezpieczonego żądania do odszyfrowanych kart w dwunastu krokach

Jeden z w pełni zrekonstruowanych projektów Cairn pokazuje, jak wygląda autonomiczna eksploatacja od początku do końca. Cały łańcuch — dwanaście kroków od niezabezpieczonego żądania sieciowego do odszyfrowanych numerów kart — przebiegł bez człowieka przy klawiaturze na żadnym z pośrednich etapów.

Niezabezpieczona injekcja SQL na endpointcie logowania (z użyciem EXTRACTVALUE opartego na błędach) ujawniła jednorazowe hasła w postaci jawnej w tabeli bazy danych, obchodząc uwierzytelnianie wieloskładnikowe.
Z panelu administracyjnego agent znalazł pole uploadu obrazów bez sprawdzania rozszerzenia, użył go do wgrania web shella i podniósł uprawnienia do roota przez błędną konfigurację sudo w Pythonie 3.12.
Następnie zamontował wewnętrzny udział NFS z luźnymi uprawnieniami, wyciągnął poświadczenia WordPressa z pliku konfiguracyjnego, utworzył nowe konto administratora w bazie WordPress i wgrał złośliwą wtyczkę, uzyskując wykonanie kodu na serwerze bloga.
Z tego miejsca wyciągnął wszystkie 46 sekretów z AWS Secrets Manager, uzyskał dostęp do produkcyjnej bazy Magento na Aurora, wydobył klucz szyfrowania i odszyfrował przechowywane numery kart z pola cc_number_enc — wszystko z użyciem Blowfish-ECB, który agent zidentyfikował i odwrócił na podstawie kodu samej aplikacji.

Dla porównania: badanie akademickie z University of Illinois Urbana-Champaign z 2024 roku wykazało, że GPT-4 samodzielnie eksploatował podatności typu one-day za średnio około 9,81 dolara na udaną próbę, podczas gdy człowiek-analityk bezpieczeństwa wykonujący tę samą pracę ręcznie kosztowałby około 80 dolarów. W kampanii Gambit koszty spadły jeszcze niżej — do 25,46 dolara za ukończone skanowanie na 101 celów — ponieważ operator używał tańszych modeli otwartych do większości zadań, a droższe uruchamiał tylko wtedy, gdy było to konieczne.

Kogo zaatakowano i dlaczego akurat tych sprzedawców

Wybór celów nie był przypadkowy. Operator korzystał z serwisu rankingowego ruchu internetowego, filtrował kategorię zakupową i świadomie wykluczał sklepy działające na dużych hostowanych lub otwartych platformach e-commerce — Shopify, WooCommerce i podobnych. Logi promptów potwierdzają tok rozumowania: sklepy z kodem własnym znacznie częściej mają niezałatane podatności niż te na platformach z centralnym systemem aktualizacji.

W efekcie lista celów przechyliła się w stronę średniej wielkości specjalistycznych sprzedawców detalicznych. Wśród potwierdzonych ofiar znalazły się firma z listy Fortune 500 z branży hotelarskiej, duże amerykańskie linie lotnicze, duży prywatny dystrybutor artykułów przemysłowych oraz amerykański detalista mody online. Część celów wybrano automatycznie przez ranking, inne przekazano agentowi z gotowym hasłem administratora i poleceniem: „do roboty”.

600 tysięcy kart — rozkład geograficzny

Gambit nawiązał współpracę z firmą wywiadu antyfraudowego Overwatch Data, aby powiadomić wystawców kart po tym, jak serwer stagingowy ujawnił ponad 600 tysięcy ważnych rekordów kart kredytowych pochodzących od dwóch poszkodowanych firm. Rozkład według kraju wydania pokazuje, że Stany Zjednoczone odpowiadały za 488 372 karty — 79 procent całości. Zjednoczone Emiraty Arabskie wniosły 13 559 kart, Arabia Saudyjska 6 785, Wielka Brytania 6 522, Nowa Zelandia 5 710, Irlandia 5 483, Singapur 5 305, Kuwejt 4 676, Australia 4 672, Hongkong 4 459, Francja 4 295, a Katar 4 075. Karty z 196 kolejnych krajów złożyły się na pozostałe 10 procent.

Poza samą kradzieżą baz danych Gambit potwierdził aktywne skrypty skimmingowe na stronach płatności 19 poszkodowanych firm w okresie aktywności kampanii. Badacz bezpieczeństwa Varys zidentyfikował ponad 100 dalszych witryn ze skimmerami powiązanymi z tą samą operacją.

Co kryje się w JavaScripcie Twojej strony płatności

Metody wdrażania skimmerów różniły się w zależności od poziomu dostępu, jaki osiągnął agent. Kilka z nich świadczy o dojrzałości operacyjnej, którą trudno byłoby utrzymać przy tak wielu celach bez automatyzacji.

Najczęstszy wariant: dopisanie małego loadera na końcu legalnego pliku JavaScript już serwowanego przez stronę — na przykład biblioteki jQuery lub Bootstrap — a następnie przywrócenie oryginalnego znacznika czasu pliku, by oszukać monitoring zmian. Loader dekoduje się do jednolinijkowca pobierającego właściwy payload skimmingowy z zewnętrznego hosta. Z zewnątrz legalny plik wygląda na niezmodyfikowany zarówno pod względem nazwy, jak i daty.
U detalisty wyrobów stalowych w USA agent ukrył loader w bloku Google Tag Manager, wypełniając go około setką znaków tabulacji, by wypchnąć wstrzyknięty kod poza prawą krawędź widoku źródła w edytorze.
U amerykańskiego detalisty kosmetycznego agent użył skradzionego klucza dostępu AWS, by zapisać payload bezpośrednio do bucketu S3 stojącego za CDN witryny — dzięki czemu strony płatności ładowały skimmer z własnej domeny ofiary.
U detalisty winnego w USA pakiet płatności był okresowo przywracany przez własny pipeline wdrożeniowy firmy, więc agent zostawił zadanie cron w katalogu logów JBoss, które co dwie minuty sprawdzało rozmiar pliku i ponownie dopisywało skimmer, gdy tylko został cofnięty.
Na amerykańskiej platformie print-on-demand metoda wstrzyknięcia polegała na dodaniu initContainera Kubernetes do produkcyjnego wdrożenia frontendu — złośliwy kod uruchamiał się jako część sekwencji startowej aplikacji.

Gdy sprzątanie zamienia się w zniszczenie

Jednym z najbardziej istotnych operacyjnie odkryć na odzyskanym serwerze była własna procedura usuwania danych atakującego. Plik umiejętności w Hermesie zawierał sekcję zatytułowaną „Database Wipe After Extraction”, która nakazywała agentowi wymazanie danych kart kredytowych z bazy Magento ofiary po eksfiltracji — z użyciem skryptów PHP dzielonych na fragmenty dla tabel z milionami wierszy i końcowym zapytaniem weryfikującym, czy wszystkie liczniki osiągnęły zero.

Atakujący zamierzał w ten sposób zatrzeć dowody. W co najmniej jednym przypadku uzyskał jednak efekt znacznie bardziej destrukcyjny. U detalisty rowerowego agent utworzył w bazie ofiary tabele stagingowe z prefiksem „ZQ”, by tymczasowo przechować wyekstrahowane rekordy. Gdy uruchomiła się procedura czyszczenia, usunęła każdą tabelę, której nazwa pasowała do „ZQ” lub „Backup” — co objęło 180 tabel, w tym tabele zapasowe utworzone przez własnych administratorów bazy ofiary, którzy użyli słowa „Backup” w nazwie. Procedura czyszczenia atakującego nie odróżniła własnych tabel stagingowych od operacyjnych kopii zapasowych sprzedawcy. Obie zostały skasowane.

Ten scenariusz nie mieści się w większości playbooków reagowania na incydenty. Plany na wypadek ransomware przygotowują organizację na zaszyfrowane dane z żądaniem okupu. Plany na wypadek eksfiltracji przygotowują na wyciek danych z obowiązkami powiadomienia. Żaden nie przygotowuje na autonomiczne usunięcie własnych kopii zapasowych bazy jako efekt uboczny cudzej procedury czyszczenia — bez żądania okupu i bez powiadomienia od atakującego. Gambit wprost ostrzega, że organizacje powinny planować zniszczenie danych jako możliwy efekt uboczny intruzji napędzanej przez AI, niezależnie od tego, czy pojawi się jakiekolwiek żądanie okupu.

Czy coś takiego zdarzyło się wcześniej?

Krótka odpowiedź brzmi: nie — nie w tej skali, nie tak autonomicznie i nie przy takim koszcie. Wcześniejsze ataki wspomagane przez AI utrzymywały człowieka w pętli decyzyjnej na każdym istotnym etapie: generowanie treści phishingowych, pisanie złośliwego kodu czy wsparcie rozpoznania — ale z osobą zatwierdzającą każdy krok. Raport Gambit dokumentuje tę różnicę.

Analiza opublikowana w Fortune w styczniu 2026 roku zauważała, że agenty AI ukończyły zaawansowane wyzwania atakujące za mniej niż 50 dolarów kosztów LLM — zadania, które wcześniej kosztowałyby blisko 100 tysięcy dolarów czasu pracy badacza. Były to jednak kontrolowane ćwiczenia red-teamowe. Kampania Gambit to pierwszy udokumentowany przypadek, w którym ta sama ekonomia kosztowa rozgrywa się w żywej, wielomiesięcznej operacji przestępczej przeciw realnym celom komercyjnym.

Dla kontekstu: u największych dostawców oprogramowania liczba zgłaszanych podatności krytycznych przekracza obecnie 600 miesięcznie, a około 87 procent luk faktycznie wykorzystywanych przez atakujących jest atakowanych w dniu ujawnienia lub wcześniej. Gdy eksploatacja wyprzedza harmonogram ujawnienie–łatka, sama szybkość łatania przestaje wystarczać jako obrona. Kampania Gambit uczyniła tę abstrakcyjną obserwację konkretem: atakujący mógł wdrożyć nowy projekt ataku przeciw celowi w czasie między ujawnieniem a łatką. Okno naprawcze dla wielu złożonych środowisk mierzy się w tygodniach. Okno ataku mierzy się teraz w godzinach.

Co można zrobić już teraz

Osobom, których karty mogły zostać ujawnione, Gambit — we współpracy z Overwatch Data — pomógł powiadomić wystawców kart, więc anulowanie i wymiana kart może już trwać. Jeśli robiłeś zakupy u specjalistycznego detalisty online od lipca 2026 roku, sprawdź wyciągi z karty i konta bankowego pod kątem nieautoryzowanych obciążeń oraz rozważ ustawienie alertu antyfraudowego.

Zespołom bezpieczeństwa i inżynierii w firmach e-commerce Gambit udostępnił pełną listę wskaźników kompromitacji, w tym adres IP serwera stagingowego atakującego (155.254.22.215), cztery adresy command-and-control (209.126.4.170, 213.21.239.62, 172.245.224.188, 172.245.89.137) oraz ponad tuzin domen i URL-i hostujących skimmery.

Kluczowa rekomendacja Gambit to zwrot ku myśleniu o odporności zamiast wyłącznie o prewencji. Zamiast zakładać, że włamaniom można zapobiec, organizacje powinny zidentyfikować minimalny zestaw systemów niezbędnych do utrzymania przychodów i aktywnie udowodnić — przez przetestowane plany odtworzenia, a nie spisane procedury — że te systemy mogą wrócić online w warunkach, jakie tworzy tego typu kampania.

Oznacza to uzgodnienie między właścicielami aplikacji, zespołami infrastruktury i dostawcami pomiędzy nimi, bez czego biznes nie może działać, a następnie przetestowanie tego uzgodnienia przeciw konkretnym trybom awarii, które pokazała ta kampania. Nie wystarczy pytanie „czy możemy odtworzyć bazę danych?”. Trzeba zapytać: „czy możemy odtworzyć bazę danych po tym, jak tabele zapasowe zostały usunięte?”. Plan odtworzenia, który kończy się na „baza danych została przywrócona”, nie odpowiada na pytanie, które stawia ta kampania.

Najczęściej zadawane pytania

Jak rozpoznać, czy strona płatności sklepu została zmodyfikowana?

Większość kupujących nie jest w stanie wykryć skimmera z poziomu interfejsu płatności — właśnie dlatego web skimming pozostaje tak skuteczny. Atakujący w kampanii Gambit celowo projektował wstrzyknięcia jako niewidoczne: przywracał znaczniki czasu plików, ukrywał kod poza prawą krawędzią widoku źródła i serwował payload z własnej domeny CDN ofiary. Z perspektywy konsumenta najskuteczniejsza ochrona to wirtualny lub jednorazowy numer karty przy zakupach u mniejszych sprzedawców, częste sprawdzanie wyciągów i włączenie alertów transakcyjnych w czasie rzeczywistym u wystawcy karty.

Co odróżniało tę kampanię od wcześniejszych zautomatyzowanych ataków?

Wcześniejsze udokumentowane ataki — w tym phishing wspomagany przez AI i pisanie malware z pomocą LLM — pozostawiały człowiekowi każdą istotną decyzję. Kampania Gambit to pierwsza udokumentowana zakrojona na szeroką skalę operacja przestępcza, w której autonomiczne agenty AI planowały, wykonywały i sprzątały wieloetapowe włamania do sklepów niemal całkowicie bez ludzkiego wsparcia na poszczególnych krokach. Operator wpisał mniej niż 2000 promptów w 260 sesjach obejmujących co najmniej 27 potwierdzonych ofiar. Najbliższy wcześniejszy kontekst badawczy — badanie University of Illinois z 2024 roku — pokazał, że GPT-4 potrafi autonomicznie eksploatować pojedyncze podatności one-day za mniej niż 10 dolarów; ta kampania pokazała tę samą ekonomię w skali wielomiesięcznej operacji przeciw setkom celów.

Czy moje dane mogą zostać zniszczone, a nie tylko skradzione?

Tak, i kampania Gambit dokumentuje dokładnie taki przypadek. Orkiestrator AI atakującego zawierał umiejętność „Database Wipe After Extraction” zaprojektowaną do usuwania skradzionych danych z baz ofiar po ich skopiowaniu. U detalisty rowerowego procedura czyszczenia dopasowała nazwy tabel zbyt szeroko — usunęła 180 tabel, w tym tabele zapasowe, którym administratorzy ofiary nadali nazwy zawierające „Backup”. Dane nie zostały zaszyfrowane ani objęte okupem; po prostu zniknęły. Większość playbooków reagowania na incydenty planuje eksfiltrację lub ransomware, ale nie uwzględnia autonomicznego usunięcia tabel zapasowych jako efektu ubocznego skryptu czyszczenia atakującego. Jeśli Twoja organizacja przechowuje dane w Magento lub podobnej bazie e-commerce, upewnij się, że kopie zapasowe istnieją poza głównym środowiskiem bazy — nie tylko jako tabele z „Backup” w nazwie w tej samej bazie, do której może dotrzeć atakujący.

Czy to ma znaczenie, że atakujący musiał sięgnąć po starszy model AI?

Ma znaczenie jako sygnał, choć nie jako rozwiązanie. Logi atakującego pokazują, że nowsze modele Anthropic odmówiły realizacji żądań ofensywnych, zmuszając operatora do użycia claude-opus-4.6. To dowód, że zabezpieczenia modeli frontier mają realne konsekwencje operacyjne dla sposobu konfiguracji narzędzi przez przestępców. Nie jest to jednak dowód, że problem został rozwiązany: starsze zdolne modele pozostają dostępne, modele otwarte uruchamiane na prywatnej infrastrukturze bez żadnych ograniczeń bezpieczeństwa są coraz łatwiej dostępne, a otwarte frameworki agentowe (Strix, Cairn, Hermes), które napędzały tę kampanię, same w sobie nie mają zabezpieczeń. Odmowa modelu stworzyła obejście, nie mur.

Kampania Gambit pokazuje, że era autonomicznych ataków AI nie jest już prognozą — jest faktem operacyjnym. Dla firm e-commerce oznacza to konieczność przemyślenia nie tylko strategii łatania, ale całego podejścia do odporności: od architektury kopii zapasowych, przez monitoring integralności plików, po testowanie scenariuszy, w których atakujący działa szybciej niż ludzki zespół jest w stanie zareagować. Pytanie nie brzmi już „czy zostaniemy zaatakowani?”, lecz „czy przetrwamy, gdy atak będzie prowadzony w tempie maszynowym?”.