FortiBleed: w nazwie jest „bleed”, ale nie ma żadnego exploita. 86 tysięcy firewalli przejętych hasłami, których nikt nie zmienił po poprzednich włamaniach.

SOCRadar wykrył operacyjny serwer grupy, która po cichu, na masową skalę, włamywała się do firewalli i bramek VPN Fortinet. To, co znaleźli, to nie była lista zgadywanych haseł. To była baza ponad 86 644 zweryfikowanych, działających poświadczeń logowania do urządzeń firm i instytucji rządowych w 194 krajach — przetestowanych i potwierdzonych przez samych atakujących za pomocą zautomatyzowanych narzędzi działających całą dobę. Hudson Rock, który niezależnie analizował dane, nazwał kampanię FortiBleed. Wśród ofiar: banki, szpitale, operatorzy telekomunikacyjni, uczelnie, agencje rządowe, firmy energetyczne i międzynarodowe korporacje.

Ale najważniejsze w tej historii jest to, czego w niej nie ma. Jak ujął to jeden z analityków: najbardziej uderzające w FortiBleed jest to, czego brakuje. Nie ma zero-daya, nie ma exploita, nie ma żadnego „bleeda". Mimo nazwy, to nie jest podatność — to stos poświadczeń wyciekłych we wcześniejszych włamaniach do Fortinet, wystrzelony z powrotem w organizacje, które nigdy ich nie zmieniły.

To jest historia, która zamyka całą naszą serię o Fortinet zupełnie innym akordem, niż się spodziewaliśmy.

Nie luka. Recykling cudzych wpadek.

Przez ostatnie tygodnie opisywaliśmy Fortinet jako pasmo podatności: FortiClient EMS z fałszywą łatką, trzy eksploatowane luki w FortiSandbox. FortiBleed jest inny — i dlatego ważny. Tu nie ma czego łatać.

SOCRadar podkreślił wprost: nie znaleźli żadnego dowodu na wykorzystanie luk Fortinet w tej operacji i traktują ją wyłącznie jako kampanię kompromitacji poświadczeń. Sam Fortinet potwierdza tę interpretację — twierdzi, że aktywność wydaje się związana ze zgadywaniem haseł i ponownym użyciem poświadczeń z wcześniejszych incydentów, i nie jest powiązana z żadną nową podatnością ani świeżym błędem produktu.

Mechanizm jest dwuetapowy i brutalnie prosty. Najpierw atakujący wystrzeliwują listę wcześniej wyciekłych haseł Fortinet przeciwko urządzeniom w całym internecie — a wiele organizacji nigdy nie zmieniło haseł po wcześniejszych włamaniach. Potem, gdy już są w środku urządzenia, pasywnie monitorują ruch sieciowy, zbierając kolejne poświadczenia, które przez nie przepływają. Te są następnie używane do kompromitacji kolejnych urządzeń.

To znaczy: cała ta operacja, dotykająca 194 krajów i każdego sektora gospodarki, jest zbudowana nie na geniuszu technicznym atakujących, ale na bezczynności obrońców. Hasła wyciekły wcześniej. Wystarczyło je zmienić. Nie zmieniono.

Urządzenie jako podsłuch — drugi etap, który czyni to samonapędzającym

Druga faza zasługuje na uwagę, bo zamienia jednorazową kradzież w samonapędzającą się maszynę.

Gdy urządzenie zostaje skompromitowane, atakujący używają go jako punktu nasłuchowego — monitorują ruch przez nie przechodzący i zbierają wszelkie dodatkowe poświadczenia, które przepływają. Firewall albo brama VPN to z definicji punkt, przez który przechodzi uwierzytelniony ruch całej organizacji. Atakujący, który go przejmie, nie tylko zyskuje dostęp — zyskuje stanowisko obserwacyjne, z którego zbiera kolejne hasła, by włamać się głębiej i szerzej.

To jest ten sam wzorzec, który opisywaliśmy przy PAN-OS i przy całej serii urządzeń brzegowych: urządzenie na granicy sieci jest jednocześnie pierwszą linią obrony i najgorzej monitorowanym elementem infrastruktury. Tutaj dochodzi dodatkowy wymiar — przejęte urządzenie nie jest celem końcowym, jest narzędziem do zbierania poświadczeń, które napędzają następną rundę ataku. Stąd liczby rosną w czasie rzeczywistym: SOCRadar zaczął od ponad 30 tysięcy, a w kolejnych aktualizacjach doszedł do 86 644 — bo kampania wciąż trwa i sama się karmi.

Domyślne konta — szczegół, który mówi wszystko o przyczynie

Jest w danych SOCRadar jeden szczegół, który jest diagnozą całego problemu.

Generyczne konta administracyjne i wbudowane konta systemowe Fortinet razem stanowią większość skompromitowanych poświadczeń. To wskazuje wprost na powszechne zaniechanie zmiany nazw domyślnych kont lub rotacji fabrycznych poświadczeń — co dało atakującemu wysoce niezawodną listę celów, zanim jeszcze zaczął jakikolwiek brute-force.

Innymi słowy: znaczna część tych 86 tysięcy urządzeń padła nie dlatego, że ktoś złamał silne hasło, ale dlatego, że hasło nigdy nie zostało zmienione z fabrycznego albo z tego, które wyciekło lata temu. Obecność kont specyficznych dla organizacji na szczycie listy jest jeszcze bardziej znacząca — oznacza, że atakujący nie zbiera tylko domyślnych poświadczeń, ale skutecznie skompromitował też konta tworzone przez same organizacje, prawdopodobnie pochodzące z wcześniejszych włamań, gdzie haseł nigdy nie zmieniono.

Skanowanie objęło nie tylko domyślny port. SOCRadar zauważył, że obok portu 443 (standardowy HTTPS i domyślny dla interfejsów SSL VPN Fortinet) atakujący przeczesywali też porty niestandardowe — 4443, 8443, 10443 — co pokazuje, że skaner był skonfigurowany do omiatania wszystkich popularnych wariantów wdrożeń Fortinet, nie tylko instalacji domyślnych. To jest poziom systematyczności operacji nastawionej na kompletność, nie na łatwe cele.

Dlaczego to jest gorsza wiadomość niż zero-day — i jednocześnie lepsza

Jest tu paradoks wart nazwania.

Z jednej strony FortiBleed jest gorszy niż zero-day, bo nie da się go „załatać". Nie ma poprawki, która zamknie problem — bo problemem nie jest kod, tylko higiena. Organizacja, która padła, padła przez własne zaniechanie, rozłożone na lata. A skoro kampania karmi się poświadczeniami z poprzednich włamań, to jest dowód, że poprzednie incydenty Fortinet nigdy nie zostały u tych ofiar właściwie posprzątane. To jest dług bezpieczeństwa, który wreszcie został ściągnięty.

Z drugiej strony — i to jest dobra wiadomość — właśnie dlatego, że nie ma luki do załatania, obrona jest w zasięgu każdego, kto prowadzi urządzenie Fortinet. Środki zaradcze są dobrze znane i powtarzane od lat. FortiBleed pokazuje tylko, jak wiele organizacji je zignorowało. To nie wymaga awaryjnego okna serwisowego ani czekania na poprawkę producenta. Wymaga zrobienia rzeczy, które należało zrobić dawno temu.

Jest tu jednak pułapka, którą trzeba nazwać wprost: sama zmiana hasła nie wystarczy, jeśli atakujący jest już w środku jako punkt nasłuchowy. Rotacja poświadczeń musi iść w parze z przeglądem logów i polowaniem na anomalne konta i sesje — inaczej zamykasz drzwi, zostawiając otwarte okno. Organizacja, która tylko zmieni hasła, a nie sprawdzi, czy ktoś już nie siedzi w urządzeniu, da atakującemu czas na zebranie nowych poświadczeń, zanim stare przestaną działać.

Co to znaczy dla naszej serii o Fortinet

Warto postawić pytanie, które samo się nasuwa: dlaczego Fortinet, znowu? W ciągu kilku tygodni opisaliśmy FortiClient EMS, FortiSandbox, a teraz FortiBleed.

Odpowiedź jest dwojaka. Po pierwsze, skala wdrożenia — firewalle i VPN-y Fortinet to jedne z najszerzej rozpowszechnionych urządzeń bezpieczeństwa sieciowego na świecie, więc są celem o gwarantowanej liczbie ofiar. Po drugie, i ważniejsze: historia wcześniejszych włamań. FortiBleed nie istniałby, gdyby nie wcześniejsze wycieki poświadczeń Fortinet — w grudniu atakujący wykorzystali dwie krytyczne luki FortiGate dni po ujawnieniu, a wcześniej tej wiosny znaleziono hakerów w ponad 14 000 VPN-ów Fortinet. Każde z tych włamań zostawiło po sobie poświadczenia. FortiBleed jest tym, co dzieje się, gdy te poświadczenia nie zostają unieważnione — kumulują się w bazę, która rośnie z każdym kolejnym incydentem.

To jest lekcja wykraczająca poza Fortinet: incydent bezpieczeństwa nie kończy się w dniu, w którym załatasz lukę. Kończy się, gdy unieważnisz każde poświadczenie, które mogło wyciec. Organizacje, które łatały luki Fortinet, ale nie rotowały haseł, zostawiły otwartą drogę — i FortiBleed właśnie nią wszedł.

Co zrobić

Sprawdź, czy twoje domeny są w bazie. Hudson Rock udostępnił darmowe narzędzie do sprawdzenia, czy twoja organizacja figuruje w danych kampanii. Jeśli prowadzisz urządzenie Fortinet i pojawiasz się w zbiorze — traktuj perymetr sieci jako już skompromitowany i działaj natychmiast.

Rotuj wszystkie poświadczenia Fortinet — ale nie tylko to. Zmień hasła wszystkich kont administracyjnych, kont SSL VPN i wbudowanych kont systemowych. Zmień nazwy domyślnych kont, jeśli wciąż używają fabrycznych. To zamyka pierwszy etap ataku.

Poluj na obecność atakującego, zanim uznasz problem za rozwiązany. Sama rotacja nie wystarczy, jeśli ktoś już siedzi w urządzeniu jako podsłuch. Przejrzyj logi, szukaj anomalnych kont, nietypowych sesji i nieznanych źródeł logowań. Jeśli urządzenie było skompromitowane, atakujący mógł już zebrać nowe poświadczenia — które trzeba też unieważnić.

Włącz wieloskładnikowe uwierzytelnienie na wszystkich interfejsach Fortinet. To jest jedyna kontrola, która łamie cały model FortiBleed: skradzione hasło bez drugiego składnika jest bezużyteczne. Kampania działa, bo poświadczenia same w sobie wystarczają do logowania — MFA to zmienia.

Potraktuj to jako audyt długu bezpieczeństwa po poprzednich incydentach. Jeśli twoja organizacja przeżyła wcześniejsze włamanie Fortinet i tylko załatała lukę, nie rotując poświadczeń — FortiBleed jest przypomnieniem, że tamta sprawa nie została zamknięta. Każdy nierozliczony incydent zostawia poświadczenia, które wracają.

Źródła

SOCRadar — oryginalny research z analizą serwera atakującego, liczbami i rozkładem portów: https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/

Dark Reading — analiza tezy „brak exploita" i kontekst credential-compromise: https://www.darkreading.com/cyberattacks-data-breaches/sweeping-credential-harvesting-heist-compromises-30k-fortinet-devices

Cybernews — kontekst wcześniejszych włamań Fortinet i mechanizm dwuetapowy: https://cybernews.com/security/hackers-database-30000-working-fortinet-logins/

Reuters (za Insurance Journal) — skala 75 000 urządzeń i ofiary Fortune 500 oraz rządowe: https://www.insurancejournal.com/news/national/2026/06/18/874317.htm

Hackread — szczegóły kampanii FortiBleed i analiza Hudson Rock: https://hackread.com/fortibleed-attack-fortinet-firewalls-credentials/