By Nilaa Maharjan, Security Research.
Fortinet disclosed a zero-day vulnerability in its FortiOS SSL-VPN products in December 2022, which was discovered to have been exploited by ransomware gangs.
The vulnerability, a heap-based buffer overflow, was silently patched in November but details were not disclosed until December when it was assigned a CVSSv3 score of 9.3 (CVE-2022-42475). Fortinet recommends organizations to apply the patches as soon as possible to mitigate the risk, or if unable to do so, to disable the SSL-VPN device temporarily.
The new malware instance “BOLDMOVE” is being attributed to Chinese Advanced Persistent Threat (APT) groups who are actively exploiting the vulnerability.
** Get research and analysis, insight, plus hints and tips, on how to mitigate BOLDMOVE in the main blog below.
Head to the contents and click each section for quick navigation.
FortiOS SSL-VPN products are vulnerable to a heap-based buffer overflow. The vulnerability has been assigned CVE-2022-42475 with a CVSSv3 score of 9.3.
At least one instance where threat actors exploited this vulnerability in the wild.
Fortinet has provided patches to mitigate the vulnerability. If unable to apply patches immediately, Fortinet recommends organizations disable the SSL-VPN device.
New malware instance BOLDMOVE is being attributed to Chinese APTs who are exploiting it actively.
Which Products and Versions are Affected?
The malware affects all the products and versions vulnerable to the CVE-2022-42475 vulnerability. See them in the list below:
v7.2.0 to v7.2.2
v7.0.0 to v7.0.8
v6.4.0 to v6.4.10
v6.2.0 to v6.2.11
v6.0.0 to v6.0.15
v5.6.0 to v5.6.14
v5.4.0 to v5.4.13
v5.2.0 to v5.2.15
v5.0.0 to v5.0.14
v7.2.3 or above
v7.0.9 or above
v6.4.11 or above
v6.2.12 or above
v6.0.16 or above (upcoming)
v7.0.0 to v7.0.7
v6.4.0 to v6.4.9
v6.2.0 to v6.2.11
v6.0.0 to v6.0.14
v7.0.8 or above
v6.4.10 or above
v6.2.12 or above
v6.0.15 or above
Plan of Action:
We recommend that users who are unable to upgrade immediately disable the web console from the public network and hide the admin console behind a VPN Firewall to view it from a remote location. Furthermore, Fortinet recommended that customers check their systems quickly against the following indicators of compromise:
Indicators of Compromise Relating to BoldMove (Updated as of January 2023)
Be On the Lookout (BOLO)
According to Fortinet, organizations should audit and monitor their devices for the following indicators and artifacts:
Multiple log entries with:
Logdesc=”Application crashed” and msg=”[…] application:sslvpnd,[…], Signal 11 received, Backtrace: […]“
Presence of the following artifacts in the filesystem:
Connections to the following IP addresses or suspicious IP addresses from the FortiGate:
18.104.22.168:444 [Germany; Hetzner Online AG]
22.214.171.124:30080,30081, 30443, and 20443 [Taiwan; Soon Keat Neo]
126.96.36.199:8443 and 444 [Sweden; Resilans AB]
188.8.131.52:8033 [USA; CloudRadium L.L.C]
What to do if you use Logpoint
Alternatively, we have pushed out a few alerts that one can use to detect the issue in the form of plug-and-play.
These detection rules are available as part of Logpoint’s latest alert release, as well as through
Logpoint’s Download Center
In December of 2022, Fortinet disclosed a zero-day vulnerability that affected most of its FortiOS versions, which was soon found to be used in the wild by a few ransomware gangs. The vulnerability is said to have been silently patched in early November but no details were assigned. Even the CVE assigned was mostly “RESERVED” for the better half of the month until finally being disclosed as a heap-based buffer overflow with a CVSSv3 score of 9.3 and assigned CVE-2022-42475.
Though, that isn’t the crux of the issue as no public Proof of Concept(PoC) is currently available and there are patches available for each version. The concern arises when the vulnerability is being actively searched by researchers and adversaries checking for its presence.
From CVE Trends (29th January),
Past 24 hrs: CVE-2022-42475: 327.9K (audience size) CVE-2022-46689: 191.1K CVE-2022-27596: 159.2K Past 7 days: CVE-2022-31706: 3.2M CVE-2022-31704: 3.2M CVE-2023-24055: 2.4M
The flaw, when properly exploited, results in allowing remote unauthenticated attackers to crash targeted devices remotely or gain remote code execution. This is all we had to go on until this month when Fortinet shared more details about how hackers exploited it, explaining that threat actors had targeted government entities with custom malware specifically designed to run on FortiOS devices.
Origins and who it has impacted so far
So far, evidence suggests the exploitation started occurring as early as October 2022, and identified targets include a European government entity and a managed service provider located in Africa.
This is expected to be a part of a long series of attacks involving Chinese adversaries using public-facing applications and is likely to increase in the future. The attackers are intent on maintaining persistence on attacked devices by deploying the malware to alter the FortiOS logging processes so that certain log entries could be erased or the logging process could be disabled entirely. These devices are appealing targets for a variety of reasons.
For example, they have an internet connection, and if the attacker has an exploit, they can acquire network access without requiring any victim input. This gives the attacker control over the time of the operation and reduces the likelihood of detection.
Making a BOLD statement
There wasn’t much of a PoC for most of January regarding CVE-2022-4245. And it has been a consistent part of our research. Eventually, we started looking at older Fortinet SSL VPN vulnerabilities to get a sense of what might be happening. An interesting read was the 2018 CVE CVE-2018-13381: Pre-auth heap overflow, similar to the heap overflow issue that is plaguing the current threat landscape. Meh Chang(@mehqq_) and Orange Tsai(@orange_8361) have an amazing blog where they were able to chain multiple Fortinet CVEs to create a reverse shell. The report explains crucial insight into Fortinet architecture for those who want to have a read.
With what we were able to gather, traditional heap overflow exploits need to combine heap-related management logic to control program execution flow by carefully controlling the heap block arrangement. But as the DEVCORE article and fuzzing results from Wanhe Songfeng’s PoC show, the heap overflow on FortiGate will overwrite the data in some key structures in the heap, specifically the SSL structure pointer of the HTTP request. By sending a lot of normal HTTP requests before triggering the vulnerability, many SSL structures will be left in the heap, and then trigger the heap overflow to cover these structures. When the program calls the handshake_func pointer in the overwritten structure, we can Directly hijack program control flow.
From Fortigate, the complexity of the exploit suggests an advanced actor:
The exploit requires a deep understanding of FortiOS and the underlying hardware.
The use of custom implants shows that the actor has advanced capabilities, including reverse-engineering various parts of FortiOS.
The actor is highly targeted, with some hints of preferred governmental or government-related targets.
The discovered Windows sample attributed to the attacker displayed artifacts of having been compiled on a machine in the UTC+8 timezone, which includes Australia, China, Russia, Singapore, and other Eastern Asian countries.
The self-signed certificates created by the attackers were all created between 3 and 8 AM UTC. However, it is difficult to draw any conclusions from this given hackers do not necessarily operate during office hours and will often operate during victim office hours to help obfuscate their activity with general network traffic.
More to the drama, Mandiant researchers have discovered a sophisticated new malware named BOLDMOVE, created specifically to exploit this particular vulnerability. The malware is believed to be developed by a threat actor with a base in China that conducts cyberespionage activities against individuals and groups linked with the government but no definitive proof has been found linking them to any specific APT.
The attackers created not only an exploit, but malware that demonstrates in-depth expertise in systems, services, logging, and undocumented proprietary formats. “The attackers not only constructed an exploit, but malware that demonstrates an in-depth expertise of systems, services, logs, and undocumented proprietary formats” with BoldMove, according to Mandiant. However, the payback for attackers can be substantial because a successful vulnerability grants them broad access to a network without requiring any user engagement, according to the security provider.
While Fortinet devices have been a particularly attractive target in this regard, threat actors have also targeted products from other vendors, such as Pulse Secure VPNs, Citrix ADCs, and SonicWall. The FBI, the US Cybersecurity and Information Security Agency (CISA), and others have issued many cautions in response to the attacks. Malware running on an internet-connected device can enable lateral network movement as well as command and control (C2) by tunneling commands and data into and out of a network and should be considered a major threat.
Boldly going where no malware has gone before
The malware was first discovered with the use of the BOLDMOVE backdoor connected with the exploitation of the CVE-2022-49475 FortiOS vulnerability in December 2022. BOLDMOVE is written in C and comes in Windows and Linux versions, with the latter meant to function (at least in part) on Fortinet devices because it pulls data from a Fortinet-proprietary file.
Mandiant discovered various versions of BOLDMOVE with differing capabilities, but the following traits were observed in all samples:
Strange C2 (command and control) server communications.
A remote shell on the host.
Redirecting traffic through the compromised device.
BOLDMOVE commands enable threat actors to remotely manage files, run commands, create interactive shells, and control backdoors.
The Windows and Linux editions are nearly identical but use different libraries, and Mandiant believes the Windows variant was compiled in 2021, nearly a year before the Linux variant.
We are yet to see the vulnerability used personally amongst any of our clients, nevertheless, copies of the BOLDMOVE Linux variant had a hard-coded C2 IP address that Fortinet identified as being involved in the exploitation, implying CVE-2022-49475 was exploited to distribute BOLDMOVE.
Currently, both Windows and Linux variants are available in sandboxing environments and allow for somewhat of an analysis similar to the one provided later on in the report.
Differences between the Windows and Linux variants of BOLDMOVE:
C and compiled with MinGW
(GCC: (GNU) 10.2.1 20210227)
Compile Time: 2021-08-26 07:13:04
C and compiled with GCC 11.2.1 20211120
Compile Time: Unknown
(this is a non-public version of libcurl, last v6 build was 6.5; also, the malware itself does not make actual use of libcurl)
|Private class C IP Address
|Globally routable IP Address
|Supports light weight systems
Uses an event-driven model wherein event callbacks are used instead of threads. This is facilitated by a library like the one leveraged by the Linux variant of BOLDMOVE, however, the reason for using it in Windows is unclear.
Uses an event-driven model, wherein event callbacks are used instead of threads
Musl is compiled statically into the malware’s binary image. Musl has been associated for its lighter utilization of resources in comparison to other libc variants.
WolfSSL which is used by the malware for encrypting traffic to the C2 is also designed in part with embedded devices in mind.
Established connection packets are encrypted with Salsa20:
Key: <8_byte_pseudorandom_nonce> || “e8dm_$Gb”
Established sessions are encrypted with AES128:
Key: <8_byte_pseudorandom_nonce> || “rg8P@TD(“
IV: <8_byte_pseudorandom_nonce> || “e5sm_$Gb”
(other campaign names were observed in different samples of the Linux variant)
Windows x Linux
Not much is available on the vulnerability and its exploitation but at least one Linux iteration can modify the behavior and functionality of Fortinet firewalls. However, from Fortinet communities, exploiting the vulnerability means that any device running vulnerable versions and having SSLVPN enabled does not require any authentication to the server. As a result, it does not matter if you are using MFA/2FA or not.
Mandiant on the other hand has analyzed the Linux variant of the malware and has shown how it works to take over the device and use it as a gateway for their purposes. As a security defender, from the information we could gather, it’s important to take this incident as a case study of how even a single vendor-specific vulnerability could lead to disastrous chain effects.
Among other things, the malware supports commands to list file metadata, create/delete folders, move and replace files, run shell commands, build an interactive shell, and delete and replace itself.
Boldmove’s expanded version may disable particular Fortinet daemons, prohibit logging, edit proprietary Fortinet logs on the system, deploy a watchdog that allows it to persist between upgrades, and will enable attackers to submit requests to an internal Fortinet service.
Depending on the logging available on the Fortinet devices, a wide range of detection queries can be created.
Log sources needed
Detecting BOLDMOVE using Logpoint
Most of this malware is very tame compared to other malware so far. Most of the malware detection queries should work while we wait for more details.
Strange C2 (command and control) server communications.
A remote shell on the host.
Redirecting traffic through the compromised device.
We know for a fact that some sort of privilege escalation takes place to make the vulnerability work. A simple investigation query might be used to detect an escalation preparation. However, the query tends to be very noisy in case of a troubleshooting event.
Alternatively, using auditd events, we can check for any suspicious process executions.
A surefire way to confirm an attack as of now is to check any source or destination addresses on the provided IP addresses. The list is updated as of February 1st, 2023.
Firstly, the attack usually starts by crashing the device. Monitoring system crashes should always be a priority. The following query will check for any crashes that occur in the SSL VPN application.
Also, once the attackers successfully compromise the device, a trail of files is modified. Checking for the existence of any of the following files might be a good starting point for a post-compromise investigation.
Since there is evidence of logs being stopped or disabled, the following alert queries should be able to detect any attempts. However, investigators might have to edit queries accordingly.
The exact path for storing Fortinet system logs on the internal memory of the device depends on the Fortinet model and operating system version. However, they can typically be found and viewed in the web-based GUI of the device under the “Log & Report” or “Monitor” section.
If you are using FortiOS 6.0 or later, the log files are stored in the /var/log directory. For earlier versions, logs can be found in the /usr/local/fortianalyzer/var/log directory. Note that accessing these log files directly may require administrative access to the device and should only be performed by experienced users.
According to Fortinet, the best solution is to patch the system, something that has been available for over a month now. Other than the CVE alone, the patch is a huge deterrent for the BOLDMOVE malware until the adversaries decide to change their TTP. We will continue to track this threat actor activity and push out detection and mitigation steps as we find them. To mitigate this issue, we recommend that all affected customers immediately take the actions recommended in the blog and from the report by Fortigate, FG-IR-22-398. Additional guidance has been provided here for how to search for the IoCs.
Investigation and response with Logpoint
The first step that should be considered during an investigation of CVE-2022-42475 is to check if any of the devices are running vulnerable versions.
The necessary steps in investigating post-compromise activity include inspecting:
If any accounts have been compromised, passwords are changed, or are receiving unusual logins, emails, or requests from any users.
Any traffic has been found between the compromised domains.
Unusual files have been downloaded or files have been rapidly modified.
Commands that have used generic evasion techniques.
Known vulnerabilities that are yet to be patched in the network.
Processes being attributed to suspicious parent processes or are being run from unusual sources.
Credential dumping attempts.
Disabling important features including but not limited to the crash dump feature.
Logs are being cleared.
Suspicious scheduled tasks are being created.
Unusual Remote Access Tools (RATs) making connections.
Security settings are being changed rapidly.
In no way would monitoring for the listed activities eliminate the chance of being compromised, but would provide basic coverage of any attempt when added to existing company cybersecurity policies.
Logpoint SOAR’s automated playbooks will help you rapidly investigate and respond to BOLDMOVE. These playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail each step for both incident and vulnerability detection.
The main playbook for investigation, with its multiple sub-playbooks, goes deep into detection and investigation if an attack has taken place.
If and when an active attack has been detected, an organization should always follow the already set internal IT and Security guidelines. Plenty of resources are available to create and follow. Some notable ones are provided by CISA, FBI, and frameworks by NIST.
The most common recommendation we usually give out to respond to exploitation is to isolate the system. But since Fortigate devices are a business-critical system, it would be illogical to do so.
The first step should instead be to take a digital snapshot of the device first.
Isolate the affected firewall: Disconnect the firewall from the network to prevent the spread of the exploit.
Gather Information: Collect as much information as possible about the exploit, including the time it was detected, the type of exploit used, and the extent of the damage.
Assess the damage: Evaluate the impact of the exploit on the organization’s systems, networks, and data.
Secure Backups: Ensure that all critical data has been backed up and is secure.
Contain the Exploit: Implement security measures to prevent the exploit from spreading further.
Repair the firewall: Remove the exploit and repair the firewall to its original state. This may require patching or updating the firewall software.
Monitor the network: Continuously monitor the network for any signs of further exploitation or attack.
Update incident response plan: Update the incident response plan based on lessons learned from this incident, to improve the organization’s ability to respond to future incidents.
Notify Stakeholders: Inform relevant stakeholders of the incident, including senior management, clients, and regulatory agencies if necessary.
Perform Post-Incident Review: Conduct a thorough review of the incident response process to identify areas for improvement.
Logpoint SOAR comes with out-of-the-box playbooks that help automate some of these processes, but given the severity, some of the tasks should be performed manually. An example could be to block malicious indicators.
This playbook checks if any IP, domain, URL, or host exists in a list of IoCs, block them, and adds them to the blocked list.
Update and patch systems as soon as possible. Prioritize patching vulnerabilities identified including but not limited to CVE-2022-42475.
Restrict admin panel and login access to office IP addresses.
Utilize phishing-resistant multi-factor authentication whenever possible. Require all accounts with password logins to have strong, unique passwords, and change passwords immediately if there are indications that a password may have been compromised.
Block obsolete or unused protocols at the network edge.
Upgrade or replace end-of-life devices.
Move toward the Zero Trust security model.
Enable robust logging of Internet-facing systems and monitor the logs for anomalous activity.
Continuously monitor critical organizational assets with a combination of tools such as Sysmon and the Logpoint Converged SIEM platform.
The emergence of BOLDMOVE is but a stepping stone in a long line of attacks soon to follow in adversaries exploiting perimeter vulnerabilities to spread new forms of malware and must be cause for concern. The increasing sophistication and reach of these cyber-attacks highlight the need for organizations to stay vigilant and proactive in their cybersecurity efforts.
This case is a strange one in that native security methods do not adequately secure these devices and determining what processes are running on these devices is difficult.
All organizations must take immediate steps to ensure the security of their systems. The first and most critical step is to patch all known vulnerabilities, especially those in the firewall. If the patches cannot be applied immediately, users are advised to check logs, disable VPN-SSL, and set up access rules to only permit connections from specific IP addresses.
With the Logpoint Converged SIEM platform combining SIEM, SOAR, BCS for SAP and endpoint response, analysts can investigate this and other new CVEs that might arise. Good luck with hunting and patching away!
** We can help you! For help with the suggested playbooks – design, development, and implementation – contact Global services here.