Mandiant and Fortinet worked together in October 2024 to look into the widespread abuse of FortiManager appliances across more than fifty potentially compromised FortiManager devices in a range of businesses. A threat actor can use an unauthorized, threat actor-controlled FortiManager device to run arbitrary code or commands against susceptible FortiManager devices with the vulnerability, CVE-2024-47575 / FG-IR-24-423.
As early as June 27, 2024, Mandiant saw a new threat cluster that is currently monitor as UNC5820 taking advantage of the FortiManager vulnerability. The configuration information of the FortiGate devices controlled by the compromised FortiManager was staged and exfiltrated by UNC5820. Along with the users and their FortiOS256-hashed passwords, this data includes comprehensive configuration details for the controlled equipment. UNC5820 might utilize this information to target the enterprise environment, advance laterally to the controlled Fortinet devices, and further attack the FortiManager.
The precise requests that the threat actor made in order to take advantage of the FortiManager vulnerability were not yet documented in the data sources that Mandiant examined. Furthermore, as of this point in Google cloud study, there is no proof that UNC5820 used the configuration data it had acquired to migrate laterally and endanger the environment even more. It therefore don’t have enough information at the time of publication to evaluate actor location or motivation. Mandiant will update this blog’s attribution assessment as new information emerges from investigations.
A forensic investigation should be carried out right away by any organizations whose FortiManager may be exposed to the internet.
Exploitation Details
The first known instance of Mandiant being exploited was on June 27, 2024. Several FortiManager devices were connected to the default port TCP/541 on that day via the IP address 45[.]32[.]41[.]202. Around the same time, the file system stored the staging of different Fortinet configuration files in an archive called /tmp/.tm that was compressed using Gzip. The files and folders mentioned in below Table were included in this bundle.
Filename | Description |
/var/dm/RCS | Folder containing configuration files of managed FortiGate devices |
/var/dm/RCS/revinfo.db | Database containing additional information of the managed FortiGate devices |
/var/fds/data/devices.txt | Contains a list of FortiGate serials and their corresponding IP addresses |
/var/pm2/global.db | Global database that contains object configurations, policy packages, and header and footer sensor configuration for IPS |
/var/old_fmversion | Contains current FortiManager version, build, and branch information |
Mandiant noticed a second attempt at exploitation using the same symptoms on September 23, 2024. Outgoing network traffic happened soon after the archive was created in both exploitation scenarios. The size of the archive is marginally less than the number of bytes delivered to the corresponding destination IP addresses. The specifics of this action are listed in below Table .
Timestamp | Description | Size |
2024-06-27 12:44:04 | /tmp/.tm (File creation) | Unknown |
2024-06-27 12:44:11 | Outbound traffic to 195[.]85[.]114[.]78:443 | 1,819,425 bytes |
2024-09-23 11:31:12 | /tmp/.tm (File modification) | 1,772,650 bytes |
2024-09-23 11:31:19 | Outbound traffic to 104[.]238[.]141[.]143:443 | 1,822,968 bytes |
The threat actor’s device was linked to the targeted FortiManager during the second exploitation attempt. Figure shows the timestamp at which the illegal FortiManager was introduced to the Global Objects database.
The threat actor’s unknown Fortinet device showed up in the FortiManager console after they had successfully exploited the FortiManager.
The inclusion of the unauthorized device serial number “FMG-VMTM23017412” and its associated IP address 45[.]32[.]41[.]202 to the file /fds/data/unreg_devices.txt is another sign of successful exploitation. The contents of this file are listed in Figure .
FMG-VMTM23017412|45.32.41.202
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 .
SerialNumber=FMG-VMTM23017412|AccountID=
0qsc137p@justdefinition.com|Company=Purity Supreme|UserID=1756868
Lack of Follow-On Malicious Activity
Mandiant examined rootfs.gz, the device’s initramfs (RAM disk) that is mounted to /bin. During the period of exploitation activity, did not discover any malicious files that had been produced or altered.
Affected clients who displayed comparable activities in their environments were alerted by Google Cloud. In order to help identify Fortinet device exploit attempts, Google Cloud Threat Intelligence also conducted retrohunts while creating detections for this activity and manually escalated Pre-Release Detection Rule notifications to impacted SecOps customers.
Apart from working with Mandiant, Fortinet made aggressive efforts to notify its clients in advance of their advise so that they may improve their security posture before it was widely made public.
Mitigation Strategies / Workaround
- Restrict only authorized internal IP addresses from accessing the FortiManager admin portal.
- Permitted FortiGate addresses should be the only ones allowed to connect to FortiManager.
- Deny FortiManager access to unidentified FortiGate devices.
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
Detection
YARA-L
IOCs mentioned in this blog post can be prioritized using Applied Threat Intelligence, and rules were released to the “Mandiant Intel Emerging Threats” rule pack (in the Windows Threats group) if you are a Google SecOps Enterprise+ customer.
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
Create searches for the following pertinent IOCs using Fortiguard logs. Specifically, if activated, the Malicious Fortinet Device ID need to deliver a high quality alert.
In the FortiManager logs, establish baselines and thresholds for distinct processes. Specifically, “Add device” and “Modify device” procedures can be infrequent enough for your company to issue a useful warning until this vulnerability is fixed.
In the FortiManager logs, baseline and establish thresholds for the changes field. When the word “Unregistered” appears in the changes field, take into account a higher sensitivity.
Every day, count the Fortigate devices and notify you when a device name that hasn’t been seen in the logs is detected.
Indicators of Compromise (IOCs)
Registered users can access a Google Threat Intelligence Collection of IOCs.
Network-Based IOCs
IOC | Description |
45.32.41.202 | UNC5820 |
104.238.141.143 | UNC5820 |
158.247.199.37 | UNC5820 |
195.85.114.78 | UNC5820 |
Host-Based IOCs
IOC | Description |
.tm | Archive of config files |
9DCFAB171580B52DEAE8703157012674 | MD5 hash of unreg_devices.txt |
Additional Keywords
Keyword | Description |
FMG-VMTM23017412 | Malicious Fortinet Device ID |
msg=”Unregistered device localhost add succeeded” | String indicating exploitation in /log/locallog/elog |
changes=”Edited device settings (SN FMG-VMTM23017412)” | String indicating exploitation in /log/locallog/elog |
changes=”Added unregistered device to unregistered table.” | String indicating exploitation in /log/locallog/elog |
0qsc137p@justdefinition.com | Observed in subs.dat and subs.dat.tmp. This is a disposable email address created by the threat actor. |
Purity Supreme | Observed in subs.dat and subs.dat.tmp |