Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
FortiBleed to nazwa rozległej kampanii wymierzonej w urządzenia FortiGate wystawione do internetu. Jej celem było nie tylko uzyskanie dostępu do samych zapór sieciowych, ale również przechwytywanie danych uwierzytelniających, budowanie trwałej obecności w środowiskach ofiar oraz dalsza monetyzacja zdobytego dostępu.
To zagrożenie pokazuje, że nowoczesne operacje przeciwko infrastrukturze brzegowej nie muszą opierać się wyłącznie na pojedynczej luce. W praktyce równie skuteczne okazuje się połączenie masowego skanowania, credential stuffingu, ataków słownikowych i wykorzystania natywnych funkcji systemowych do monitorowania ruchu.
W skrócie
- Kampania była aktywna od lutego 2026 roku i objęła setki tysięcy urządzeń FortiGate.
- Atakujący mieli zidentyfikować ponad 110 mln poświadczeń, w tym dane RADIUS, hashe NTLM i Kerberos oraz tokeny uwierzytelniające.
- Szczególnie narażone były małe i średnie firmy oraz dostawcy usług IT.
- Kluczowym elementem operacji było pasywne przechwytywanie ruchu uwierzytelniającego na skompromitowanych urządzeniach.
- Charakter kampanii wskazuje na dojrzały model działania brokera początkowego dostępu.
Kontekst / historia
W ostatnich latach urządzenia perymetryczne, takie jak firewalle, bramy SSL-VPN, koncentratory zdalnego dostępu czy systemy NAS, stały się jednym z głównych celów grup nastawionych na uzyskanie dostępu początkowego. Wynika to z ich roli w infrastrukturze: obsługują ruch z internetu, pośredniczą w logowaniu użytkowników i często mają wysoki poziom zaufania w środowisku organizacji.
FortiBleed wpisuje się w ten trend, ale wyróżnia się skalą oraz poziomem automatyzacji. Z dostępnych ustaleń wynika, że operatorzy interesowali się nie tylko samymi urządzeniami FortiGate, lecz także innymi usługami wystawionymi publicznie, takimi jak portale RDWeb, serwery baz danych czy rozwiązania zdalnego dostępu. Sugeruje to szerszy model operacyjny, w którym FortiGate był jednym z wielu punktów wejścia do środowisk firmowych.
Analiza techniczna
Pierwszym etapem kampanii był rekonesans na dużą skalę. Atakujący identyfikowali urządzenia dostępne z internetu, klasyfikowali je według typu usługi i lokalizacji, a następnie budowali listy celów przeznaczonych do dalszej eksploatacji.
Następnie prowadzono próby logowania do paneli administracyjnych oraz portali SSL-VPN. W tym celu wykorzystywano credential stuffing, ataki słownikowe i automatyczne sprawdzanie par login-hasło. Jeśli dostęp został uzyskany, operatorzy wdrażali kolejne narzędzia umożliwiające dalsze działania w środowisku ofiary.
Najbardziej charakterystycznym elementem kampanii było użycie niestandardowego sniffera określanego jako FortigateSniffer, napisanego w języku Go. Narzędzie miało wykorzystywać natywne funkcje diagnostyczne FortiOS do pasywnego przechwytywania ruchu przechodzącego przez skompromitowane urządzenie. To istotna różnica względem klasycznego malware, ponieważ mechanizm opierał się na funkcjach systemowych, a nie na modyfikacji stosu sieciowego czy instalacji dodatkowego sterownika.
Sniffer analizował ruch uwierzytelniający dla wielu protokołów, w tym Kerberos, LDAP, SMB, RDP, WinRM, FTP, SMTP, Telnet, MS-SQL, MySQL, PostgreSQL oraz RADIUS. Dzięki temu atakujący mogli pozyskiwać zarówno dane przesyłane jawnym tekstem, jak i hashe czy tokeny uwierzytelniające. Przechwycone informacje były następnie walidowane, łamane w infrastrukturze do crackingu haseł i ponownie wykorzystywane do logowania do innych systemów.
W dalszej fazie przejęte poświadczenia służyły do enumeracji domen Active Directory, uzyskiwania dostępu do udziałów sieciowych, poruszania się bocznego w sieci oraz utrzymywania trwałości. Dodatkowym elementem mogło być wykorzystywanie skradzionych ciasteczek sesyjnych, co pozwalało utrzymywać uwierzytelnione sesje bez ponownego podawania hasła.
Na uwagę zasługuje również sposób organizacji infrastruktury. Według opisów kampania działała w powtarzalnych cyklach, z mechanizmami geofencingu i ograniczeniami czasowymi odpowiadającymi godzinom aktywności operatorów. To wskazuje na wysoki poziom dojrzałości operacyjnej i dużą skalę automatyzacji.
Konsekwencje / ryzyko
Ryzyko związane z FortiBleed jest wielowarstwowe. Bezpośrednim skutkiem może być przejęcie kontroli nad urządzeniem FortiGate, czyli strategicznym punktem kontrolnym całej infrastruktury sieciowej. Pośrednio oznacza to jednak znacznie więcej, ponieważ firewall może stać się źródłem poświadczeń do systemów wewnętrznych, usług katalogowych, serwerów baz danych i platform zdalnego dostępu.
Szczególnie groźne jest pasywne przechwytywanie ruchu uwierzytelniającego na urządzeniu, przez które przechodzi duża część komunikacji organizacji. W takim scenariuszu urządzenie perymetryczne przestaje być wyłącznie celem ataku i staje się platformą do systematycznego zbierania danych uwierzytelniających z wielu systemów jednocześnie.
Znaczenie ma również profil ofiar. Ukierunkowanie na małe i średnie przedsiębiorstwa oraz firmy świadczące usługi IT podnosi ryzyko kompromitacji łańcuchowej. Przejęcie dostępu do dostawcy usług może bowiem otworzyć drogę do środowisk jego klientów, co zwiększa operacyjną wartość pojedynczego incydentu.
Rekomendacje
Organizacje korzystające z FortiGate powinny rozpocząć od przeglądu ekspozycji urządzeń dostępnych z internetu. Interfejsy administracyjne należy ograniczyć wyłącznie do zaufanych adresów IP, a tam, gdzie to możliwe, całkowicie odseparować je od publicznej sieci.
Konieczne jest wdrożenie silnego uwierzytelniania wieloskładnikowego dla dostępu administracyjnego i zdalnego. Równolegle należy wymusić stosowanie unikalnych, długich haseł oraz wyeliminować współdzielone konta administracyjne.
Ważnym elementem obrony jest monitorowanie logów pod kątem nietypowych prób logowania, zwiększonej liczby błędnych uwierzytelnień, niestandardowych sesji SSH oraz użycia poleceń diagnostycznych, które nie wynikają z rutynowej administracji. W środowiskach podwyższonego ryzyka warto dodatkowo monitorować uruchamianie funkcji sniffingu i zmiany konfiguracyjne na urządzeniach brzegowych.
Z perspektywy reagowania na incydent należy zakładać, że kompromitacja firewalla mogła doprowadzić do wycieku poświadczeń do innych systemów. W praktyce oznacza to potrzebę szerszego dochodzenia i działań naprawczych.
- Przeprowadzenie rotacji haseł i resetu sekretów usługowych.
- Weryfikację kont uprzywilejowanych oraz logowań do Active Directory.
- Analizę dostępu do udziałów sieciowych, usług RDP, VPN i baz danych.
- Przegląd zmian konfiguracyjnych i aktywności administracyjnej na urządzeniach FortiGate.
- Regularne aktualizowanie FortiOS i śledzenie komunikatów bezpieczeństwa producenta.
Dobrą praktyką pozostaje również segmentacja sieci i ograniczenie zaufania do urządzeń brzegowych. Im mniejszy zakres ich uprawnień i widoczności w środowisku, tym mniejsze skutki potencjalnej kompromitacji.
Podsumowanie
FortiBleed to przykład kampanii, która pokazuje zmianę sposobu atakowania infrastruktury brzegowej. Zamiast opierać się wyłącznie na krytycznej luce, operatorzy połączyli masowe skanowanie, ponowne użycie poświadczeń, automatyzację i wykorzystanie natywnych funkcji systemowych do przechwytywania ruchu.
Dla zespołów bezpieczeństwa oznacza to konieczność patrzenia na ochronę FortiGate szerzej niż tylko przez pryzmat podatności. Równie ważne są higiena haseł, kontrola dostępu, telemetria, monitorowanie działań administracyjnych oraz zdolność do szybkiego wykrywania nadużyć na urządzeniach perymetrycznych.
Źródła
- https://thehackernews.com/2026/06/fortibleed-targeted-fortigate-firewalls.html
- https://socradar.io/
- https://spycloud.com/
- https://www.fortiguard.com/psirt