Jeśli używasz FortiClient EMS 7.4.5 lub 7.4.6 bez hotfixa — potraktuj serwer jako skompromitowany, dopóki nie udowodnisz inaczej. Zaktualizuj do 7.4.7 lub nowszej natychmiast. To był zero-day eksploatowany przed publikacją łatki, więc sama aktualizacja nie wystarczy — trzeba też przeszukać środowisko.
Sygnał do sprawdzenia w logach EMS: linia Certificate not found in request header, a kilka sekund po niej Certificate user: fortinet-ca2 ... successfully updated. Ta sekwencja oznacza próbę eksploitacji. Sprawdź też nieoczekiwane zmiany w konfiguracji Remote Access Profile i wartość remind_upgrade_after — atakujący ją modyfikował, żeby odroczyć przypomnienia o aktualizacji firmware.
CVE-2026-35616 to obejście uwierzytelnienia w FortiClient Enterprise Management Server. CVSS 9.1. Fortinet wydał awaryjne hotfixy na początku kwietnia, potwierdzając że błąd był eksploatowany jako zero-day. CISA dodała go do katalogu Known Exploited Vulnerabilities 6 kwietnia.
Mechanizm samej podatności jest prosty i dlatego groźny. Gdy specjalnie spreparowane żądania HTTP trafiają do określonych endpointów API serwera EMS bez ważnych poświadczeń, są przetwarzane tak, jakby były legalnymi działaniami administracyjnymi. Atakujący zdalny i nieuwierzytelniony wysyła żądanie z podrobionym nagłówkiem certyfikatu — i od tego momentu może wykonywać operacje, które normalnie wymagają uprawnień administratora.
To jest punkt wyjścia. Ale nie jest sercem tej historii.
System zarządzania jako kanał dystrybucji
FortiClient EMS to centralna płaszczyzna zarządzania całym wdrożeniem Fortinet — narzędzie, przez które administratorzy IT wdrażają, konfigurują i monitorują oprogramowanie FortiClient na wszystkich urządzeniach w organizacji.
Arctic Wolf opisuje co atakujący zrobił z tym dostępem — i to jest moment, w którym pojedyncza podatność staje się kompromitacją całej floty: atakujący użył własnej ścieżki zarządzania FortiClient, żeby wypchnąć złośliwe polecenia PowerShell na zarządzane urządzenia w sposób, który przypominał legalne operacje zarządcze.
Sekwencja: obejście uwierzytelnienia daje dostęp do API. Atakujący modyfikuje konfigurację Remote Access Profile i politykę endpointów, wstrzykując złośliwy skrypt. Następnie używa workflow skryptowego VPN — normalnego mechanizmu FortiClient do wykonywania poleceń na urządzeniach — żeby uruchomić ten skrypt.
Kluczowe zdanie z raportu Arctic Wolf: gdy atakujący ma już drogę do modyfikacji konfiguracji zarządzanej przez EMS, każdy zarządzany endpoint staje się potencjalnym celem wykonania — bez konieczności osobnej ścieżki włamania do każdego urządzenia.
To jest cała teza tej historii. Atakujący nie włamuje się na sto urządzeń. Włamuje się na jeden serwer zarządzania i każe mu rozdystrybuować malware na sto urządzeń — używając mechanizmu, który te urządzenia mają zaprojektowany właśnie po to, żeby ufać poleceniom z EMS.
Łatka, która jest malware
Ładunek dostarczony na endpointy nazywa się FortiEndpoint_Patch.exe. Jest to infostealer skompilowany w MinGW, który Arctic Wolf nazwał EKZ.
Nazwa pliku nie jest przypadkowa. Malware podaje się za łatkę na dokładnie tę podatność, przez którą został dostarczony. Urządzenie dostaje przez system zarządzania Fortinet plik o nazwie sugerującej aktualizację zabezpieczeń Fortinet — i wykonuje go po cichu przez PowerShell.
Darkweb Informer wskazuje to wprost jako szczegół wart uwagi obrońców: malware udający łatkę na właśnie tę lukę, której użyto do jego dostarczenia. To jest socjotechnika wpisana w nazwę pliku. Administrator który zobaczy FortiEndpoint_Patch.exe w logach wykonania, w środowisku Fortinet, w momencie gdy wszyscy mówią o krytycznej luce w Fortinet — ma wszelkie powody, żeby pomyśleć "to ta łatka, dobrze".
Co kradnie EKZ
EKZ Infostealer został zbudowany do kradzieży poświadczeń. Wyciąga zapisane dane logowania, ciasteczka i dane autouzupełniania z przeglądarek rodziny Chromium i Firefox — w tym techniki obchodzące mechanizm szyfrowanego przechowywania haseł w Chrome.
Skradzione dane trafiają przez HTTP na serwer VPS kontrolowany przez atakującego. Arctic Wolf zaznacza że zdolność EKZ do wyciągania poświadczeń, ciasteczek i danych autouzupełniania tworzy ryzyko wykraczające poza początkowo dotknięte urządzenia — bo skradzione poświadczenia otwierają dostęp do kolejnych systemów.
To jest ten sam wzorzec eskalacji, który opisywaliśmy przy całej serii supply chain z maja — skradzione poświadczenia z jednego miejsca są kluczem do następnego.
Dlaczego to jest pierwszy temat czerwca
Jest jedno zdanie, które krąży wokół tej kampanii i które łączy ją bezpośrednio z tezą czerwcową z naszego Radaru: AI skróciło okno reakcji człowieka i zmieniło zdalny dostęp w najszybszą drogę do naruszenia.
FortiClient EMS jest ilustracją tej tezy w trzech wymiarach naraz.
Po pierwsze — zaufana infrastruktura jako wektor. To jest kontynuacja DAEMON Tools z zatrutym instalatorem, CPUIDi całej serii, w której oficjalny kanał dystrybucji staje się drogą ataku. Tutaj kanałem jest sam system zarządzania bezpieczeństwem endpointów — narzędzie, którego zadaniem jest chronić te urządzenia.
Po drugie — system zarządzania jako mnożnik zasięgu. Jeden skompromitowany serwer EMS to nie jedno urządzenie. To każde urządzenie, które ten serwer zarządza. Blast radius nie jest liniowy — jest równy całej zarządzanej flocie.
Po trzecie — okno reakcji. Był to zero-day, eksploatowany przed publikacją łatki. Organizacje, które czekały na regularny cykl aktualizacji, były eksploatowane, zanim w ogóle wiedziały, że jest co łatać. Dokładnie to, o czym CERT-In pisał wprowadzając 12-godzinne okno, i o czym Palo Alto mówiło, szacując okno obrońcy na tygodnie.
Co zrobić — pełna lista
Sama łatka nie wystarczy, bo to był zero-day. Jeśli prowadziłeś FortiClient EMS 7.4.5 lub 7.4.6 bez hotfixa w okresie przed kwietniową łatką, zakładaj kompromitację serwera.
Zaktualizuj EMS do 7.4.7 lub nowszej.
Przeszukaj logi EMS pod kątem sekwencji Certificate not found in request header → Certificate user: fortinet-ca2 ... successfully updated.
Sprawdź konfigurację Remote Access Profile i polityki endpointów pod kątem nieoczekiwanych skryptów. Sprawdź wartość remind_upgrade_after — jej modyfikacja to ślad atakującego odraczającego przypomnienia o aktualizacji.
Na endpointach: szukaj FortiEndpoint_Patch.exe i wykonań PowerShell wywołanych przez workflow skryptowy FortiClient. Jeśli znajdziesz — rotuj wszystkie poświadczenia przeglądarkowe na tym urządzeniu, bo EKZ kradnie zapisane hasła, ciasteczka i dane autouzupełniania.
Kilku badaczy opublikowało bezpieczne, niedestrukcyjne skrypty detekcyjne wykorzystujące analizę różnicową odpowiedzi serwera — wysyłają żądanie bazowe bez nagłówków i porównują odpowiedź z żądaniem ze spreparowanym nagłówkiem, żeby wykryć podatny serwer bez jego eksploitacji.
Źródła
Arctic Wolf — pierwotna analiza kampanii z pełnym łańcuchem ataku i IOC: https://arcticwolf.com/resources/blog/forticlient-ems-exploited-via-cve-2026-35616-to-deliver-ekz-infostealer-disguised-as-a-fortinet-patch/
BleepingComputer — szczegóły workflow VPN i sekwencji logów certyfikatu: https://www.bleepingcomputer.com/news/security/hackers-exploit-forticlient-ems-flaw-to-push-infostealer-malware/
Help Net Security — mechanizm obejścia API i modyfikacje konfiguracji: https://www.helpnetsecurity.com/2026/05/29/forticlient-ems-vulnerability-infostealer/
Darkweb Informer — analiza techniczna podrobionego nagłówka i skrypty detekcyjne: https://darkwebinformer.com/one-forged-header-unauthenticated-authentication-bypass-in-fortinet-forticlient-ems-cve-2026-35616/
SecurityWeek — kontekst zero-day i oś czasu od kwietniowych hotfixów: https://www.securityweek.com/critical-forticlient-ems-vulnerability-exploited-in-fresh-attacks/
The Hacker News — potwierdzenie trwającej eksploitacji w maju: https://thehackernews.com/2026/05/threat-actors-exploit-critical.html
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł