Written by: Foti Castelan, Max Thauer, JP Glab, Gabby Roncone, Tufail Ahmed, Jared Wilson

Summary

In October 2024, Mandiant collaborated with Fortinet to investigate the mass exploitation of FortiManager appliances across 50+ potentially compromised FortiManager devices in various industries. The vulnerability, CVE-2024-47575 / FG-IR-24-423, allows a threat actor to use an unauthorized, threat actor-controlled FortiManager device to execute arbitrary code or commands against vulnerable FortiManager devices. 

Mandiant observed a new threat cluster we now track as UNC5820 exploiting the FortiManager vulnerability as early as June 27, 2024. UNC5820 staged and exfiltrated the configuration data of the FortiGate devices managed by the exploited FortiManager. This data contains detailed configuration information of the managed appliances as well as the users and their FortiOS256-hashed passwords. This data could be used by UNC5820 to further compromise the FortiManager, move laterally to the managed Fortinet devices, and ultimately target the enterprise environment.

At this time, the data sources analyzed by Mandiant did not record the specific requests that the threat actor used to leverage the FortiManager vulnerability. Additionally, at this stage of our investigations there is no evidence that UNC5820 leveraged the obtained configuration data to move laterally and further compromise the environment. As a result, at the time of publishing, we lack sufficient data to assess actor motivation or location. As additional information becomes available through our investigations, Mandiant will update this blog’s attribution assessment.

Organizations that may have their FortiManager exposed to the internet should conduct a forensic investigation immediately.

Exploitation Details

Mandiant’s earliest observed exploitation attempt occurred on June 27, 2024. On that day, a FortiManager device received inbound connections from the IP address 45[.]32[.]41[.]202 on the default port TCP/541. At approximately the same time, the file system recorded the staging of various Fortinet configuration files in a Gzip-compressed archive named /tmp/.tm. This archive contained the files and folders as listed in Table 1.

On Sept. 23, 2024, Mandiant observed a second exploitation attempt with the same indicators. In both exploitation events, outbound network traffic occurred shortly after the archive creation. The amount of bytes sent to the respective destination IP addresses are slightly larger than the size of the archive. Table 2 lists the details of this activity.

During the second exploitation attempt, the threat actor’s device was registered to the targeted FortiManager. Figure 1 lists the unauthorized FortiManager in the Global Objects database along with the timestamp when it was added.

Once the threat actor successfully exploited the FortiManager, their unknown Fortinet device appeared in the FortiManager console.

An additional indicator of successful exploitation is the addition of the unauthorized device serial number “FMG-VMTM23017412” and its corresponding IP address 45[.]32[.]41[.]202 to the file /fds/data/unreg_devices.txt. Figure 3 lists the content of this file.

FMG-VMTM23017412|45.32.41.202

Figure 3: Content of /fds/data/unreg_devices.txt

The files /fds/data/subs.dat and /fds/data/subs.dat.tmp contain additional indicators of the exploitation that include an associated disposable email address and a company name as listed in Figure 4.

SerialNumber=FMG-VMTM23017412|AccountID=
[email protected]|Company=Purity Supreme|UserID=1756868

Figure 4: Content of /fds/data/subs.dat

Mandiant scraped the FortiManager’s memory image for additional artifacts of threat actor activity and detected a JSON blob containing the keywords “FMG-VMTM23017412” and “45[.]32[.]41[.]202”. This JSON blob also included a “first_tunnel_up” key, which contained the epoch time of 1726999303 as its value. This timestamp translates to 2024-09-22 10:01:43 UTC.

Lack of Follow-On Malicious Activity

Mandiant reviewed the rootfs.gz, which is an initramfs (RAM disk) for the device that gets mounted to /bin. We did not find any malicious files created or modified during the time frame of exploitation activity. 

Google Cloud notified affected customers who showed similar activity in their environments. Additionally, Google Threat Intelligence ran retrohunts while developing detections for this activity and manually escalated Pre-Release Detection Rule alerts to affected SecOps customers to assist with detecting exploit attempts of Fortinet devices.

In addition to collaborating with Mandiant, Fortinet proactively sent advance communications to its customers as an early warning on their advisory to enable customers to strengthen their security posture prior to broad public disclosure.

Timeline of Threat Actor Activity

Mitigation Strategies / Workaround

Limit access to FortiManager admin portal for only approved internal IP addresses.

Only allow permitted FortiGate addresses to communicate with FortiManager.

Deny unknown FortiGate devices from being associated with FortiManager.

Available 7.2.5, 7.0.12, 7.4.3 and later (not functional workaround on 7.6.0).

config system global
set fgfm-deny-unknown enable
end

Figure 7: Configuration to deny unknown devices

Detection

YARA-L

If you are a Google SecOps Enterprise+ customer, rules were released to the “Mandiant Intel Emerging Threats” rule pack (within the Windows Threats group), and IOCs listed in this blog post are available for prioritization with Applied Threat Intelligence.

Relevant Rules

Suspicious FortiManager Inbound and Outbound Connection
UNC5820 Fortinet Exploitation and File Download
UNC5820 Fortinet Exploitation and non-HTTPS Command and Control
UNC5820 Fortinet Exploitation and HTTPS Command and Control

Other SIEMs

Develop searches against Fortiguard logs for the following relevant IOCs. In particular, the Malicious Fortinet Device ID should provide a high fidelity alert if triggered.

Baseline and set thresholds for unique operations in the FortiManager logs. In particular, operations for “Add device” and “Modify device” may be rare enough for your organization to provide an actionable alert until this vulnerability can be patched.

Similarly, baseline and set thresholds for the changes field in the FortiManager logs, and consider a higher sensitivity when the changes field includes the word ‘Unregistered’.

Enumerate the Fortigate devices daily, and alert when a previously unseen device name is observed in the logs. 

Indicators of Compromise

Network-Based IOCs

Host-Based IOCs

Additional Keywords