Jak wspomagany przez AI aktor zagrożenia włamał się do ponad 600 urządzeń FortiGate bez użycia exploita

Między 11 stycznia a 18 lutego 2026 r. rosyjskojęzyczny aktor motywowany finansowo przejął kontrolę nad ponad 600 urządzeniami FortiGate pełniącymi funkcję zapory ogniowej w ponad 55 krajach — i dokonał tego bez wykorzystania ani jednej luki w produkcie. Amazon Threat Intelligence, które opublikowało śledztwo 20 lutego 2026 r., podaje, że aktor znalazł interfejsy zarządzania wystawione do internetu na portach 443, 8443, 10443 i 4443 i dostał się do nich za pomocą często ponownie używanych haseł na kontach bez uwierzytelniania wieloskładnikowego. Pobrane konfiguracje urządzeń zawierały poświadczenia SSL-VPN z hasłami możliwymi do odzyskania, poświadczenia administratora, politykę zapory ogniowej i topologię sieci. Komercyjne duże modele językowe były wykorzystywane w ramach operacji, pisząc narzędzia do rekonesansu i opracowując plany ataku; według relacji niezależnego badacza, który znalazł własny serwer aktora, jeden z modeli był również skonfigurowany do uruchamiania poleceń ofensywnych. Ten incydent to jeden z wpisów w Orca AI Incident Archive, który zawiera pełny zapis, jego źródła i ocenę, obok sąsiednich przypadków z serii.

Co Amazon zgłosił i jak to odkrył

Raport „Aktor zagrożeń wspomagany przez AI uzyskuje dostęp do urządzeń FortiGate na dużą skalę” jest przypisywany CJ Mosesowi, CISO w Amazon Integrated Security, i został opublikowany na AWS Security Blog 20 lutego 2026 r. Jego pierwsze istotne ustalenie ma charakter negatywny: „Nie zaobserwowano wykorzystania luk w zabezpieczeniach FortiGate”. Początkowy dostęp przez cały czas opierał się na poświadczeniach — systematycznym skanowaniu interfejsów zarządzania na czterech powyższych portach, a następnie próbach uwierzytelnienia z użyciem często ponownie wykorzystywanych poświadczeń.

To, co uczyniło kampanię widoczną, to własne zabezpieczenia operacyjne aktora. Amazon twierdzi, że zidentyfikował infrastrukturę hostującą złośliwe narzędzia w ramach rutynowej pracy wywiadu zagrożeń oraz że ten sam serwer zawierał wygenerowane przez AI plany ataków, konfiguracje ofiar i kod źródłowy niestandardowych narzędzi, przechowywane bez szyfrowania. To zaniedbanie dało Amazonowi niemal pełny wgląd w metodykę. „To jak oparta na AI linia montażowa cyberprzestępczości” — czytamy w raporcie.

Skradzione pliki konfiguracyjne stanowią punkt wyjścia pozwalający przejść z urządzenia do sieci znajdującej się za nim. Według Amazon zawierają one dane uwierzytelniające użytkowników SSL-VPN wraz z hasłami możliwymi do odzyskania, dane uwierzytelniające administratorów, pełną topologię sieci i informacje o routingu, polityki zapory ujawniające wewnętrzną architekturę oraz konfiguracje peerów IPsec VPN. Napastnik napisał wspomagane przez AI skrypty w Pythonie, aby je sparsować, odszyfrować i uporządkować.

Post-eksploatacja, według samego Amazona

Po dostaniu się do środka aktor podążył standardową, dobrze udokumentowaną ścieżką. Jego dokumentacja operacyjna, napisana po rosyjsku, opisuje użycie Meterpreter z modułem mimikatz do przeprowadzania ataków DCSync przeciwko kontrolerom domeny i wyodrębniania skrótów haseł NTLM z Active Directory. W potwierdzonych kompromitacjach uzyskał kompletne bazy danych poświadczeń domeny. Amazon zauważa co najmniej jeden przypadek, w którym konto Administrator domeny używało hasła w postaci jawnej, które albo zostało ponownie użyte z konfiguracji FortiGate, albo było niezależnie słabe.

Stamtąd udokumentowane techniki to pass-the-hash i pass-the-ticket przeciwko dalszej infrastrukturze, relay NTLM z użyciem standardowych narzędzi do zatruwania oraz zdalne wykonanie poleceń na hostach Windows. Aktor szczególnie obrał za cel serwery Veeam Backup & Replication, wykorzystując skrypty PowerShell, skompilowane narzędzia deszyfrujące i próby wykorzystania znanych luk w Veeam — zachowanie, które Amazon opisuje jako „spójne z operacjami poprzedzającymi ransomware”, choć raport nie odnotowuje wdrożenia ransomware.

Notatki sprawcy odwołują się do kilku CVE, w tym CVE-2019-7192, CVE-2023-27532 i CVE-2024-40711. BleepingComputer, który opisał raport 21 lutego 2026 r., identyfikuje pierwszy z nich jako lukę w QNAP umożliwiającą zdalne wykonanie kodu, a dwa pozostałe jako problemy Veeam. Żaden z nich nie był drogą wejścia. Co bardziej wymowne, te same notatki odnotowują powtarzające się niepowodzenia: usługi już załatane, porty zamknięte, exploity, które nie miały zastosowania do docelowego systemu operacyjnego. W przypadku jednej potwierdzonej ofiary własna ocena sprawcy stwierdzała, że kluczowa infrastruktura była „dobrze chroniona” i nie miała „żadnych podatnych wektorów wykorzystania”.

Warto wyraźnie wskazać dwa ograniczenia dotyczące przypisania. Amazon twierdzi, że podmiot ten „nie jest znany jako powiązany z żadną zaawansowaną, trwałą grupą zagrożeń dysponującą zasobami sponsorowanymi przez państwo”, oraz że nie zaobserwowano, by infrastruktura AWS była zaangażowana w tę kampanię.

Gdzie tak naprawdę siedziała AI

Opis warstwy AI przedstawiony przez Amazon jest konkretny, jeśli chodzi o role, ale milczy na temat produktów. Według raportu podmiot korzystał z co najmniej dwóch różnych komercyjnych dostawców LLM: jednego jako głównego twórcy narzędzi, planisty ataków i asystenta operacyjnego, a drugiego jako dodatkowego planisty, gdy podmiot potrzebował pomocy w przemieszczaniu się wewnątrz określonej sieci. W jednym z zaobserwowanych przypadków podmiot przesłał pełną wewnętrzną topologię — adresy IP, nazwy hostów, potwierdzone dane uwierzytelniające i zidentyfikowane usługi — i poprosił o plan krok po kroku pozwalający dotrzeć do systemów, do których jego istniejące narzędzia nie miały dostępu.

Dowody Amazonu na to, że narzędzia zostały napisane przez maszynę, mają charakter stylistyczny, a nie forensyczny. Wymienia się w nich zbędne komentarze, które jedynie powtarzają nazwy funkcji, architekturę, która więcej inwestuje w formatowanie danych wyjściowych niż w działanie, JSON analizowany przez dopasowywanie ciągów znaków, a nie przez właściwą deserializację, oraz warstwy zgodności z pustymi zaślepkami dokumentacji. Narzędzia działały w wąskim przypadku aktora i zawodziły na brzegach. Jak zauważa Amazon, taki wolumen zwykle sugerowałby zespół deweloperski; tutaj pochodził od jednego aktora lub bardzo małej grupy.

Czego raport AWS nie zawiera, to żadnego dostawcy modeli, żadnej nazwy produktu ani żadnej wzmianki o Model Context Protocol. Te pojawiają się w drugim opracowaniu opublikowanym następnego dnia.

Serwer i nazwy, których Amazon nie opublikował

21 lutego 2026 r. blog bezpieczeństwa Cyber and Ramen opublikował własną analizę otwartego katalogu pod adresem 212.11.64[.]250:9999, hostowanego w AS4264 (Global-Data System IT Corporation, Zurich) — jednego z dwóch adresów, które Amazon wymienia jako infrastrukturę aktorów zagrożeń. Badacz naliczył 1402 pliki w 139 podkatalogach, w tym skradzione kopie zapasowe konfiguracji FortiGate, dane mapowania Active Directory, zrzuty poświadczeń, szablony skanowania Nuclei i narzędzia Veeam do wyodrębniania poświadczeń, a także dwa foldery nazwane na cześć Claude’a zawierające ponad 200 plików wyników zadań, różnic sesji i buforowanych stanów promptów.

W tej analizie wymieniono dwa niestandardowe komponenty. ARXON opisano jako serwer Model Context Protocol w Pythonie, który pozyskuje dane rozpoznawcze dla każdego celu, wywołuje DeepSeek w celu generowania planów ataku i prowadzi bazę wiedzy rosnącą wraz z każdym celem; zawiera także skrypty do masowego tworzenia kont FortiGate VPN przez SSH oraz weryfikacji poświadczeń Domain Admin. CHECKER2 to oparty na Go i Dockerze orkiestrator do równoległego skanowania VPN, a jego logi pokazują 2516 celów w 106 krajach. Badacz stwierdza, że nie udało się znaleźć żadnych publicznych odniesień do któregokolwiek z tych narzędzi, co wskazuje, że oba zostały zbudowane na potrzeby tej operacji.

Ta sama analiza opisuje ujawnienie w grudniu 2025 r. tego samego serwera, tym razem zawierającego kopię HexStrike — frameworka MCP do działań ofensywnych o otwartym kodzie źródłowym — oraz plik ustawień .claude, który wstępnie zatwierdził Claude Code do uruchamiania narzędzi Impacket, Metasploit i hashcat przeciwko wpisanym na stałe poświadczeniom domenowym należącym do pracownika dużej azjatyckiej firmy medialnej. Według badacza do lutego aktor przeszedł od tego punktu wyjścia opartego na otwartym kodzie źródłowym do ARXON i CHECKER2 — progresja zajmująca około ośmiu tygodni.

BleepingComputer przekazał te ustalenia w aktualizacji swojego artykułu z 21 lutego. To rozróżnienie ma znaczenie: ARXON, CHECKER2, DeepSeek i Claude Code to interpretacja badacza dotycząca plików, logów i ustawień w niezabezpieczonym katalogu. Amazon, który miał niezależny dostęp do tej samej infrastruktury, nie wskazał żadnego z nich. Żaden dostawca modeli nie potwierdził niczego z tego.

Co jest ustalone, a co opiera się na jednym źródle

Trzy twierdzenia opierają się na dwóch niezależnych stronach. Własny wpis blogowy Fortinetu z 6 marca 2026 r. „Attacks at the Speed of AI” stwierdza, że Fortinet „nie zaobserwował żadnego wykorzystania luk w FortiGate” oraz że kampania powiodła się dzięki wystawionym portom zarządzania i słabym poświadczeniom z jednoskładnikowym uwierzytelnianiem, przy użyciu password sprayingu. To potwierdza mechanizm Amazonu ze strony dostawcy, mimo że żadna ze stron nie widziała opublikowanych dowodów drugiej.

Sam Amazon jest źródłem danych o skali — ponad 600 urządzeń, ponad 55 krajów, okno od stycznia do lutego — oraz o profilu aktora: rosyjskojęzyczny, motywowany finansowo, o niskim do średniego poziomie podstaw technicznych, ze znacznym uzależnieniem od AI, płytkim zakresem działań po eksploitacji, nieodpowiednim bezpieczeństwem operacyjnym. Żadna strona trzecia nie przytoczyła liczby 600.

Wyłącznie Cyber and Ramen jest źródłem wymienionych narzędzi, dostawców modeli, liczb plików i 2 516 celów skanowania. Jego własne dokumenty dowodowe potwierdziły naruszenia bezpieczeństwa w firmie z branży gazów przemysłowych w regionie Azji i Pacyfiku, u dostawcy usług telekomunikacyjnych w Turcji oraz w firmie medialnej z grudniowego ujawnienia, a rekonesans odnosił się do Korei Południowej, Egiptu, Wietnamu i Kenii — potwierdzony zbiór ofiar w co najmniej pięciu krajach, znacznie mniej niż 55, na które powołuje się Amazon. Te dwie liczby mierzą różne rzeczy i żadnej z nich nie uzgodniono publicznie.

Odpowiedź Fortinetu i skala, której nie potwierdził

Wpis Fortinet autorstwa Carla Windsora, datowany na 6 marca 2026 r., zgadza się z Amazonem co do mechanizmu, ale różni się w kwestii skali. „Zgodnie z dochodzeniem i monitoringiem Fortinet, atak dotknął kilku klientów” – czytamy. „Jesteśmy w trakcie powiadamiania tych organizacji”. Nie potwierdza 600 urządzeń, nie przyjmuje liczby krajów podanej przez Amazon i nie wskazuje sprawcy.

Stanowisko Fortinet jest takie, że technika jest stara, a automatyzacja nowa: password spraying przeciwko słabo chronionym urządzeniom brzegowym, teraz napędzany rozmowami opartymi na podpowiedziach, niewymagającymi kodowania. Stwierdza, że atak „byłby niemożliwy przy włączonym MFA” i „wysoce nieprawdopodobne, aby się powiódł” przy włączonej polityce złożoności haseł. Opublikował również wskaźniki: dostęp administratora z 212[.]11.64[.]250 lub 185[.]196.11[.]225, tworzenie kont o nazwach fortiuser, fortinet-support lub fortinet-tech-support, nieoczekiwane konfiguracje VPN lub użytkownicy oraz skrypty zaplanowane do uruchamiania jako mechanizm utrzymania dostępu.

To rozbieżność co do zakresu, a nie spór o to, czy kampania miała miejsce. Nikt wymieniony w zapisie nie kwestionuje wtargnięcia; archiwum ocenia je na A, bez oznaczenia sporności, i odnotowuje rzeczywistą szkodę.

Co się potem zmieniło?

Nie ma CVE ani poprawki, ponieważ nie było luki. Remediacja polega na konfiguracji, a obie organizacje zbiegły się do tej samej listy. Amazon twierdzi, że udostępnił odpowiednim partnerom wskaźniki kompromitacji, współpracował z partnerami z branży i pomógł organizacjom podjąć kroki, które zmniejszyły skuteczność podmiotu atakującego; raport nie podaje liczby powiadomionych organizacji. Fortinet twierdzi, że bezpośrednio powiadamia dotkniętych klientów.

Wskazówki techniczne są spójne w obu przypadkach: odciąć dostęp administracyjny od interfejsów wystawionych na internet i zarządzać nim przez ścieżkę wewnętrzną lub pozapasmową; wymuszać MFA dla dostępu administracyjnego i VPN; stosować złożoność haseł; rotować poświadczenia SSL-VPN na każdym urządzeniu, którego interfejs zarządzania był lub mógł być osiągalny; przeprowadzać audyt ponownego użycia haseł między kontami VPN FortiGate a Active Directory; oraz odizolować infrastrukturę kopii zapasowych, łatać ją i przechowywać niezmienne kopie.

Jeśli chodzi o wykrywanie, Amazon wskazuje na aktywność DCSync (Event ID 4662 z GUID-ami związanymi z replikacją), nowe zadania zaplanowane o nazwach imitujących legalne usługi Windows, nietypowe połączenia zdalnego zarządzania z pul adresów VPN, artefakty zatruwania LLMNR i NBT-NS oraz nieautoryzowany dostęp do magazynów poświadczeń kopii zapasowych. Ostrzega również, że wykrywanie oparte na sygnaturach ma w tym przypadku ograniczoną wartość, ponieważ narzędzia są zbudowane z legalnych narzędzi open source — Impacket, gogo, Nuclei — które pojawiają się w zwykłych testach penetracyjnych.

Dlaczego ta płyta jest kamieniem milowym

Archiwum oznacza to jako przełomowy wpis, a powód jest widoczny w kontraście między tym, co podmiot osiągnął, a tym, co podmiot mógł zrobić. Pojedynczy operator lub bardzo mała grupa, oceniana na niski do średniego poziom umiejętności, prowadziła równoległe włamania w kilkudziesięciu krajach, wytworzyła zestaw narzędzi, który normalnie sugerowałby zespół programistów, oraz generowała plany ataków dla poszczególnych celów wystarczająco szybko, by utrzymać kilka włamań w ruchu jednocześnie.

Ten sam raport określa górny pułap. Aktor nie potrafił skompilować własnych exploitów, debugować nieudanych prób eksploatacji ani improwizować, gdy plan napotykał utwardzony cel — dlatego zamiast trwać, szedł dalej. Wygenerowany przez AI kod zawodził na skrajach. Jego notatki operacyjne to zapis załatanych usług i zamkniętych portów. To, co usunęły modele, to praca, a nie osąd: rekonesans, parsowanie, dokumentacja i planowanie zostały zautomatyzowane; części wymagające adaptacji pozostały poza zasięgiem.

To także dlatego otwarte pytania są przyziemne i konkretne. To, ile organizacji Fortinet faktycznie powiadomił, rozstrzygnęłoby różnicę między „kilkoma klientami” a ponad 600 urządzeniami. Druga analiza katalogu ARXON, niezależna od badacza, który go znalazł, rozstrzygnęłaby, czym było to narzędzie i jakie modele wywoływało. Do tego czasu zapis pozwala na stanowczy wniosek co do metody i znacznie słabszy co do skali.