Fortinet customers are facing a new wave of attacks after a critical flaw in FortiClient Endpoint Management Server (EMS) was exploited to push a fake Fortinet patch that secretly installs credential‑stealing malware.
The vulnerability, tracked as CVE‑2026‑35616, allows unauthenticated attackers to bypass FortiClient EMS API authentication and issue privileged requests, effectively turning the management server into a remote code execution platform for the entire managed fleet.
Arctic Wolf Labs recently observed a threat cluster abusing this weakness to deliver a new infostealer, dubbed EKZ, across organizations that rely on FortiClient EMS for centralized endpoint and VPN management.
FortiClient EMS is designed to centrally manage FortiClient endpoints, policies, and VPN configurations, making it a high‑value target for adversaries seeking scale and trust abuse.
In this campaign, attackers first interacted with exposed EMS instances over HTTP, sending specially crafted requests that were processed as legitimate administrative actions despite lacking valid certificates or credentials.
During testing and incident response, Arctic Wolf analysts consistently observed a distinctive EMS log entry, “Certificate not found in request header,” when exploitation attempts were made, followed within seconds by messages indicating successful updates from a fabricated Fortinet fabric device identity.
Shortly after these events, malicious login activity was recorded from multiple Tor exit node IP addresses, suggesting the attackers were deliberately hiding their infrastructure.
Once inside EMS, the threat actors modified management configurations rather than directly attacking endpoints one by one. They updated parameters such as firmware reminder settings and, more critically, altered Remote Access Profile configurations and endpoint policies to insert a malicious script that would execute automatically on FortiClient‑managed devices.
Because EMS can push SSL and IPsec VPN configurations to endpoints, including scripts that run when a VPN tunnel connects, the attackers abused this legitimate “on_connect” behavior to silently execute their payload.
Within seconds of an endpoint establishing an IPsec tunnel to a configured FortiGate firewall, FortiClient components such as fortitray.exe were observed launching .cmd scripts from the FortiClient logsTracescripts directory, using filenames based on GUIDs to blend in with routine troubleshooting artifacts.
These command scripts then executed a base64‑encoded PowerShell script that implemented a multi‑step infection chain. The PowerShell code attempted to download a payload from the attacker‑controlled server at 83.138.53[.]110 using several fallback methods to improve reliability, saved and executed the downloaded binary, slept for roughly 90 seconds, and then exfiltrated output data back to the same server via HTTP POST.
Across multiple endpoints, the observed process tree remained consistent: a FortiClient VPN or tray process spawned cmd.exe, which spawned powershell.exe running the download script, which finally launched an executable named FortiEndpoint_Patch.exe, presented to victims and logging systems as a routine Fortinet endpoint update.
Analysis of FortiEndpoint_Patch.exe, also hosted as p.exe on the attacker’s infrastructure, revealed a previously unreported MinGW‑compiled Windows credential stealer that Arctic Wolf named EKZ Infostealer.
The tool focuses on harvesting browser data from Chromium‑based browsers such as Chrome, Edge, and related variants, as well as Firefox and other Gecko‑based browsers.
For Chromium families, EKZ locates installed browsers through the registry, reads the Local State file to extract the os_crypt.app_bound_encrypted_key value, then copies itself into the browser’s Application directory and re‑executes to satisfy Chromium’s elevation service checks.
It then calls the Windows interface IElevator::DecryptData to derive the AES‑256 master key, iterates over user profiles, and decrypts SQLite databases containing passwords, cookies, and autofill data.
For Firefox and Gecko‑based browsers, EKZ dynamically loads NSS libraries via nss3.dll and targets standard credential stores including key4.db, logins.json, and cookies.sqlite.
The malware aggregates this data into an internal SQLite‑backed results store and writes output to log.txt under the ProgramData directory, which the earlier PowerShell script periodically exfiltrates to the attacker’s server.
Collected information includes saved passwords, session cookies that may allow login bypass or MFA circumvention through session reuse, and sensitive autofill content such as credit card details, addresses, and phone numbers.
Arctic Wolf also recovered additional related samples from the same server, including ZIP and MSI variants of the fake FortiEndpoint patch and a trojanized installer with a misspelled “Microsoftr Windowsr Operating System‑Installer.exe” filename, indicating active tooling development around this campaign.
According to Arctic Wolf, this activity demonstrates how attackers increasingly weaponize trusted management infrastructure instead of relying on broad phishing or standalone malware lures.
By abusing CVE‑2026‑35616 to gain privileged access to FortiClient EMS, the threat actors turned a legitimate patching and VPN automation pipeline into a highly efficient delivery channel for EKZ Infostealer.
Organizations running affected FortiClient EMS versions are urged to upgrade to fixed releases immediately and restrict network access to the EMS management port 8013 to trusted administrative IP ranges only.
Defenders should also hunt for anomalous EMS log entries, Tor‑sourced logins, unusual VPN‑triggered script execution chains, and outbound HTTP traffic to 83.138.53[.]110, and consider resetting browser‑stored credentials and invalidating active sessions for potentially impacted users.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
