Ataki na FortiClient EMS: luka CVE-2026-35616 posłużyła do dystrybucji infostealera EKZ

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Aktywnie wykorzystywana podatność CVE-2026-35616 w FortiClient Enterprise Management Server (EMS) pokazuje, jak niebezpieczne może być przejęcie centralnej infrastruktury zarządzania punktami końcowymi. W tym przypadku napastnicy nie ograniczyli się do uzyskania dostępu do serwera zarządzającego, lecz wykorzystali go jako zaufany kanał do rozsyłania złośliwego oprogramowania do zarządzanych stacji roboczych. Kampania doprowadziła do wdrożenia nowego infostealera oznaczonego jako EKZ, podszywającego się pod legalną poprawkę dla oprogramowania Fortinet.

W skrócie

CVE-2026-35616 to krytyczna luka typu authentication bypass w FortiClient EMS.
Podatność umożliwia nieuwierzytelnionemu atakującemu wykonywanie działań administracyjnych, w tym zdalne uruchamianie poleceń lub kodu.
Napastnicy wykorzystywali przejęty serwer EMS do modyfikowania profili zdalnego dostępu i polityk endpointów.
Końcowym ładunkiem był infostealer EKZ kradnący dane z przeglądarek Chromium oraz Firefox.
Atak wyróżnia się użyciem legalnego, zaufanego kanału administracyjnego do dystrybucji malware.

Kontekst / historia

FortiClient EMS pełni rolę centralnego systemu zarządzania agentami FortiClient, politykami bezpieczeństwa oraz konfiguracją połączeń VPN. Tego typu platformy są wyjątkowo atrakcyjnym celem dla cyberprzestępców, ponieważ kompromitacja pojedynczego serwera może przełożyć się na szeroki wpływ na całe środowisko organizacji.

Podatność CVE-2026-35616 została publicznie powiązana z aktywnymi atakami na początku kwietnia 2026 roku. Producent potwierdził wykorzystanie luki w rzeczywistych kampaniach i opublikował awaryjne poprawki dla podatnych wersji 7.4.5 oraz 7.4.6. Jednocześnie wskazano, że linia 7.2 nie została objęta tym problemem. Sprawa zyskała dodatkową wagę po pilnych ostrzeżeniach dla administracji federalnej USA oraz doniesieniach o dużej liczbie publicznie dostępnych instancji EMS wystawionych do Internetu.

Z czasem analizy incydentów pokazały, że luka nie była używana wyłącznie do uzyskania dostępu administracyjnego. Atakujący zaczęli wykorzystywać centralne mechanizmy zarządzania FortiClient do masowego dostarczania złośliwego kodu na zarządzane endpointy, znacząco zwiększając skalę oddziaływania pojedynczej kompromitacji.

Analiza techniczna

Źródłem problemu jest nieprawidłowa kontrola dostępu w interfejsach API FortiClient EMS. W praktyce oznacza to możliwość wykonywania operacji administracyjnych bez poprawnego uwierzytelnienia. Po skutecznym obejściu mechanizmów dostępowych napastnik może ingerować w konfigurację systemu oraz polityki stosowane wobec agentów końcowych.

W obserwowanej kampanii łańcuch ataku przebiegał według powtarzalnego schematu. Najpierw napastnik wykorzystywał CVE-2026-35616 do uzyskania nieautoryzowanego dostępu do funkcji administracyjnych EMS. Następnie modyfikował profil Remote Access Profile i polityki endpointów, dodając skrypt uruchamiany po zestawieniu połączenia VPN. Po ustanowieniu tunelu IPsec komponent FortiClient uruchamiał skrypt wsadowy przy użyciu procesów systemowych, a ten wywoływał zakodowany w Base64 payload PowerShell. Kolejnym etapem było pobranie pliku wykonywalnego podszywającego się pod legalną poprawkę endpointową, który finalnie uruchamiał infostealera EKZ.

Istotne jest to, że złośliwy kod nie był dostarczany przez phishing ani przez odrębne włamanie na każdą stację. Dystrybucja odbywała się za pośrednictwem zaufanego kanału administracyjnego. W efekcie każdy zarządzany endpoint mógł stać się celem wykonania malware bez wzbudzania natychmiastowych podejrzeń użytkownika.

Sam EKZ Infostealer koncentruje się na kradzieży danych z przeglądarek. Obejmuje to zapisane hasła, ciasteczka sesyjne, dane autouzupełniania, informacje adresowe oraz dane kart płatniczych. Obsługiwane są zarówno przeglądarki oparte na Chromium, jak i Firefox. Szczególnie niebezpieczna jest zdolność do pozyskiwania ciasteczek i innych danych wspierających przejęcie aktywnych sesji, co może ograniczać skuteczność części mechanizmów MFA.

W analizach incydentów zwracano uwagę na sygnały ostrzegawcze w logach EMS. Jednym z ważniejszych wskaźników był komunikat o braku certyfikatu w nagłówku żądania, po którym mogły następować nietypowe operacje związane z certyfikatami i zmianami konfiguracji. Dodatkowo obserwowano logowania z infrastruktury VPS, z węzłów Tor oraz nieoczekiwane modyfikacje profili zdalnego dostępu.

Konsekwencje / ryzyko

Skutki kompromitacji FortiClient EMS są znacznie poważniejsze niż przejęcie pojedynczego hosta. W tym scenariuszu naruszona zostaje zaufana płaszczyzna zarządzania, która może posłużyć do równoczesnego wdrożenia złośliwych skryptów na wielu stacjach roboczych i systemach klienckich.

masowa dystrybucja malware do zarządzanych endpointów,
kradzież poświadczeń z przeglądarek i aplikacji webowych,
przejęcie sesji przy użyciu ciasteczek uwierzytelniających,
wtórny dostęp do usług chmurowych, paneli administracyjnych i aplikacji wewnętrznych,
ryzyko dalszego ruchu bocznego lub eskalacji do ransomware,
utrata integralności konfiguracji bezpieczeństwa dystrybuowanej centralnie.

Z perspektywy operacyjnej szczególnie niebezpieczne jest to, że część aktywności może przypominać legalne działania administracyjne. Jeśli organizacja nie monitoruje zmian w profilach VPN, uruchomień PowerShell inicjowanych przez komponenty FortiClient oraz nietypowych logowań do konsoli EMS, naruszenie może pozostać niewykryte przez dłuższy czas.

Rekomendacje

Organizacje korzystające z FortiClient EMS powinny potraktować ten typ incydentu jako zagrożenie dla całej floty zarządzanych urządzeń, a nie wyłącznie dla jednego serwera aplikacyjnego. Reakcja powinna obejmować zarówno działania naprawcze po stronie EMS, jak i szeroką weryfikację endpointów.

niezwłocznie zainstalować poprawki bezpieczeństwa lub przeprowadzić aktualizację do wersji wolnej od problemu,
sprawdzić, czy instancja EMS była wystawiona bezpośrednio do Internetu,
przeanalizować logi EMS pod kątem anomalii związanych z certyfikatami i próbami obejścia uwierzytelnienia,
zweryfikować ostatnie zmiany w profilach Remote Access Profile, politykach endpointów i skryptach uruchamianych po zestawieniu tunelu VPN,
monitorować uruchomienia cmd.exe i powershell.exe inicjowane przez procesy FortiClient,
poszukiwać artefaktów w katalogach związanych z logowaniem i skryptami klienta oraz podejrzanych plików w katalogach systemowych,
wykrywać połączenia HTTP do surowych adresów IP oraz sekwencje obejmujące pobranie, uruchomienie i eksfiltrację danych,
sprawdzić, czy nie pojawiły się nowe konta administracyjne lub logowania z nietypowych lokalizacji i ASN,
wymusić reset poświadczeń użytkowników przy podejrzeniu kradzieży danych z przeglądarek,
unieważnić aktywne sesje w systemach SaaS i aplikacjach wewnętrznych, aby ograniczyć skutki przejęcia ciasteczek.

W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto dodatkowo odseparować płaszczyznę zarządzania EMS od sieci publicznej, ograniczyć dostęp administracyjny za pomocą segmentacji i list dozwolonych adresów oraz wdrożyć reguły detekcji skupione na nietypowych modyfikacjach centralnie dystrybuowanej konfiguracji VPN.

Podsumowanie

Kampania wykorzystująca CVE-2026-35616 przeciwko FortiClient EMS pokazuje, że atak na system zarządzający może mieć skutki porównywalne z naruszeniem o charakterze domenowym. Po obejściu uwierzytelnienia napastnicy użyli legalnych funkcji platformy do wypchnięcia infostealera EKZ na zarządzane endpointy, znacząco zwiększając skalę i skuteczność operacji.

Dla zespołów bezpieczeństwa kluczowy wniosek jest jasny: kompromitacja systemu EDR, UEM, MDM czy platformy zarządzania klientami VPN nie powinna być traktowana jak zwykły incydent serwerowy. Wymaga szybkiego łatania, monitorowania zmian konfiguracyjnych, analizy procesów potomnych uruchamianych przez agentów końcowych oraz założenia, że wszystkie zarządzane hosty mogły zostać narażone.