The Cybersecurity & Infrastructure Security Agency has issued an alert about the use of a zero-day vulnerability in MOVEit software. Exploitation of this zero-day SQL injection vulnerability in the wild has been observed, mainly targeting North America and including attacks from the ransomware threat actor Lace Tempest.
MOVEit is managed file transfer software from Progress (formerly Ipswitch), an application development and digital experience technologies provider. According to the MOVEit site, the application is being used by thousands of organizations around the world.
Jump to:
What is the zero-day MOVEit Transfer vulnerability?
This zero-day MOVEit Transfer vulnerability, as it was known to attackers before being patched, is a SQL injection vulnerability, CVE-2023-34362. It affects all versions of MOVEit Transfer according to its development company Progress; it doesn’t affect MOVEit Automation, MOVEit Client, MOVEit Add-in for Microsoft Outlook, MOVEit Mobile, WS_FTP Client, WS_FTP Server, MOVEit EZ, MOVEit Gateway, MOVEit Analytics and MOVEit Freely.
This zero-day vulnerability allows an unauthenticated attacker to get access to MOVEit Transfer’s database, possibly allowing the attacker to execute SQL statements altering or deleting the database elements.
SEE: SQL injection attacks: What IT pros need to know (TechRepublic Premium)
Exploitation in the wild, particularly in North America
A blog post from Rapid7 indicates this cybersecurity company has observed exploitation of the CVE-2023-34362 zero-day vulnerability in the wild across multiple customer environments. According to Rapid7, a wide range of organizations have been affected.
The active exploitation of the vulnerability by cybercriminals started at least four days prior to the release of the security advisory from Progress.
SEE: Zero-day exploits: What IT pros need to know (TechRepublic)
More than 2,500 MOVEit Transfer instances are exposed to the internet, with more than 1,800 of those instances being in the U.S., according to the Shodan search engine (Figure A).
Figure A
Rapid7 observed the same webshell name in multiple customer environments. On compromised systems, the webshell named human2.aspx is located in the wwwroot folder of the MOVEit install folder. The name of the file has probably been chosen to stay unnoticed, as a legitimate file named human.aspx is the native file used by MOVEit Transfer for its web interface.
The webshell’s access is protected by a password. Attempts to connect to the webshell without the proper password results in the malicious code providing a 404 Not Found error.
The use of the same name on multiple servers might indicate automated exploitation, according to Rapid7. It seems the targeting is more opportunist than highly targeted. The initial compromise might lead to ransomware exploitation, as file transfer solutions have been popular targets for attackers including ransomware threat actors.
Microsoft has confirmed the exploitation of this vulnerability via Twitter, attributing attacks exploiting the CVE-2023-34362 MOVEit Transfer zero-day vulnerability to Lace Tempest, a threat actor known for ransomware operations and running the Clop extortion site. This threat actor exploited a vulnerability in another File Transfer Manager software, GoAnywhere, earlier this year.
How to detect threat exploitation
System administrators should check for the presence of a human2.aspx file in the wwwroot folder of their MOVEit Transfer software.
Log files should also be reviewed from at least a full month earlier. Unexpected downloads/uploads of files from unknown IP addresses should be carefully reviewed.
Web server log files should be checked for any events that would include a GET request to a human2.aspx file, as well as large numbers of log entries or entries with large data sizes, which might indicate unexpected file downloads.
If applicable, Azure log files should be reviewed for unauthorized access to Azure Blob Storage keys.
According to Rapid7, data exfiltration can also be identified. In the case where administrators of the MOVEit Transfer software enabled logging, a Windows Event File C:\Windows\System32\winevt\Logs\MOVEit.evtx provides a lot of information, including file name, file path, file size, IP address and username performing the download. While logging isn’t enabled by default, it’s common for administrators to enable it post-installation. Data exfiltration can then be seen in that event log file.
Audit logs are stored in the MOVEit database and can be queried directly or through the software’s built-in reporting functionality. Administrators can use those logs to generate a report of file download actions run via the software, letting them see potential data exfiltration.
How to mitigate this risk
The Progress provider strongly recommends immediately applying the patch it released.
If not applicable immediately, organizations should disable all HTTP and HTTPS traffic to the MOVEit Transfer environment to avoid attackers connecting to it. While legitimate users won’t be able to connect to it anymore, SFTP and FTP protocols will continue working as usual, and administrators will still be able to connect to it via Remote Desktop Protocol.
If the human2.aspx file or any suspicious .cmdline script is found, it should be deleted. Any newly created or unknown file in the MOVEit folder should be closely analyzed; in addition, .cmdline files in any temporary folder of Windows should be examined.
Any unauthorized user account should be removed.
Once the patch or the blocking of HTTP and HTTPS is done, administrators should run detections as mentioned earlier and carefully look for indications of compromise. If evidence is found, the service account credentials should be reset.
Continuous monitoring should be applied for any of the Indicators of Compromises provided by Progress.
Additional security best practices
While not specific to the CVE-2023-34362 vulnerability, Progress indicates that administrators should allow multifactor authentication on MOVEit Transfer. In addition, remote access policies should be updated to only allow known and trusted IP addresses. Finally, user accounts should be carefully checked to only allow authorized accounts to access the service.
Disclosure: I work for Trend Micro, but the views expressed in this article are mine.
