Abstract

Progress Software’s MOVEit Transfer solution is a widely used secure file transfer product. In late May, they announced a critical vulnerability that has left about 2,500 organizations vulnerable, most of them in the US. The worst part of it is that the MOVEit Transfer instances are exposed on the public internet, so anyone can exploit these organizations over HTTP/HTTPS without authenticating. The scenario continues to unravel. Several additional vulnerabilities have been subsequently announced; the most recent on July 7.

For security teams, the task at hand is to review/detect all known and previously unknown uses of MOVEit Transfer in the organization, patch those instances, look for prior exploits, and take remedial action.

The purpose of this blog is to investigate the vulnerability. This blog will lay out the steps to investigate in a traditional fashion, and then contrast that with an investigation using open federated search via Query’s open federated search solution. Please refer to MOVEit Transfer and MOVEit Cloud Vulnerability for remediation information from the vendor.

More about the vulnerabilities

MOVEit Transfer has SQL injection vulnerabilities that allow remote unauthenticated attackers to gain unauthorized access to its database over HTTP/HTTPS. The attacker can steal file and user information, get an administrative backdoor, execute any SQL statement to steal data from the underlying database, and modify the database to cause further harm.

There are four distinct vulnerabilities (as of July 11, 2023, when this was published):

CVE-2023-36934 from July 7.
CVE-2023-35708 from June 15.
CVE-2023-35036 from June 9.
CVE-2023-34362 from May 31.

The remedy is to patch the software. For further details along with steps to patch, please refer to MOVEit Transfer and MOVEit Cloud Vulnerability. All MOVEit Transfer and MOVEit Cloud versions prior to the service pack released on July 6th, i.e. three days ago as of writing, are vulnerable.

The Investigation: time-critical, yet time-taking

Do you have MOVEit Transfer?

The security team should determine any possible instance of MOVEit Transfer that puts the organization at risk. Along with the known server(s) running MOVEit Transfer, the team should also search the organization’s assets to detect any previously unknown use. They should also search external intel sources like Shodan to see if any public facing server owned by the organization is revealed.

If you find any installations of MOVEit Transfer, you have to patch it asap and investigate for any potential exploits. But first, modify your internet-facing firewall to disable access to it from the public internet; at least until you have completed patching and your investigation. If you were using MOVEit Cloud, the vendor has patched it already, though it is possible your data was exploited prior to their patching so you should still continue to investigate.

So far, CVE-2023-34362 is the vulnerability for which an exploit has been observed, performed by cl0p ransomware gang. The observed exploit puts a file human2.aspx in the wwwroot folder of the MOVEit install directory, giving webshell access to the attacker. (human.aspx is the native ASPX file used by MOVEit for the web interface). Look for this file first.

Investigating the webshell exploit is difficult. Attackers could easily modify their webshell to different filenames and hashes. You could go deeper and look for webshells using YARA. Take a look at these open source YARA rules: signature-base/yara/vuln_moveit_0day_jun23.yar at master and YaraRules/MOVEit_Transfer_Critical_Vulnerability.yara at main. (For understanding YARA, refer to my previous blog – Querying for Malware Varients.)

We expect our EDR vendors to incorporate rules like above in their detections, and we can then query their logs. Typically this would mean querying from data lakes where the rolled-off EDR data resides.

This CISA advisory #StopRansomware: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability | CISA has the IOCs we need to investigate: 40+ hashes for LEMURLOOT webshell, 60+ malicious IPs seen attempting the exploit, etc. I am not going to replicate them here. The investigation is a lot of manual work; pivoting into multiple tools and running individual queries -possibly hundreds. Manually correlating hits is further pain and most organizations may not have the resources to do the detailed follow-up on the possible paths.

For investigating further, let’s move it 😉 to federated search instead so that we can avoid the drudgery, double digit browser tabs, several command shells, notepad, and thousands of keystrokes!

We assume that you have already integrated Query’s open federated search solution with relevant data sources like extended EDR, threat intel like Shodan, asset inventory, cloud blob storage having relevant application and server logs, and other data sources relevant to your environment. 

Here is how you would start to check whether you have MOVEit Transfer in your environment:

  • run federated search for human.aspx, the file used by MOVEit for the web interface.
  • run federated search for 989289239, the MOVEit Transfer’s favicon file’s mmh3 hash.

If you find any installations of MOVEit Transfer in your environment, let’s now use federated search to investigate the exploit. We should search data from May 2023 onwards.

Steps to investigate using open federated search:

  • Search for the human2.aspx webshell exploit’s originally observed hashes:
    • 2413b5d0750c23b07999ec33a5b4930be224b661aaf290a0118db803f31acbc5
    • 48367d94ccb4411f15d7ef9c455c92125f3ad812f2363c4d2e949ce1b615429a
    • E8012a15b6f6b404a33f293205b602ece486d01337b8b3ec331cd99ccadb562e
    • (…see more related LEMURLOOT webshell hashes in the MOVEit Campaign Indicators of Compromise section of the CISA advisory)
  • Search for the presence of human2.aspx file
  • Run federated search to check the modification timestamps on moveitisapi.dll, the DLL used to perform SQL injection.
  • Search for webshell scripts on the MOVEit Transfer server – filename ends with cmdline.
  • Search MOVEit Transfer audit logs’ for Action = file_download. Look for unexpected downloads of files from unknown IPs or large numbers of files downloaded and pivot accordingly.
  • Search for the list of IOCs reported in the CISA advisory at #StopRansomware: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability | CISA. This is to stay up to date on the IOCs as the attacks evolve.

Post-exploit Incident Response

You have to now follow through with your IR process if any of the above IOCs are observed in your environment. Delete new/unknown users and reset all users credentials and service account credentials on the affected servers. You can see users with this SQL on MOVEit Transfer’s database:

SELECT * FROM [<database name>].[dbo].[users] WHERE Status=’active’ and Deleted=’0′

The database engines behind MOVEit Transfer running in your environment would be one of MySQL, Microsoft SQL Server, or Azure SQL. Understand what data you were transferring/receiving and take custom remediation actions accordingly: notifying partners/customers, etc. These details make the investigation pretty specific to every organization and increase the complexity.

Open federated search helped in all of the investigation stages above by greatly expanding data visibility and understanding the impact. Since the investigation involved searching file and process information, asset information, network logs, server logs, identity information, etc., you would not have that full data in your SIEM. Moving/duplicating that data into SIEM was not practical either. Federated search solved that problem. It not only searched the SIEM, but all of the above sources in-place. 

Federated search can be integrated with more data sources relevant to the investigation to look beyond traditional security log data and query live from sources such as asset stores, endpoint telemetry data, SQL databases, event logs, etc.

Query’s open federated search provides a single console to search decentralized data without moving the data:

Please contact us for further information or to test-drive open federated search.