Abusing Trust: FortiClient EMS Exploitation (CVE-2023-48788) Analysis
Hey everyone,
Just reviewing the latest IOCs from the Arctic Wolf report concerning the exploitation of CVE-2023-48788 in FortiClient EMS. It's a textbook example of "abusing the trusted land." The attackers are leveraging a critical SQL injection vulnerability (SQLi) in the FCTUID parameter to achieve RCE on the management server.
What makes this campaign particularly nasty is the payload delivery mechanism. Instead of dropping a generic malicious executable, the threat actors are disguising the credential stealer as a legitimate Fortinet endpoint component. This poses a significant challenge for allowlisting controls, as the file appears trusted at a glance.
Technical breakdown indicates that the SQLi allows for stacked queries, enabling the attacker to write web shells or execute commands directly. Since the EMS service often runs with high privileges, the impact is immediate credential theft via tools like Mimikatz once they have a foothold.
I've put together a KQL query for hunting suspicious child processes spawned by the EMS service, which shouldn't typically be spawning shells:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "FCTEMS.exe" or InitiatingProcessFileName =~ "java.exe"
| where FileName in~ ("powershell.exe", "cmd.exe", "whoami.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
This is a high-fidelity signal for this specific attack chain.
Given the ubiquity of Fortinet gear, how is everyone handling the patching latency? Are you isolating your EMS management interfaces from the internet entirely, or do you rely strictly on WAFs?
Good catch on the child process hunting. We actually saw some weird base64 encoded strings in the web server logs before the shell spawned. If you have access to the access logs, look for long URL-encoded strings hitting the /EMS/API. endpoints. It’s a tell-tale sign of the SQLi probe. Also, verify if the FortiClientEMS.exe process is making unexpected outbound connections to non-FortiGuard IPs.
Patching EMS is always a headache because of the agent connectivity drop. We're debating setting up a dedicated jump host just to manage the update deployment to minimize downtime. The fact that they're disguising malware as trusted components is scary—auditing our signed binaries now. Any recommendations for tools that can verify the digital signature integrity of files in real-time without killing CPU performance?
From a red team perspective, this is a perfect initial access vector. Admins often forget that the management console is just another web app with a database backend. If they haven't patched, the SQLi is trivial. The "trusted" payload disguise is just the cherry on top to bypass EDR heuristics. I'd recommend running a vulnerability scan specifically on port 443 of your EMS servers if you haven't already.
Great discussion. Since the injection point is the FCTUID parameter, you can quickly scan your Nginx access logs for obvious SQLi syntax mixed in there. If you have shell access, try this to flag potential attempts:
grep "FCTUID=" /var/log/nginx/access.log | egrep -i "(union select|' or '|1=1|--)"
It's a noisy regex but effective for a first pass before deep-diving into the Base64 payloads.
Great breakdown. Once they achieve RCE, they often drop payloads in obscure temp directories with obfuscated names. If you're triaging, don't forget to check the FortiClient EMS installation path for recently created binaries. I usually scan for executables created around the time of the suspicious FCTUID requests.
Get-ChildItem "C:\Program Files (x86)\Fortinet\FortiClientEMS\" -Recurse -Filter *.exe | Where-Object {$_.CreationTime -gt (Get-Date).AddHours(-24)} | Select-Object FullName, CreationTime
This helps correlate the web shell activity with the dropped payload.
Since patching can be delayed, validating process lineage is crucial for containment. We noticed that successful exploitation results in the web server process spawning an unauthorized shell.
To triage a potentially compromised server, check if the EMS service has spawned cmd.exe or powershell.exe using this PowerShell snippet to query Sysmon:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} | Where-Object { $_.Message -match 'ParentImage.*EMS' -and $_.Message -match 'Image.*powershell.exe' } | Select-Object TimeCreated, Message
This helps confirm the RCE vector quickly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access