Attackers are actively exploiting CVE-2026-35616, a critical authentication bypass in Fortinet's FortiClient Enterprise Management Server, to deploy a previously undocumented credential stealer called EKZ. Arctic Wolf observed the attacks earlier this month, finding that threat actors abused EMS's endpoint APIs to push malicious scripts through VPN workflows, disguising the payload as a legitimate Fortinet endpoint update. As reported by BleepingComputer, The Shadowserver Foundation had already flagged around 2,000 internet-exposed EMS instances at the time CISA issued its emergency directive to federal agencies.
The attack chain here is particularly damaging because the malicious payload arrives through a trusted, managed workflow. FortiClient itself, the VPN client your endpoints already trust and communicate with, is the delivery mechanism. When seconds after an IPsec tunnel is established the legitimate fortitray.exe launches batch scripts through Command Prompt, there's very little that looks anomalous to a detection rule watching for unsigned binaries or suspicious parent processes. The attacker has effectively borrowed your own tooling to do the work.
EKZ targets both Chromium-based and Firefox browsers, extracting credentials, credit card details, addresses, phone numbers, and cookies. That last category is the one you should lose sleep over. Stolen session cookies bypass MFA entirely. You don't need to crack a password or intercept a one-time code, you just replay the cookie. For organisations relying on MFA as their primary account protection layer, this removes that control without the user or your SIEM seeing anything that looks like a failed login.
The cleanup is also deliberate. According to Arctic Wolf, the malware exfiltrates harvested browser data and then removes local artefacts before the script chain ends. By the time you're investigating, the forensic trail on the endpoint itself has already been partially swept. That means your window for incident response is compressed, and you're likely relying on network telemetry and EMS logs rather than endpoint artefacts. If your logging posture on EMS administrative actions wasn't tight before this, you may not know whether you've already been hit.
Any organisation running FortiClient EMS versions prior to the emergency hotfixes is directly exposed. Fortinet released patches for versions 7.4.5 and 7.4.6 in early April after confirming active exploitation. If you're running an earlier version branch and haven't applied an equivalent fix, assume you're vulnerable.
The vulnerability is an improper access control flaw, unauthenticated remote attackers can execute arbitrary code or commands via specially crafted requests. That means internet-exposed EMS instances with no authentication requirement to reach the vulnerable endpoint are the highest-priority targets. The Shadowserver Foundation counted 2,000 such instances exposed to the internet at the time the advisory dropped. If your EMS management interface is reachable from outside your network perimeter, you're in that group.
The sectors most commonly running FortiClient EMS at scale, enterprises with distributed workforces, banks, and government agencies using centralised VPN management, are exactly the environments where the EKZ stealer's credential haul would be most valuable to an attacker. CISA's rapid directive to federal agencies reflects that the risk isn't theoretical for high-value targets. Your attack surface here extends to every managed endpoint that connects through a FortiGate firewall once EMS is compromised.
Patch immediately to EMS 7.4.5 or 7.4.6. Fortinet released emergency hotfixes for these two versions in early April following confirmed exploitation. If you're on an earlier version branch, check Fortinet's advisory for guidance on your specific release. Don't wait for your next scheduled maintenance window, this vulnerability is under active exploitation right now.
Audit EMS administrative logs for certificate authentication anomalies. Arctic Wolf identified a specific log indicator tied to exploitation attempts: the entry "Certificate not found in request header." In lab testing, this was followed within seconds by "Certificate user: fortinet-ca2 … successfully updated." Pull your EMS logs and search for this sequence. Any hit warrants immediate investigation, not a ticket in the queue.
Review Remote Access Profile configurations for unauthorised changes. The attack chain involves modifying EMS configuration and VPN policies to introduce malicious script execution. Check your Remote Access Profiles for any changes you don't recognise, particularly any additions to VPN scripting workflows. If something's been added that shouldn't be there, treat it as active compromise.
Investigate any administrative activity originating from Tor exit nodes or VPS IP ranges. Arctic Wolf flags logins from unfamiliar origins, specifically Tor and VPS IP addresses — and new account creation as red flags. Review authentication logs for your EMS instance and cross-reference source IPs against known VPS and Tor exit node ranges. Any administrative action you can't account for should be treated as suspicious.
Treat MFA as potentially bypassed for accounts on affected endpoints. EKZ specifically targets browser-stored session cookies. If any endpoint connected to a compromised EMS instance has been online since early April without patching, assume cookies may have been exfiltrated and used to establish authenticated sessions elsewhere. Force re-authentication for affected users and invalidate active sessions, particularly for privileged accounts and any SaaS applications that don't enforce short session timeouts.
No. It's an improper access control flaw that allows unauthenticated remote attackers to execute arbitrary code or commands via specially crafted requests. An attacker with network access to your EMS instance can exploit this without any prior authentication, which is why internet-exposed instances are the immediate priority.
EKZ steals browser-stored session cookies rather than passwords. A valid session cookie proves to a web application that authentication already happened — including any MFA step. Replaying that cookie elsewhere grants access without triggering any further authentication challenge, making MFA irrelevant once the cookie is in the attacker's hands.
Arctic Wolf identified "Certificate not found in request header" as an early indicator in exploitation attempts. In their lab tests, this entry appeared seconds before "Certificate user: fortinet-ca2 … successfully updated." Searching your EMS logs for this sequence is the fastest way to identify whether exploitation has been attempted against your instance.
No specific IOCs such as file hashes, IP addresses, or domain names have been published in the sources available at time of writing. Arctic Wolf's detection guidance focuses on log-based and behavioural signals rather than static IOCs, so detection should prioritise the certificate anomalies and configuration change monitoring described above.
