[UPDATE: 26/06/29] FortiBleed: nincs CVE, nincs patch, csak a vegytiszta kockázat [tl;dr]

FRISSÍTÉS: 2026. június 29.

A poszt megírása óta a kampány több ponton is élesedett, ezért az alábbi rövid kiegészítésel igyekszem teljesebb képet adni. A fő irányok nem változotak, néhány új részlet viszont érdemben módosítja a kockázat megítélését.

• A FortiGate csak a jéghegy csúcsa. A SpyCloud június 29-i frissített elemzése szerint a FortiGate volt a legnagyobb egységes célhalmaz a támadók pásztázó szerverén, de az összes megcélzott, internet felé kitett végpontnak még a harmadát sem tette ki. Ugyanez az infrastruktúra Synology DSM és Sophos tűzfal belépőportálokat is gyűjtött, bár egyelőre nem világos, hogy a puszta felderítésen túljutottak-e. Ez számokkal is alátámasztja, a korábbi megállapításunk: nem "Fortinet-probléma", hanem egy több gyártót érintő, válogatás nélküli hozzáférés-szerző gépezet.
• A léptékre konkrét számok jöttek. A friss kutatói összegzések szerint a művelet nagyjából 1,16 milliárd belépési kísérletet futtatott több mint 320 000 FortiGate ellen, és ezzel párhuzamosan 2,1 milliárd brute-force kísérletet több mint 160 000 MS-SQL szerver ellen. Az "ipari lépték" jelző így már nem túlzás.
• A jellemzés a kémkedés felé tolódott, és van megerősített adatszivárgás. A megjelenés óta több kutató is megerősített, teljes kompromittálódásokról számolt be, többek között Japánban, Tajvanon, Vietnamban, Irakban és Törökországban, egy NATO-hoz köthető török védelmi beszállítótól pedig minősített dokumentumokat is kiszivárogtattak. A célzás súlypontja feltűnően NATO-tagországokra esik, ami a pénzügyi motiváció mellett geopolitikai dimenziót is valószínűsít. Ez már nem pusztán hitelesítőadat-gyűjtés, hanem bizonyított behatolás és kiszivárogtatás.
• Konkrét post-exploitation eszközök, közvetlenül a vadászathoz. A Bitsight a FortiBleed-hez köthető hozzáférésekben Chisel és Neo-reGeorg HTTP-tunneling eszközöket figyelt meg. Vagyis a jelszócsere és a patchelés után érdemes a kifelé menő, normál webforgalomba simuló forgalmakat is végigvadászni, mielőtt bárki lezártnak tekinti az incidenst. Ezt érdemes beépíteni az assume-breach forgatókönyvbe, amelyet a poszt is javasol.
• Nevesített érintettek. A Hudson Rock adathalmazában többek között a Samsung, a Siemens, a Foxconn, az Oracle, az Accenture, a DHL, az Infosys, a Comcast, a Lenovo és a PwC is szerepel, sőt maga a Fortinet is. A méret és a profil tehát nem válogat: a kitett peremeszköz mindenkinél ugyanaz a kockázat.
• Hatósági kép és NIS2. A CISA mellett a brit NCSC és az ausztrál hatóság is kiadott figyelmeztetést, vagyis az ügyet Five Eyes-szinten kezelik. Dedikált ENISA- vagy CERT-EU-közleményt egyelőre nem találtam, de a SOCRadar szerint a teljes adathalmazt eljuttatták a világ CERT- és CSIRT-csapataihoz, így természetesen a hazai incidenskezelőkhöz is. NIS2-kötelezett szervezetként ez azt jelenti, hogy az érintettség dokumentált vizsgálata mostanra nemzetközileg is elvárt lépés, és pontosan beleillik a június 30-i audit bizonyítékbázisába.
• Amire számítani kell, és ez előrejelzés, nem tény. Több elemző a korábbi nagy hitelesítőadat-szivárgások mintája alapján arra számít, hogy a legnagyobb árbevételű célpontoknál nagyjából 30-60 napon belül, tehát durván július és augusztus folyamán indulhatnak zsarolóvírus-bevetési kísérletek, mert a szektor és árbevétel szerint rendezett adathalmaz éppen a zsarolóvírus-partnerprogramok célzási logikáját szolgálja ki. Ha eddig halogatható volt a teljes jelszócsere, most már nem az: a monetizációs hullám később jön, az ablakot viszont most kell bezárni.

A poszt fő tanulsága ettől csak még élesebb. Ha a kapu kulcsa kint van, akkor nem az a kérdés, hogy bejutnak-e, hanem hogy mire mennek vele, és láthatóan egyre messzebbre jutnak.

Új források a frissítéshez

• SpyCloud - What SpyCloud found inside the FortiBleed threat actor infrastructure (2026. június 29-i frissítés)
• Bitsight - Security alert: FortiBleed Fortinet VPN credentials and firewall exposure (Chisel és Neo-reGeorg)
• Recorded Future (Insikt Group) - Critical FortiBleed campaign
• Censys - June 19 advisory: Fortinet credential exposure campaign (FortiBleed)
• Sophos - FortiBleed credential exposure and Sophos VPN brute-forcing campaign
• UK NCSC figyelmeztetés a Fortinet peremeszközöket célzó FortiBleed kampányról
• Help Net Security - 74,000 Fortinet firewall credentials exposed in FortiBleed data leak (frissítésekkel)

AZ EREDETI BEJEGYZÉS ITT FOLYTATÓDIK:

2026 júniusában megint egy Fortinet-sztorin pörög a szakma, de ez a mostani meglehetősen más, mint amihez hozzászoktunk. Nincs mögötte friss CVE, nincs hozzá kiadott javítócsomag, és a Fortinet hivatalos álláspontja szerint a termékeiben sincs új sebezhetőség. Mégis olyan kampányról beszélünk, amely világszerte több mint 430 000 FortiGate tűzfalat vett célba, nagyjából 75 000 eszközről szerzett ellenőrzött, működő adminisztrátori belépést, és összesen több mint 110 millió hitelesítő adatot azonosított. A háttérben pedig egy pénzügyi haszonszerzésre játszó, orosz nyelvű hozzáférés-kereskedő (initial access broker, IAB) áll.

Ezért is tartom fontosnak, hogy írjak róla, mert ez a kampány, amelyet a kutatók FortiBleed néven kezdtek emlegetni, pontosan azt a vakfoltot világítja meg, amit a megfelelőségi mátrixokban olyan könnyű kipipálni: a "be van patchelve, tehát rendben van" hamis biztonságérzetét. Sőt, ahogy a friss elemzésekből kiderül, a sztori jóval túlmutat a tűzfal jelszaván: a kompromittált eszköz az egész belső hitelesítési forgalom lehallgatójává válik. Az alábbiakban összeszedem, hogyan értelmezem a kampányt, mi a tényleges technikai mechanizmusa, miért súlyosabb a kockázata, mint egy átlagos sebezhetőségé, hogyan tudja egy szervezet ellenőrizni a saját érintettségét, és milyen lépéseket javaslok, a hazai NIS2-kötelezettségekre is kitérve.

Mi a FortiBleed valójában?

Kezdjük a fogalmi tisztázással, mert ez a sztori egyik fő tanulsága. A FortiBleed nem egy sebezhetőség és nem a Fortinet feltörése. Egy nagyszabású, erősen automatizált hitelesítőadat-begyűjtési (credential harvesting) kampány, amely FortiGate tűzfalakat és SSL VPN átjárókat céloz, de a jelek szerint ennél jóval szélesebb, több gyártót érintő, kezdeti hozzáférést szerző művelet része.

A nyilvánosságra kerülés íve tankönyvi. Elsőként Volodymyr "Bob" Diachenko biztonsági kutató jelezte, hogy talált egy támadói kézben lévő, "különféle módokon" összegyűjtött, működőképesnek tűnő FortiGate-jelszavakat tartalmazó listát. Ezután a SOCRadar kutatói egymástól függetlenül bukkantak rá a támadók egyik nyitva felejtett operatív szerverére, amelyen ott sorakoztak az ellopott jelszavak, az eszközkészlet, az automatizációs infrastruktúra és az áldozati lista is. A Hudson Rock elemezte és nevezte el a kampányt, Kevin Beaumont pedig több szervezetnél személyesen ellenőrizte, hogy a kiszivárgott belépési adatok valódiak és élnek-e. Több, egymástól független forrás ugyanazt a képet erősíti meg, ami önmagában is komolyan veendővé teszi az ügyet.

A nagyságrendet érdemes három, egymástól elkülönülő mérőszámmal nézni, mert a sajtóban ezek gyakran összemosódnak:

• Célba vett eszközök: világszerte több mint 430 000 internet felé kitett FortiGate tűzfal.
• Megerősített, működő admin-hozzáférés: nagyjából 75 000 eszköz (a kiadás és az ellenőrzés állapotától függően ~30 000 és ~86 000 között szóródik a szám), és ez Shodan-adatok alapján az összes interneten elérhető FortiGate körülbelül fele.
• Összes begyűjtött hitelesítő adat: több mint 110 millió, és itt már messze nem csak FortiGate admin-jelszavakról van szó.

Összehasonlításként: a 2022-es, hírhedt Belsen Group-féle szivárgás nagyjából 15 000 eszközt érintett. A FortiBleed nem ugyanannak a történetnek az ismétlése, hanem nagyságrendi ugrás.

A célzás profilja sokat elárul a motivációról. Az elemzések szerint a kampány erősen a 200 főnél kisebb kis- és középvállalatokra (SMB) koncentrál, földrajzilag pedig az Egyesült Államok és India a kiemelt fókusz. Kulcsfontosságú célpont az IT-szolgáltatói szektor, és ez nem véletlen: egy kompromittált szolgáltatón keresztül hozzáférési útvonalak nyílnak az ügyfelei környezeteibe (itt érdemes megállni és elgondolkodni egy pillanatra, és visszaemlékezni a múlt heti Atomic Arch cikkemre, ahol megmutattam, hogy éppen célzottan fejlesztői accokat támadnak, és ellátási láncba történő észrevétlen beavatkozás a mögöttes cél... hát ez most ugyanaz kicsit más irányból... ). A támadó nem is kezeli egyformán a célpontokat: gazdasági érték szerint rangsorolja őket, mielőtt exploitációs erőforrást rendelne hozzájuk. A SOCRadar által megtalált adatbázisok ennek megfelelően ország, szektor és árbevétel szerint rendszerezve tárolták a validált belépési adatokat.

És itt jön a tágabb kép: a FortiBleed valószínűleg egy szélesebb, több gyártót célzó hozzáférés-szerző művelet egyik szelete. Ugyanaz az infrastruktúra 2026. február 28. óta automatizált brute-force-szal támad Synology NAS-okat, Sophos tűzfalakat, RDWeb portálokat, Citrix SSL-VPN-eket és MS-SQL szervereket is. Vagyis nem "Fortinet-probléma", hanem egy ipari léptékű, válogatás nélküli hozzáférés-begyűjtő gépezet, amelynek a FortiGate csak az egyik, bár kiemelten értékes belépési pontja. A "feketepiacon" mindeközben egy "SantaAd" nevű, orosz nyelvű szereplő több ezer Fortinet eszközhöz kínált hozzáférést, induló áron 30 000 dollárért, amit órákon belül 60 000-re emelt, bár nem egyértelmű, hogy ennek van-e közvetlen köze a FortiBleed adathalmazhoz.

A Fortinet álláspontja szerint ez régi incidensekből származó adatok újrahasznosítása, brute-force tevékenységgel kombinálva, és nincs benne új sebezhetőség. Technikailag ez védhető is. Csakhogy a védekező oldal szempontjából lényegtelen. Egy szervezet számára teljesen mindegy, hogy a belépési adatait tegnap vagy két éve lopták el, ha azóta sem cserélte le. Egy internet felől elérhető eszköz változatlan jelszavakkal nyitott ajtó marad, függetlenül attól, mikor szerezték meg hozzá a kulcsot. A "régi adat kontra aktuális fenyegetés" megkülönböztetés egyszerűen szertefoszlik abban a pillanatban, amikor a kulcs még mindig nyitja a zárat.

Hogyan működik a kampány: a technikai anatómia

A FortiBleed ereje a teljes automatizáltságában és az önmagát tápláló természetében rejlik: a kompromittált eszköz nem a végcél, hanem egy hitelesítőadat-pumpa, amely újabb belépéseket termel. A friss SOCRadar-elemzés alapján a művelet öt, jól elkülönülő szakaszra bontható, és ami szakmai szempontból igazán figyelemre méltó: szinte minden lépéshez saját, névvel ellátott eszköz tartozik.

1. Felderítés. Masscan és Shodan segítségével azonosítják az internet felé kitett, sebezhető FortiGate eszközöket, majd egy FortiProbe-fast nevű saját segédeszközzel szűrik, és egy GeoSplit nevű eszközzel ország szerint csoportosítják őket.

2. Hozzáférés. Egy "forticheck" nevű jelszóellenőrző célzottan a FortiGate adminisztrációs paneljét és az SSL-VPN portált támadja, credential stuffinggal és szótáralapú támadással szerezve adminisztrátori SSH-hozzáférést.

3. Lehallgatás, a kampány technikai szíve. Az SSH-hozzáférés birtokában a támadók egy Golang nyelven írt eszközt, a FortigateSniffer-t telepítik. Ez a FortiOS beépített diagnose sniffer packet diagnosztikai parancsát fordítja támadóeszközzé, hogy passzívan elkapja az eszközön áthaladó hitelesítési forgalmat, összesen 24 protokollon át (többek között TACACS+, Kerberos, RPC, SMB, LDAP, RDP, WinRM, MS-SQL, MySQL, PostgreSQL és RADIUS). A lényeg, hogy egy teljesen legitim, beépített funkcióval gyűjtenek be nyílt szövegű hitelesítő adatokat és jelszó-hasheket egyaránt.

4. Törés és terjeszkedés. A megszerzett hasheket Hashcattel és Hashtopolisszal törik, egy "HASHBOT" nevű Telegram-bot vezérlésével, majd az eredményt laterális mozgásra és Active Directory feltérképezésére használják.

5. Adatszerzés és perzisztencia. A hálózati megosztásokról érzékeny adatokat szivárogtatnak ki, az ellopott munkamenet-sütikkel (session cookie) pedig tartós, hitelesített hozzáférést tartanak fenn.

Hogy ez mekkora termelést jelent: a becslések szerint a támadók 2026. május 31. és június 15. között legalább 659 hitelesítőadat-begyűjtő pipeline-t indítottak, amelyek több mint 110 millió hitelesítő adatot azonosítottak, köztük nagyjából 14,8 millió RADIUS-belépést, 924 000 NTLM-hasht, 130 000 Kerberos-hasht és 89 millió MySQL-tokent. Ez már rég nem egy tűzfal jelszava, hanem egész szervezetek belső hitelesítő adatai.

Külön figyelmet érdemel, hogy a támadók a jelek szerint egy nyílt forráskódú, AI-natív offenzív platformot, a CyberStrike-ot is bevethették a munkafolyamat egyes részeihez. Ennek CyberStrikeAI nevű változatát egy korábbi, FortiGate-eket célzó tömeges pásztázó kampányban is használták, amelyet az Amazon Threat Intelligence tárt fel idén év elején. A peremeszközöket célzó automatizáció és a generatív eszközök összeérése önmagában is jól jelzi, merre tartanak a fenyegetések.

Az operatív kézjegyek attribúciós és detekciós szempontból is hasznosak. A sniffelő mechanizmus geofencing-szűrővel csak meghatározott IP-tartományokon működik, a tevékenység pedig moszkvai idő szerint 7 és 18 óra közé korlátozódik. A SpyCloud adatai szerint a FortiGate-hez kötődő begyűjtési ciklus 2026. május 19-én indult, a hash-törő infrastruktúrát a hónap végére állították fel. A Zenox elemzése szerint a művelet 300 perces (ötórás) ciklusokban fut, percenkénti státuszjelzéssel, ciklusonként egy regionális céllistát betöltve, 1000 párhuzamos szállal validálva. Az első ciklusokban a sikeres validáció aránya 90% körül mozgott. A Zenox ráadásul olyan felhasználónév-jelszó párokat talált, amelyek több ezer különböző IP-címen ismétlődtek, ami felveti, hogy ezeket a támadó ültette be rejtett hátsó kapuként.

A kép így áll össze: kurált jelszólista korábbi Fortinet-szivárgásokból és infostealer-naplókból, automatizált belépés, a kompromittált eszköz lehallgatóvá alakítása, majd a begyűjtött adatok visszacsatolása a pásztázóba. A gép önmagát eteti. A háttérben pedig ott van egy sor korábbi és párhuzamos Fortinet-sebezhetőség, amely éveken át táplálta a hitelesítő adatok begyűjtését: a klasszikus authentikáció-megkerülő CVE-2022-40684, az SSL VPN heap-túlcsordulásos CVE-2023-27997, a CVE-2024-55591, valamint 2026-ból a teljesen patchelt FortiOS ellen is bevetett, FortiCloud SSO-hibára épülő CVE-2026-24858 és a FortiSandbox körüli friss hibák (például CVE-2026-25089).

A SHA-256-csapda: miért nem véd a patch önmagában

Itt jön a sztori egyik legkínosabb és szakmailag legizgalmasabb része, amit minden FortiGate-üzemeltetőnek meg kell értenie.

A Fortinet a korábbi, sózott SHA-256 alapú jelszótárolásról áttért a számításigényesebb, így offline töréssel szemben sokkal ellenállóbb PBKDF2 algoritmusra. Ezt a FortiOS 7.2.11, 7.4.8 és 7.6.1 verziókban vezette be, 2025 végén. Eddig szép is lenne, csakhogy a migráció két komoly feltételhez kötött, és ezek együtt alkotják azt, amit "a passzív remediáció csapdájának" is hívhatunk.

Az első feltétel: a régebbi verzióról frissítve a meglévő adminisztrátori jelszó mindaddig SHA-256 hashként marad tárolva, amíg az adott adminisztrátor a frissítés után először be nem jelentkezik. Vagyis lehet, hogy a firmware-t felraktad, de ha az adminok azóta nem léptek be, a régi, gyengébb hash ott ül a konfigban. Egy "frissített" eszköz így bőven maradhat sebezhető.

A második, még alattomosabb részlet: a Fortinet leírása szerint a korábbi SHA-256 hash a PBKDF2-re váltás után is megőrződik egy rejtett, old-password nevű beállításban, visszafelé kompatibilitás céljából. Ez a beállítás a tűzfalra bejelentkezett adminisztrátor számára nem látható, de egy super_admin által készített konfigurációs mentésben megfigyelhető. Magyarul: akár újra is hashelted a jelszót, a régi gyenge hash maradék formában tovább létezhet, és pont ez az a "legacy adósság", ami a tömeges törést egyáltalán lehetővé tette.

És hogy teljes legyen a kép: a diagnose sniffer packet-re épülő lehallgatás a forgalomból nyíltan kapja el a hitelesítő adatokat, függetlenül attól, milyen erős a konfigban tárolt admin-hash. A SHA-256-csapda az offline törést könnyíti meg; a sniffer pedig még a tökéletes hash mellett is működik. A kettő együtt zárja be a kört.

Ezeket összerakva adódik a kampány leglesújtóbb tanulsága: rengeteg kompromittált eszköz "be volt patchelve". A firmware-frissítés nem ezüstgolyó, ha a mögöttes adat, vagyis maga a hash, nem frissül vele együtt, és főleg nem az, ha a támadó eleve a forgalomból szedi a jelszavakat.

A jelszóerősség mítoszát is érdemes eltemetni: a kutatók 25 karakteres, szimbólumokat, számokat és vegyes kis-nagybetűt tartalmazó jelszavakat is találtak az adathalmazban, méghozzá nyílt szövegben. Ezeket nem feltörték. Eleve ismertek voltak, mert egy az egyben kikerültek korábbi infostealer-naplókból. Ez újrarajzolja a teljes kockázati képet: egy erős jelszó, ami átment egy infostealer-fertőzésen, pontosan annyit ér, mint egy gyenge. A jelszó eredete fontosabb lett, mint az erőssége.

Miért súlyosabb ez, mint egy átlagos CVE?

Egy átlagos sebezhetőségnél van egy kényelmes mentális modellünk: jön a CVE, jön a patch, telepítjük, lezárjuk. A FortiBleed pont azért kellemetlen, mert ebbe a modellbe nem igazán illeszkedik.

A peremeszköz a királyság kulcsa. Egy FortiGate adminisztrátori belépési adat nem egy az adatlopási kockázatok közül, hanem teljes hálózati kontroll. VPN-hozzáférés, forgalomláthatóság, a laterális mozgás kiindulópontja, és gyakran a teljes szervezeti infrastruktúra előszobája. Aki ezt birtokolja, az nem "bejutott egy gépre", hanem a kapuban áll a kulccsal.

A robbanási sugár nem a tűzfal. Ez a FortiBleed legfontosabb újraértékelése. A FortigateSniffer 24 protokollon hallgat, így nem csak a FortiGate admin-jelszava kerül veszélybe, hanem minden, ami az eszközön áthalad: a belső RADIUS-hitelesítés, az Active Directory (NTLM, Kerberos), az adatbázis- és szolgáltatásfiókok. Hiába cseréled le a tűzfal jelszavát, ha a rajta átment domain- és szolgáltatási hitelesítő adatok már bent vannak az adathalmazban. A kompromittált perem itt az egész belső hitelesítést lehallgatta.

A hozzáférés perzisztens. Ahogy Benjamin Harris (watchTowr) megfogalmazta: a modern exploitáció nem mindig az azonnali hatásról szól, hanem olyan adatok begyűjtéséről, amelyek értéke jóval túléli az adott sebezhetőség javítását. A FortiBleednél ez kétszeresen igaz: az ellopott munkamenet-sütik a jelszócsere után is hozzáférést adhatnak, a több ezer IP-n ismétlődő, gyanús belépési párok pedig beültetett hátsó kapukra utalnak.

A megfelelőség és a valós biztonság szétcsúszik. Lehetsz teljesen patchelt, és közben kompromittált. A "passzív remediáció", vagyis a "felrakom a firmware-t, és kész" hozzáállás pont az a fajta gondolkodás, ami ezt a kampányt ennyire eredményessé tette.

Ellátási lánc és harmadik felek. Ha egy konkrét biztonsági termék globális telepítéseinek a fele kompromittálódik, az már nem egyedi IT-mulasztások halmaza, hanem rendszerszintű kockázat. A kampány kifejezetten az IT-szolgáltatókat célozza, mert rajtuk keresztül az ügyfélkörnyezetek is elérhetők, vagyis a beszállítód vagy a partnered kitett, változatlan jelszavú tűzfala a te problémád is. Ez egyenesen a hozzáférés-kereskedők gazdaságába vezet, ahol a peremeszköz a belépő, amit aztán zsarolóvírus- vagy kémkampány követhet.

A kínosabb tanulságok

Ezt a részt szándékosan őszintén írom, mert a FortiBleed olyan dolgokra mutat rá, amiket kényelmetlen kimondani, de pont ezért érdemes.

• "Be van patchelve" még nem "helyreállítva". A firmware-frissítés és a tényleges remediáció nem ugyanaz. A passzív megközelítés csapda.
• Legitim parancs mint támadóeszköz. A diagnose sniffer packet egy beépített diagnosztikai funkció, nem pedig "sebezhetőség", amit patchelni lehetne. Aki SSH-admin-hozzáférést szerez, az a saját eszközöd beépített képességeivel hallgat le.
• A tűzfalon át az AD-d is kiszivárgott. A sniffer 24 protokollon gyűjt, így a belső RADIUS/Kerberos/NTLM/MySQL hitelesítés is a zsákmány része. A FortiGate jelszó cseréje ezt önmagában nem zárja le.
• Session cookie perzisztencia. Az ellopott munkamenet-sütikkel a támadó a jelszócsere után is bent maradhat.
• Beültetett hátsó kapuk. A több ezer IP-n ismétlődő, gyanús belépési párok arra utalnak, hogy a támadó saját fiókokat is elhelyezhetett.
• Konfigurációhigiéniai csőd. A kompromittált fiókok több mint hatvan százaléka gyári alapértelmezett vagy kiszámítható, generikus nevű volt (nagyjából 35% generikus admin-fiók, 28,3% beépített Fortinet rendszerfiók). A támadónak sokszor brute-force-ra sem volt szüksége, elég volt a kiszámíthatóság.
• Menedzsmentinterfész az interneten. Az érintett eszközök többségénél a FortiGate menedzsmentinterfész közvetlenül kint volt az interneten, és a felfedezéskor is online maradt.
• Hiányzó MFA és jelszó-újrahasználat. Egyfaktoros admin- és távoli hozzáférés, korábbi incidens után sem cserélt jelszavak: a kurált lista pont ezt aknázza ki.
• Infostealer-vakfolt. A végpont kompromittálódása a peremet is kompromittálja. A hitelesítő adat eredete (átment-e egy fertőzött gépen) többet számít, mint az erőssége.

Az érintettség önellenőrzése: lépésről lépésre

Ha FortiGate-et vagy Fortinet SSL VPN-t üzemeltetsz, az alábbi sorrendben javaslom végigmenni az ellenőrzésen. A logika: a külső jelektől haladunk a konfigurációs és forgalmi bizonyítékig, mert az utóbbi az igazi próba.

1. Szerepelsz-e az adathalmazban? Több kutató ingyenes ellenőrzőt is közzétett: a Hudson Rock domain-alapú keresőt üzemeltet (infostealers.com), a SOCRadar pedig sajátot. Fontos a fenntartás: ezek domain szintű, tájékoztató jellegű eredmények, nem végleges ítéletek. A "nem találtunk" nem egyenlő a "biztosan nem vagyok érintett"-tel.
2. Támadási felület felmérése. Nézd meg (akár Shodan-szerű külső nézettel), hogy bármelyik FortiGate menedzsmentinterfész, SSL VPN portál vagy SSH-hozzáférés elérhető-e az internet felől, és azonosítsd a kitett FortiOS verziókat.
3. Konfigurációs szintű ellenőrzés, az egyik igazi teszt. super_admin jogosultsággal készíts konfigurációs mentést, és vizsgáld meg az adminisztrátori jelszavak tárolását. Keresd, hogy SHA-256 hash van-e PBKDF2 helyett, és nézd meg a rejtett old-password mezőt: ha ott maradék SHA-256 hash ül, akkor patchelt firmware mellett is kitett vagy.
4. Sniffer- és IOC-vadászat, a másik igazi teszt. Keress FortigateSniffer-nyomokat, jogosulatlan vagy szokatlan diagnose sniffer packet használatot, ismeretlen SSH-munkameneteket, idegen binárisokat vagy folyamatokat az eszközön. Vizsgáld, hogy a sikeres belépések feltűnően a moszkvai 7-18 óra sávba esnek-e, és figyeld a FortiGate szokatlan kimenő forgalmát.
5. Fiókleltár és beültetett kapuk. Vedd számba az összes admin- és rendszerfiókot, jelöld meg a gyári alapértelmezett vagy generikus nevűeket (admin és társai) és a működésileg szükségtelen beépített fiókokat. Külön keress olyan gyanús belépési párokat, amelyek több helyen, indokolatlanul ismétlődnek (lehetséges hátsó kapu).
6. Tágítsd ki a hitelesítőadat-kitettség vizsgálatát. Ne csak a FortiGate admin-fiókokat nézd: a kompromittált tűzfalon áthaladt RADIUS-, AD- (NTLM/Kerberos), MS-SQL/MySQL- és szolgáltatásfiókok is veszélyben vannak. Vizsgáld az Active Directory és a RADIUS naplóit is.
7. Munkamenet- és tokenellenőrzés. Tekintsd át a gyanús munkameneteket és session cookie-kat, mert ezeken keresztül a jelszócsere után is fennmaradhat a hozzáférés.
8. Naplóelemzés. A hitelesítési naplókban keress szokatlan földrajzi helyről érkező belépéseket, ismétlődő sikertelen próbálkozás utáni sikeres belépést, váratlan adminisztrátori tevékenységet, új admin-fiók létrehozását, konfigurációmódosítást.
9. MFA-lefedettség. Auditáld, mely admin- és VPN-fiókoknál hiányzik a többfaktoros hitelesítés.
10. Feltételezd a kompromittálódást, ha az eszköz internet felől elérhető volt, MFA nélkül, és/vagy a fenti hash- vagy sniffer-nyomok fennállnak. Ebben az esetben ne "ellenőrizz", hanem indíts incidenskezelést.

Megoldás és mitigáció: itt az ideje a teljes jelszócserének

A lépéseket szándékosan időhorizont szerint csoportosítom, mert a sorrend itt számít.

Azonnal (0-24 óra):

• Cseréld le az ÖSSZES admin- és VPN-hitelesítő adatot. Ne csak a gyanúsakat: minden kitett belépési adatot kezelj kompromittáltként.
• Ne állj meg a tűzfalnál. Rotáld a domain/AD-, RADIUS- és szolgáltatásfiók-jelszavakat is, és érvénytelenítsd a munkamenet-sütiket/tokeneket, mert ezeket a sniffer a forgalomból begyűjthette. Ez a kampány esetében nem túlzás, hanem az alapfeltétel.
• Vedd ki a menedzsmentinterfészeket és az SSH-t az internetről. Korlátozd megbízható belső IP-tartományokra, out-of-band menedzsmenthálózatra vagy kizárólag VPN-en keresztüli admin-útvonalra.
• Az SSL VPN portál csak akkor maradjon publikus, ha egyértelmű üzleti igény indokolja; egyébként korlátozd.
• Kényszerítsd ki az MFA-t minden admin- és távoli hozzáférésű fióknál.
• Keress és távolíts el ismeretlen vagy beültetett admin-fiókokat.

Rövid táv (napok):

• PBKDF2 kikényszerítése minden admin-fiókra. FortiOS-frissítés után kérd meg az összes adminisztrátort, hogy legalább egyszer jelentkezzen be, mert ez automatikusan PBKDF2-re állítja a hashelést. Ahol ez nem kivitelezhető, ott super_admin fiókkal manuálisan állítsd át a maradék adminisztrátorok jelszavát.
• A maradék SHA-256 eltávolítása az old-password mezőből. FortiOS 7.2.x és 7.4.x esetén kapcsold be a login-lockout-upon-weaker-encryption beállítást a system password-policy alatt, hogy a rejtetten tárolt SHA-256 hashek ténylegesen eltűnjenek.
• Monitorozd a diagnose sniffer packet használatát és a szokatlan SSH-tevékenységet; korlátozd az SSH-t megbízható forrásokra.
• Patchelés. FortiGate, FortiSandbox és FortiClient EMS, elsősorban az authentikáció-megkerülő és a távoli kódfuttatásos sebezhetőségekre.
• Alapértelmezett fiókok rendezése. Nevezd át vagy tiltsd le az alapértelmezett admin-fiókot, és távolítsd el a szükségtelen beépített rendszerfiókokat (a Fortinet hardening-útmutatója szerint).
• Végpontvédelem. Vadászd le és számold fel az infostealer-fertőzéseket, mert pont innen szivárogtak ki az "erős" jelszavak is.

Tartós (programszint):

• Folyamatos támadásifelület-monitorozás külső, internet felőli nézetből.
• Hitelesítőadat-életciklus: rendszeres csere, az újrahasználat tiltása, adathalászat-ellenálló MFA (FIDO2), privilegizált hozzáférés-kezelés (PAM).
• Az identitásmonitorozás terjedjen ki az AD-re és a RADIUS-ra is, ne csak a peremre, mert a FortiBleed pont azt mutatja meg, hogy a perem kompromittálódásával a teljes belső hitelesítés is kompromittálódik.
• Assume-breach készültség. Ha a kompromittálódás megerősítést nyer, futtass teljes incidenskezelést, és abból indulj ki, hogy az eszköz lehallgatóállomás volt: cseréld le mindazt, ami áthaladt rajta, érvénytelenítsd a munkameneteket, és keress perzisztenciát, tunneleket, beültetett fiókokat.
• Mélységi védelem. Ne a perem "falának" épségére hagyatkozz: szegmentálj, és figyeld a kelet-nyugati (east-west) forgalmat is.

A NIS2-dimenzió: bejelentési kötelezettség és audit

Hazai, NIS2-kötelezett szervezetként ezt a kampányt nemcsak technikai, hanem szabályozási szemüvegen át is nézni kell. Egy peremeszköz megerősített kompromittálódása nagy valószínűséggel bejelentésköteles incidens, és mivel a sniffer a belső AD-t és RADIUS-t is elérheti, a bejelentendő hatókör könnyen túlnyúlhat a tűzfalon.

A kötelezett kör Magyarországon a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (és a kapcsolódó végrehajtási rendeletek) alapján áll fenn; érdemes figyelni, hogy a 2026. január 6-i hatályú módosítás jelentősen szűkítette ezt a kört (jellemzően a középvállalkozási küszöböt, azaz az 50 főt vagy 10 millió eurót elérő, kockázatos vagy kiemelten kockázatos ágazatban működő szervezetekre). Ha a szervezeted ezután is a hatály alá esik, a NIS2 szerinti bejelentési kaszkád lép életbe: korai előrejelzés nagyjából 24 órán belül, részletesebb incidensbejelentés 72 órán belül, végső jelentés körülbelül egy hónapon belül, mindezt a felügyeleti hatóság, illetve a nemzeti CSIRT felé. A versenyszférában a felügyeletet a Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) látja el, a bírságtételeket pedig a 418/2024. (XII. 23.) Korm. rendelet rögzíti.

Van egy időzítési átfedés is, amit nem érdemes figyelmen kívül hagyni: a kötelező első kiberbiztonsági audit határideje 2026. június 30. Egy ilyen kampánnyal kapcsolatos érintettségvizsgálat és remediáció pontosan az a fajta megállapítás, amelynek be kell épülnie a kockázatelemzésbe és az audit bizonyítékbázisába. Dokumentált, megismételhető helyreállítás: ez egyszerre szolgálja a biztonságot és a megfelelést. (A pontos eljárásrendet és a saját szervezeti besorolásból fakadó határidőket mindenkinek a saját helyzetére kell illesztenie.)

Záró gondolat

A FortiBleed igazi tanulsága számomra nem a Fortinetről szól. Évek óta a kerítés magasítására költünk milliárdokat, miközben a kapu kulcsa szabadon hever, sőt, jó eséllyel már rég kint van az utcán. A peremvédelem akkor sem ér semmit, ha a falai tökéletesek, de a kulcsai kompromittáltak; és ahogy ez a kampány megmutatta, a kompromittált kapu mögött az egész belső hitelesítés lehallgathatóvá válik.

A modern, gazdasági érték szerint rangsoroló, AI-eszközökkel is felszerelt hozzáférés-kereskedelem korában a kérdés már nem az, hogy mennyire magas a falad, hanem az, hogy megbízhatsz-e azokban a hitelesítő adatokban, amelyek kinyitják a kaput, és azokban is, amelyek mögötte közlekednek. A valódi perem ma az identitás és a hitelesítő adatok integritása. Egy tűzfal pontosan annyira erős, mint a belépési adatok, amelyek feloldják.

Források

• The Hacker News (Ravie Lakshmanan) - FortiBleed Targeted FortiGate Firewalls in 110 Million-Credential Harvesting Operation
• SOCRadar - Dismantling FortiBleed: Inside an Active Fortinet Credential Harvesting Campaign (és a kapcsolódó blogbejegyzés)
• Hudson Rock - FortiBleed elemzés és ingyenes ellenőrző (infostealers.com)
• Kevin Beaumont (DoublePulsar) - FortiBleed: 75k Fortinet firewalls have admin passwords cracked
• Arctic Wolf Labs - Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries
• SpyCloud - What SpyCloud found inside the FortiBleed threat actor infrastructure
• Zenox - FortiBleed pipeline- és validációs elemzés
• Kudelski Security - Fortinet "FortiBleed" Global Compromise & Active Exploitation
• CSO Online - FortiBleed campaign exposes 75,000 Fortinet firewalls worldwide
• Cloud Security Alliance - Research note: FortiBleed és az alapértelmezett hitelesítő adatok
• CISA figyelmeztetés, valamint a Cyber Security Agency of Singapore AD-2026-007 tanácsadása
• Fortinet PSIRT / FortiGuard Labs és Fortinet Community (PBKDF2 kikényszerítése FortiOS-en)
• Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény; 418/2024. (XII. 23.) Korm. rendelet; 7/2024. (VI. 24.) SZTFH rendelet