MOVEit SQLi Zero-Day (CVE-2023-34362) Exploited by CL0P Ransomware Group
by Ori David, Sam Tinklenberg, Maxim Zavodchik, and Ophir Harpaz
Executive summary
On May 31, 2023, Progress Software began warning customers of a previously unknown vulnerability in MOVEit Transfer and MOVEit Cloud software. The SQL injection (SQLi) vulnerability, assigned CVE-2023-34362, has been actively exploited by attackers.
According to a report by Mandiant, exploitation attempts of this vulnerability were detected as early as May 27, 2023. On the same day, Akamai researchers detected exploitation attempts against one of Akamai’s financial customers — an attack that was blocked by the Akamai Adaptive Security Engine.
The attack campaign was attributed to a ransomware group dubbed CL0P. The group, thought to be based in Russia or Eastern Europe, is financially motivated and has been known to extort their victims via data exfiltration.
Attackers have exploited the SQLi vulnerability to deploy a custom ASP.NET web shell (LEMURLOOT) to achieve persistence on victim networks to allow for further attack.
At the time of writing, full exploit details are not publicly available. However, analysis by the Akamai Security Intelligence Group and collaboration with the Progress security team confirms the Adaptive Security Engine has protected our customers against exploitation attempts.
Timeline
Fig. 1: MOVEit exploitation campaign timeline of events
On May 31, 2023, Progress Software published an advisory and started alerting their customers to a zero-day vulnerability in MOVEit Transfer and MOVEit Cloud that was being actively exploited by attackers to compromise internet-facing servers (Figure 1).
This alert came after the identification of a massive exploitation campaign that leveraged this vulnerability to exfiltrate sensitive files stored on vulnerable servers. According to Mandiant, exploitation attempts of the vulnerability were observed as early as May 27, 2023. A technical analysis of the vulnerability was performed by Huntress, who showed that the vulnerability could actually lead to a full remote code execution on the server.
Microsoft officially attributed this attack to the Lace Tempest group on June 2, 2023, and this was finally confirmed on June 5 when CL0P published a statement regarding this campaign on their blog (Figure 2).
Fig. 2: The CL0P ransomware group acknowledge their involvement in the MOVEit campaign
Scope of attacks
At the time when the attack was already known and investigated, Shodan identified approximately 2,500 internet-facing servers running MOVEit (Figure 3).
Fig. 3: A Shodan query showed more than 2,500 internet-facing servers running a vulnerable version of MOVEit
Progress Software stated that all servers running MOVEit were vulnerable and no patch existed at the time of the massive attack. Therefore, it's safe to assume that the number of victims is substantial. Several organizations are already confirmed breached, and many more will probably surface in the coming days.
Exploit chain
There has been a lot of information published about this vulnerability. However, the full exploit details have yet to be made public. Based on public information, analysis done by the Akamai Security Intelligence Group, and the data seen in our logs, we have a solid idea of how moveitisapi.dll is being used to perform SQLi.
Additionally, our team met with the Progress security team for an information-sharing session in which we shared our analysis and other information relating to indicators of compromise (IOCs). Based on this meeting, we are able to confirm that Akamai Adaptive Security Engine protected and continues to protect our mutual customers against this attack.
We may publish more details about our analysis and exploit chain once enough time has passed to allow for patching.
Concealing the operation
The CL0P group made several attempts to stay undetected and complicate analysis.
First, the name of the uploaded web shell was “human2.aspx”, which is very similar to the legitimate MOVEit file implementing the web interface: named “human.aspx”.
Second, accessing the web shell required a password to be sent via the “X-siLock-Comment” header. If the header was missing or the password was incorrect, the web shell would return a 404 Not Found response. Oftentimes, the easiest way to to find a web shell is to send a simple GET request. If the page does not exist then a 404 is returned. Having the web shell return a 404 only prevents the easiest way of discovery. With a few additional steps you can compare the web shell’s 404 response to the server's normal 404 response and see the difference between the two responses.
Third, the headers used to control the web shell and send exploits used names that are very similar to MOVEits original header names. For example, “X-siLock-Comment” is used to transmit the web shell password. Other information from the MOVEit database was exfiltrated via similarly named headers: “X-siLock-Step2” and “X-siLock-Step3”.
Exploitation detection
Exploitation attempts can be identified in several ways.
Known indicators of compromise (IOCs)
Progress Software and the security community have published many host- and network-based indicators of compromise including IP addresses, file hashes, and YARA rules.
Network administrators can inspect network traffic and IIS logs, and scan assets in the network to find known IOCs and thus identify exploited machines.
Adaptive Security Engine customers can inspect their WAF logs for signs of exploitation. If their MOVEit hosts were targeted, they should see SQLi attack group triggers targeting “/moveitisapi/moveitisapi.dll”.
Threat hunting
Servers that run the vulnerable software should be investigated and scanned for anomalous behavior even if known IOCs were not detected on them. For example, after inspecting the payload the attackers used, we see it resulted in an aspx web shell being dropped to the root directory of the server at <DriveLetter>: \MOVEitTransfer\wwwroot\. he web shell deployed in the original attack campaign was named human2.aspx, but this indicator could easily change.
Instead of only relying on static IOCs, we recommend employing anomaly-based threat hunting methods on vulnerable servers. In this specific case, one approach could be checking the root directory of the MOVEit server to find any aspx files that were recently created. aspx files are relatively static in nature and aren't usually modified or created, so a new addition could be suspicious and should be investigated. Additional suspicious file paths were published in the initial Progress advisory and in a recent CISA #StopRansomware advisory.
Akamai Guardicore Segmentation customers can use the Insight query illustrated in Figure 4 to locate such files.
Fig. 4: Insight query to find any aspx files that were recently created
Please note that the drive letter (C:\) and installation path can vary; this query will only cover the default installation path.
Akamai Hunt — Akamai’s managed threat hunting service — has performed thorough scans of customers’ environments in order to detect vulnerable assets, exploitation attempts, and IOCs associated with the attack campaign. In cases where MOVEit components were found, Hunt researchers informed the relevant teams and helped mitigate the threat immediately (Figure 5).
Fig. 5: Hunt alert regarding a MOVEit exploitation attempt detected in a customer environment
Mitigation
Unfortunately, software vulnerabilities are inevitable, but organizations can do a lot to protect themselves against this type of breaches.
Map internet-facing servers
Before being able to mitigate the attack, defenders first have to identify what sensitive internet-facing applications they are running. In the MOVEit case, all vulnerable customers were informed of the vulnerability by Progress. However, it is still crucial to be aware of your externally facing attack surface and identify all sensitive applications that are exposed to the internet. Once you’ve identified these applications, the following mitigation steps can reduce the risk of the applications being compromised.
Limit internet access
Reducing the attack surface should be top priority. If there is no justified reason for unauthorized internet access to an application, it should be protected with user-based access controls, which can be achieved via Zero Trust Network Access (ZTNA) or traditional VPN products.
If unauthorized internet access is required for some use cases, we recommend that you run a separate external application server, limit the data that is stored on it or accessible from it, and segment it from the internal network as much as possible. This way even if the application server is breached, the blast radius would be limited.
Block exploitation with a WAF
Applications with web interfaces should be placed behind a WAF, as it can block anomalous and suspicious requests and potentially block exploitation of previously unknown zero-day vulnerabilities.
According to our current knowledge and understanding of the exploitation chain, Akamai Adaptive Security Engine provides protection against this attack with the SQLi Attack Group. Specifically, we have identified instances in which the Adaptive Security Engine prevented attackers from exploiting the SQLi vulnerability. The blocked requests originated from the IPs listed in the known IOCs.
Prevent lateral movement with segmentation
Internet-facing servers can often be the entry point for attackers into the network. With that knowledge, those servers should be treated accordingly and kept in a separate segment, limiting the attacker’s ability to perform lateral movement inside the network.
For example, a rule can be created to block all outbound connections from internet-facing servers over management ports (Figure 6).
Fig.6: A sample rule in Akamai Guardicore Segmentation to block lateral movement attempts
This way, if an attacker were to breach the server, it would be impossible to perform lateral movement over these ports. Additional rules covering sensitive applications and other management ports should be created to limit the attack surface from these servers as much as possible. Keep in mind that such rules might also break normal network operations, so you should apply discretion when creating them and adding exclusion to existing traffic necessary for daily operations.
Until next time?
MOVEit is yet another case of zero-day vulnerability exploitation of a managed file transfer (MFT) service. By now, the CL0P ransomware group has become notorious for this type of activity; they have previously exploited vulnerabilities in the GoAnywhere, SolarWinds Serv-U, and Accellion applications to steal data and extort their victims, and they also exploited additional vulnerabilities in other internet-facing applications.
In fact, if any of the top MFT solutions is installed in your network, it's a pretty safe bet that as you are reading this sentence, a highly skilled and motivated hacker somewhere in the world is studying these applications and trying to find their security holes. It seems to be only a matter of time until a new exploitation campaign is launched by the CL0P group, and additional groups will presumably be quick to follow.
