A Security Tool as the Weapon: Breaking Down the FortiClient EMS Campaign
Earlier this month, Arctic Wolf observed a credential theft campaign that didn't need to find a way past the endpoint security stack becuase it used the endpoint security stack.
Threat actors exploited CVE-2026-35616, a critical pre-authentication API bypass in FortiClient Endpoint Management Server, to modify EMS configuration and push a malicious PowerShell script to every managed endpoint simultaneously. The payload β a credential stealer named EKZ Infostealer β arrived disguised as a Fortinet endpoint update, executed through FortiClient's own VPN scripting workflow, harvested browser credentials, and exfiltrated them over HTTP before cleaning up its artifacts.
No separate intrusion path was required for each endpoint. Once EMS was compromised, the entire managed fleet was reachable.
This post draws on Arctic Wolf Labs' technical report published May 27, 2026, the Fortinet advisory FG-IR-26-099 for CVE-2026-35616 published April 4, 2026, and supplementary reporting from watchTowr and Cybersecurity Dive. It covers how the vulnerability was exploited, how the attack chain unfolded across managed endpoints, what the EKZ Infostealer collected, and where the defensive windows were.
The Vulnerability
CVE-2026-35616 is an improper access control vulnerability in FortiClient EMS (CVSS 9.1). FortiClient EMS is used by enterprises to centrally manage endpoint devices, enforce security policies, deploy VPN configurations, and govern compliance posture across a corporate fleet β the kind of infrastructure that sits at the center of an organization's endpoint security architecture.
The vulnerability allows an unauthenticated attacker to bypass API authentication entirely by sending specially crafted HTTP requests to certain FortiClient EMS endpoints. Those requests are processed as if they came from a legitimate administrator. From there, the attacker can interact with EMS functionality that would normally require administrative credentials.
The vulnerability was first observed being exploited in the wild on March 31, 2026 by watchTowr and Defused through honeypot sensors β before Fortinet published its advisory on April 4. CISA added it to the Known Exploited Vulnerabilities catalog on April 6, setting an April 9 remediation deadline for federal agencies. Affected versions are FortiClient EMS 7.4.5 and 7.4.6. Fortinet released hotfixes for both versions and says FortiClient EMS 7.4.7 will also include the fix.
The Incident
The campaign described here draws entirely on Arctic Wolf's May 27, 2026 technical report. No victim organizations are named in that report. The attack chain is documented from Arctic Wolf's telemetry across affected environments.
In May 2026, Arctic Wolf observed a cluster of malicious activity targeting endpoints managed by FortiClient EMS. The attack chain unfolded in three phases: exploitation of CVE-2026-35616 to gain administrative access to EMS, configuration changes that turned EMS's own management pathway into a malware delivery mechanism, and credential harvesting across the managed endpoint fleet.
The Attack Chain
Stage 1: Initial Access via Authentication Bypass
ATT&CK: T1190 (Exploit Public-Facing Application), T1078.003 (Valid Accounts: Local Accounts)
Exploitation of CVE-2026-35616 begins by sending specially crafted HTTP requests that bypass FortiClient EMS's API authentication. Arctic Wolf's lab analysis identified a consistent indicator: EMS logs show a Certificate not found in request header error, followed within seconds by a Certificate user: fortinet-ca2 β¦ successfully updated log line. In the real-world intrusions, malicious login events from Tor exit node IP addresses appeared within hours of initial exploitation β a signal that threat actors were establishing footholds through anonymized infrastructure before moving to configuration changes.
Stage 2: EMS Configuration Modification
ATT&CK: T1562.001 (Impair Defenses: Disable or Modify Tools), T1072 (Software Deployment Tools)
With administrative access established, threat actors made two targeted configuration changes. First, they modified the remind_upgrade_after setting to defer firmware upgrade reminders β suppressing a legitimate channel that might alert endpoint users to available updates. Second, and more consequentially, they edited the Remote Access Profile configuration and endpoint policy to insert a malicious script using FortiClient EMS's own on_connect directive.
FortiClient EMS supports scripts that run automatically on endpoint devices when a VPN tunnel is established. This is a documented, legitimate feature. The threat actors used it to turn every managed endpoint's next VPN connection into an execution event.
Arctic Wolf's assessment is worth quoting directly here: "Once the threat actors had a route to modify EMS-managed configuration, every managed endpoint became a potential execution target without requiring a separate intrusion path to each device." That's the architectural consequence of a compromised management plane β scale that no endpoint-by-endpoint intrusion could match.
Stage 3: Malicious Script Execution on Managed Endpoints
ATT&CK: T1059.001 (Command and Scripting Interpreter: PowerShell), T1036.005 (Masquerading: Match Legitimate Name or Location)
When affected endpoints established an IPsec tunnel, fortitray.exe β a legitimate FortiClient executable β launched a .cmd script via cmd.exe. The script files had GUIDs in their filenames and were placed in a path FortiClient uses for VPN troubleshooting logs, making the initial execution blend with legitimate FortiClient activity.
The .cmd script launched a base64-encoded PowerShell script. That script attempted to download a malicious payload using several fallback methods, ran the payload, waited 90 seconds, then exfiltrated results via HTTP POST to a threat-actor-controlled server at 83.138.53[.]110. The payload arrived on endpoints named FortiEndpoint_Patch.exe β a fake Fortinet update.
Stage 4: EKZ Infostealer Execution and Credential Harvesting
ATT&CK: T1555.003 (Credentials from Password Stores: Credentials from Web Browsers), T1539 (Steal Web Session Cookie), T1048.003 (Exfiltration Over Unencrypted Non-C2 Protocol)
EKZ Infostealer is a previously unreported Windows credential stealer, first documented by Arctic Wolf in this campaign. It targets both Chromium-family browsers (Chrome, Edge, and others) and Firefox/Gecko-family browsers (including LibreWolf, Waterfox, Pale Moon, and Thunderbird).
For Chromium browsers, the stealer locates installations through the registry, copies itself into the browser's application directory to pass Chromium Elevation Service path validation, and calls IElevator::DecryptData to obtain the master key needed to decrypt stored credentials. For Firefox-family browsers, it dynamically loads NSS and extracts credentials from key4.db, logins.json, and cookies.sqlite.
The stealer writes harvested data β passwords, cookies, autofill data including credit card details, addresses, and phone numbers β to a log file in the ProgramData directory. It lacks its own network exfiltration capability, but the PowerShell script handles transmission to 83.138.53[.]110/service/save.php via HTTP POST. Local artifacts are deleted afterward.
The cookie harvesting is worth specific attention. Session cookies captured here can allow threat actors to authenticate to cloud services, internal applications, and other resources as the legitimate user β including bypassing MFA prompts where session reuse is accepted. The credential exposure extends significantly beyond whatever was on the endpoint at the time of compromise.
Where Defenders Had a Window
1. EMS management interface exposure. CVE-2026-35616 requires network access to the FortiClient EMS management port. Organizations that restricted access to the management interface (port 8013) to internal subnets or trusted IP ranges were not exposed to unauthenticated exploitation from the internet. This is the architectural control that makes the vulnerability a non-event for well-configured environments.
2. EMS log monitoring for exploitation indicators. Arctic Wolf documented a specific, detectable log signature: Certificate not found in request header followed within seconds by Certificate user: fortinet-ca2 β¦ successfully updated. Organizations with EMS log ingestion into a SIEM had visibility here β the exploitation attempt leaves a trace before configuration changes begin.
3. Remote Access Profile configuration change alerting. Modification of the on_connect directive in a Remote Access Profile is a high-signal event when it appears without a corresponding change request. Organizations that log and alert on EMS configuration changes would have seen the insertion of the malicious script before it executed on endpoints.
4. Process tree monitoring on managed endpoints. The execution chain β fortitray.exe or ipsec.exe β cmd.exe β powershell.exe downloading a binary from an external IP β is detectable through endpoint telemetry. Specifically, PowerShell launched by cmd.exe from within the FortiClient log trace path, downloading and executing a binary, is anomalous regardless of how legitimate the parent process looks. The GUID-named .cmd files in the trace path are also a specific indicator.
5. Network monitoring for raw IP HTTP activity. Outbound HTTP connections to a raw IP address, particularly download followed shortly by POST to the same host, are detectable at the network layer. The infrastructure here was not particularly evasive β the same IP served both the payload and received the exfiltrated credentials.
Technique in Focus: Abusing Trusted Management Infrastructure
The tradecraft in this campaign reflects a pattern appearing with increasing frequency: rather than fighting through endpoint defenses, threat actors compromise the management plane that controls those endpoints.
FortiClient EMS is trusted to push configurations, enforce policies, and execute scripts on managed endpoints. That trust makes a compromised EMS server a multiplier β a single administrative access point that reaches the entire managed fleet simultaneously and in a way that resembles legitimate operations.
The EKZ Infostealer payload was tightly adapted to this delivery mechanism. It arrived named as a Fortinet patch, executed through FortiClient's own VPN scripting workflow, and its artifacts were placed in a path associated with legitimate FortiClient logging. On the endpoint, the process tree starts with a legitimate FortiClient binary. Each layer of the chain is designed to look like something that should be there.
This is not novel as a concept β the SolarWinds supply chain attack documented the same architectural principle at scale in 2020. What's notable here is how precisely the campaign's tooling was adapted to the specific trusted pathway FortiClient EMS provides. The threat actors built a fake patch that fit the exact update mechanism their targets would recognize.
Takeaway for Defenders
For security teams evaluating management plane risk more broadly: an organization's endpoint management infrastructure β EMS, SCCM, Intune, RMM platforms β represents a high-value attack surface precisely because of the trust it holds. Compromising a management server is not equivalent to compromising one endpoint. It's equivalent to compromising every endpoint the server manages, simultaneously, through a channel that looks like normal operations.
Sources
Arctic Wolf Labs, "FortiClient EMS Exploited via CVE-2026-35616 to Deliver EKZ Infostealer Disguised as a Fortinet Patch," May 27, 2026: arcticwolf.com
Arctic Wolf Labs, IOCs and binary payloads: github.com/rtkwlf
Fortinet Security Advisory FG-IR-26-099, CVE-2026-35616, April 4, 2026: fortiguard.com
watchTowr, "Fortinet FortiClient EMS Zero-Day: CVE-2026-35616 (Active Exploitation Underway)": watchtowr.com
Cybersecurity Dive, "Critical flaw in FortiClient EMS under exploitation," April 6, 2026: cybersecuritydive.com
MITRE ATT&CK Framework: attack.mitre.org