Overview

On 28 May 2026 Arctic Wolf publicly disclosed an active threat campaign in which an unidentified financially motivated actor exploited CVE-2026-35616, a critical (CVSS 9.8) improper access control flaw in Fortinet FortiClient Endpoint Management Server (EMS) API authentication, as the initial access vector to weaponize trusted endpoint management infrastructure for mass credential theft. The campaign delivered a previously undocumented Windows infostealer that Arctic Wolf designated EKZ Infostealer, named from internal symbol strings recovered from the decrypted code. The campaign represents a textbook misuse-of-legitimate-feature attack: rather than relying on novel implants for persistence, the actor abused FortiClient's documented on_connect script directive — which executes scripts upon IPsec VPN tunnel establishment — to achieve recurring code execution under SYSTEM context every time the user connects to the corporate VPN.

Initial Access and Vulnerability

CVE-2026-35616 (CWE-284, Improper Access Control) was published by Fortinet on 4 April 2026 under advisory FG-IR-26-099, with credit to Simo Kohonen of Defused and Nguyen Duc Anh. The flaw affects FortiClient EMS 7.4.5 and 7.4.6 and permits an unauthenticated remote attacker to bypass API authentication and issue privileged requests against the EMS management API (TCP/8013 in default deployments). FortiClient EMS 7.4.7 contains the fix; FortiClient Cloud and FortiSASE customers were remediated server-side. watchTowr's Attacker Eye sensors observed in-the-wild exploitation as early as 31 March 2026, four days before Fortinet's coordinated disclosure, indicating the vulnerability was a zero-day at the time of initial use. CISA added CVE-2026-35616 to the Known Exploited Vulnerabilities catalog on 6 April 2026 with a federal mitigation deadline of 9 April 2026.

Weaponization — on_connect Script Injection

After authenticating to the EMS API via the bypass, the actor modifies the organization's Remote Access Profile and endpoint policy, injecting a malicious on_connect script directive. The on_connect feature is a documented FortiClient capability that executes administrator-defined scripts when an IPsec tunnel is established; it is designed for legitimate post-connection automation (drive mapping, banner display) and runs in the context of the FortiClient service. EMS pushes the modified policy to every managed endpoint, and on the next VPN connection the on_connect script materializes on the endpoint at C:\Program Files\Fortinet\FortiClient\logs\Trace\scripts\{GUID}.cmd, where {GUID} is a fresh UUID generated per push. fortitray.exe (the FortiClient system-tray host) or ipsec.exe (the VPN tunnel handler) invokes cmd.exe to execute the .cmd file, which in turn launches powershell.exe with a base64-encoded -EncodedCommand payload. The PowerShell stage downloads FortiEndpoint_Patch.exe (also named p.exe in transit) from hxxp://83.138.53.110/dl/p.exe and executes it with no on-disk staging beyond the binary itself, sleeping for approximately 90 seconds before issuing an HTTP POST to the same host to confirm execution and stage exfiltration.

EKZ Infostealer Capabilities

FortiEndpoint_Patch.exe is a MinGW-compiled (GCC for Windows) PE32+ binary masquerading as a legitimate Fortinet patch. Reverse-engineering by Arctic Wolf revealed the implant calls itself EKZ in internal symbol strings. The malware enumerates installed browsers via the Windows registry and selects from two distinct credential-extraction paths:

Chromium-family (Google Chrome, Microsoft Edge, Brave, and other v20-AES-256 derivatives): EKZ stages a self-copy into the targeted browser's Application\ directory to satisfy the Elevation Service's path-validation check, then invokes the legitimate Google Chrome Elevation Service via the IElevator COM interface, specifically IElevator::DecryptData. This call returns the cleartext v20 master AES-256 key that protects the SQLite-based Login Data and Cookies databases — bypassing the DPAPI-bound user-context decryption requirement that has historically forced stealers to run as the logged-in user.

Gecko-family (Mozilla Firefox, LibreWolf, Mozilla Thunderbird): EKZ dynamically loads nss3.dll from the targeted application's install directory and uses NSS_Init, PK11SDR_Decrypt, and related APIs to decrypt key4.db (master key store), logins.json (saved credentials), and cookies.sqlite (browser cookies) directly in process.

All harvested material — passwords, session cookies, credit card autofill, and browser autocomplete entries — is concatenated to a plaintext file at C:\ProgramData\log.txt and exfiltrated to the C2 (83.138.53.110) on a timed schedule via HTTP POST. Arctic Wolf explicitly highlights that stolen session cookies enable account takeover even where MFA protections are in place, because valid post-authentication cookies bypass the MFA challenge entirely.

Post-Exploitation Activity

Within hours of successful credential exfiltration, Arctic Wolf observed authentication attempts from Tor exit nodes 185.220.101.15 and 192.42.116.14 against the victim's perimeter and SaaS identity providers — consistent with hands-on-keyboard validation of stolen cookies and credentials. The malware itself does not appear to implement lateral movement or post-exploitation tooling; the actor appears to operate a steal-validate-monetize tradecraft model in which the EKZ implant is solely a harvester and human operators perform follow-on intrusion.

Attribution and Motivation

No public attribution has been issued. The campaign's tradecraft — exploitation of a recently disclosed enterprise CVE for opportunistic mass deployment, financially monetizable credential and cookie theft, and Tor-fronted follow-on access — is consistent with cybercriminal initial access broker (IAB) operations rather than nation-state activity. Attribution confidence is LOW. The presence of EKZ as an apparently bespoke (not commodity) infostealer suggests either a tooled-up criminal crew or a small custom-tool ecosystem rather than reuse of mainstream stealer-as-a-service families (RedLine, Lumma, StealC).

Defensive Posture

Patching FortiClient EMS to 7.4.7+ remediates the initial access vector. Detection focuses on (1) FortiClient EMS API access from unexpected sources or with anomalous request volume targeting Remote Access Profile endpoints; (2) GUID-named .cmd file creation under C:\Program Files\Fortinet\FortiClient\logs\Trace\scripts\; (3) parent-child anomalies where fortitray.exe or ipsec.exe spawns cmd.exe → powershell.exe with -EncodedCommand; (4) outbound TCP to 83.138.53.110 or related infrastructure; (5) network connections to nss3.dll-bearing browser process trees from non-browser parents. All credentials and session cookies on managed endpoints exposed to a vulnerable EMS should be considered compromised pending rotation.