Wprowadzenie do problemu / definicja luki
Amazon Threat Intelligence opisał kampanię, w której rosyjskojęzyczny aktor (najpewniej finansowy, a nie APT) uzyskał dostęp do ponad 600 urządzeń Fortinet FortiGate w 55 krajach w ciągu ok. pięciu tygodni. Kluczowe: nie wykorzystywano podatności FortiOS/0-day – powodzenie zapewniły wystawione do internetu interfejsy zarządzania oraz słabe hasła bez MFA, a generatywna AI miała przyspieszać i automatyzować kolejne kroki operacji.
W skrócie
- Okres aktywności: 11 stycznia – 18 lutego 2026.
- Skala: 600+ urządzeń, 55 krajów.
- Wejście: skanowanie i ataki na wystawione porty zarządzania oraz brute-force na popularnych hasłach, bez eksploita.
- Po przejęciu: wyciągnięcie konfiguracji (m.in. dane SSL-VPN, konta admin, polityki), rozpoznanie i pivot w sieci ofiary; wskazania, iż to może przygotowywać grunt pod ransomware.
- Rola AI: użycie komercyjnych narzędzi GenAI do planowania, generowania poleceń/skryptów i skalowania działań mimo ograniczonych umiejętności aktora.
Kontekst / historia / powiązania
To kolejny przykład trendu „AI jako akcelerator”: AI nie musi dawać atakującym nowych, magicznych technik – wystarczy, iż podnosi tempo i automatyzuje żmudne elementy (rozpoznanie, generowanie komend, modyfikacje skryptów, wariantowanie działań). Google GTIG w swoich raportach również opisuje coraz powszechniejsze użycie AI przez różne klasy aktorów w całym cyklu ataku (research, socjotechnika, malware/tooling).
W praktyce ta kampania uderza w najbardziej „przyziemny” problem: higiena dostępu do urządzeń brzegowych. o ile panel administracyjny jest dostępny z internetu, a do tego nie ma MFA i są słabe hasła, to organizacja sama redukuje koszt ataku do poziomu „sprytnej automatyzacji”.
Analiza techniczna / szczegóły kampanii
Na bazie opisu Amazona i relacji branżowych można odtworzyć typowy łańcuch działań:
(1) Odkrywanie celów (scanning)
- Aktor miał skanować internet pod kątem FortiGate/GUI management wystawionego na typowych portach 443, 8443, 10443, 4443.
(2) Uzyskanie dostępu (initial access)
- Zamiast 0-day: brute-force / password spraying na powszechnych hasłach oraz kontach chronionych wyłącznie hasłem (single-factor).
(3) Eksfiltracja konfiguracji i danych dostępowych
- Po zalogowaniu napastnik miał pobierać konfigurację, która zwykle zawiera m.in.:
- dane użytkowników SSL-VPN (w tym hasła możliwe do odzyskania/zrekonstruowania w zależności od konfiguracji),
- poświadczenia administracyjne,
- reguły firewall/NAT, architekturę sieci,
- konfiguracje IPsec VPN, routing/topologię.
(4) Rozpoznanie i pivot w sieci
- Amazon wskazuje, iż po uzyskaniu dostępu przez VPN aktor wdrażał własne narzędzia rozpoznawcze (wspominane są warianty w Go i Pythonie) i próbował poruszać się po sieci.
(5) „AI w pętli” (gdzie realnie pomaga GenAI)
- Raport sugeruje, iż AI była używana jako multiplikator produktywności: generowanie i poprawianie komend, tworzenie/ulepszanie prostych narzędzi, przyspieszenie planowania kolejnych kroków oraz automatyzacja działań na większej liczbie ofiar.
Praktyczne konsekwencje / ryzyko
Przejęcie FortiGate to nie tylko „kolejne urządzenie”. To często mapa drogowa do całej sieci:
- Ujawnienie topologii i polityk: atakujący widzi, które segmenty istnieją, jak jest realizowany dostęp, jakie są wyjątki w regułach.
- Poświadczenia VPN/administracyjne: ryzyko przejęcia sesji, kolejnych urządzeń, a także kont uprzywilejowanych (w zależności od tego, co zapisano w konfiguracji).
- Przygotowanie do ransomware: Bloomberg wskazuje, iż uzyskany dostęp był wykorzystywany do ruchu w głąb sieci w sposób wyglądający jak staging pod ataki ransomware/wymuszenia.
- Skala i tempo: 600 urządzeń w 5 tygodni pokazuje, iż przy słabej higienie uwierzytelniania granica między „średniakiem” a masową kampanią mocno się zaciera.
Rekomendacje operacyjne / co zrobić teraz
Poniżej checklista „minimum”, która adresuje dokładnie ten scenariusz (bez czekania na patche, bo tu nie chodzi o exploit):
Natychmiast (0–24h)
- Wyłącz zarządzanie z WAN (admin GUI/SSH) albo ogranicz je do allowlist IP (np. tylko VPN / bastion / ZTNA).
- Wymuś MFA na wszystkich kontach administracyjnych i wszędzie, gdzie to możliwe (również dla zdalnego dostępu).
- Zrób audit kont: usuń nieużywane, zmień domyślne nazwy/hasła, wprowadź polityki długości i złożoności oraz blokady po wielu próbach.
- Sprawdź, czy interfejsy zarządzania nie są wystawione na portach typowych dla GUI (w tym 8443/10443/4443).
Krótki termin (1–7 dni)
- Rotuj poświadczenia (admin, VPN, klucze PSK/IPsec, konta serwisowe) – zakładaj kompromitację, jeżeli panel był publicznie dostępny bez MFA.
- Przejrzyj logi (FortiGate + upstream SIEM): nietypowe logowania admin/VPN, skoki geolokacji, próby wielu haseł, nowe konta, zmiany polityk.
- Wdróż monitoring ekspozycji (external attack surface management) – urządzenia brzegowe potrafią „wypłynąć” przez zmiany w NAT/ISP.
Średni termin (1–4 tygodnie)
- Segmentuj zarządzanie: osobny VRF/VLAN, dostęp tylko przez VPN z MFA, PAM dla kont uprzywilejowanych.
- Wymuś standard „no public management” jako kontrolę bazową, z testami zgodności.
Różnice / porównania z innymi przypadkami
- Klasyczny schemat FortiGate w mediach: „0-day w FortiOS → masowa eksploatacja”.
- Ten przypadek: „brak eksploita → sukces przez ekspozycję panelu + słabe hasła + brak MFA”, a AI zwiększa przepustowość działań.
Wniosek: choćby jeżeli organizacja świetnie patchuje, ale zostawia zarządzanie na WAN bez MFA, to przez cały czas jest w strefie wysokiego ryzyka.
Podsumowanie / najważniejsze wnioski
- Kampania z 2026 r. pokazuje, iż AI nie musi tworzyć „nowych” technik, żeby realnie podnieść skuteczność ataku – wystarczy, iż skaluje wykorzystanie podstawowych błędów konfiguracyjnych.
- Największą dźwignią obrony jest „nudna baza”: brak zarządzania z internetu, MFA, higiena haseł, monitoring logowań.
- Jeżeli Twoje FortiGate miało publiczny panel administracyjny bez MFA w okresie 11.01–18.02.2026, potraktuj to jako sygnał do pilnego przeglądu ekspozycji i rotacji poświadczeń.
Źródła / bibliografia
- AWS Security Blog (Amazon Threat Intelligence), CJ Moses – opis kampanii i wnioski techniczne. (Amazon Web Services, Inc.)
- BleepingComputer – szczegóły dot. wektora wejścia i danych z konfiguracji. (BleepingComputer)
- Bloomberg – kontekst skali i interpretacja możliwego „stagingu” pod ransomware. (Bloomberg.com)
- Google Cloud Threat Intelligence (GTIG) – raport/aktualizacje o nadużyciach AI przez aktorów. (Google Cloud)
- Google Threat Intelligence – „Advances in Threat Actor Usage of AI Tools” (aktualizacja i tło trendu). (Google Cloud)
