MOVEit Vulnerability Investigations Uncover Additional Exfiltration Method

Kroll has identified two different file exfiltration methodologies leveraged by threat actors, primarily CLOP, during recent engagements involving the exploitation of the MOVEit vulnerability (CVE-2023-34362) throughout May and June 2023.

In the vast majority of Kroll’s global MOVEit investigations, the primary data exfiltration method consisted of utilizing the dropped web shell to inject a session or create a malicious account (named Method 1 for this piece). From there, threat actors were able to reauthenticate and use the MOVEit application itself to transfer files.

However, in a few instances, Kroll identified an additional and distinctly different methodology used to exfiltrate data that left markers in the available logging and required a separate approach for analysis versus the more broadly leveraged and primarily used methodology (named Method 2 for this piece). Kroll has also analyzed the Python script leveraged by CLOP to exfiltrate data during its initial wave of coordinated and largely automated attacks across MOVEit servers globally (Method 2).

Analysis of Additional Exfiltration Methodology (Method 2)

The web shell, dropped by the threat actors during exploitation of CVE-2023-34362, contains built-in data exfiltration capabilities. As opposed to the more commonly observed method (Method 1), data exfiltration via this mechanism (Method 2) creates distinct indicators of compromise due to its direct interaction with the MOVEit API. Kroll investigators have identified forensic artifacts consistent with the use of this capability in approximately 5% of Kroll’s global MOVEit engagements (Method 2). 

In Method 2, threat actors pass three variables to the web shell. These variables consist of the organization ID, the folder ID and the file name. From there, the web shell utilizes MOVEit API calls for file enumeration and data exfiltration.

The code snippet below demonstrates how the three variables, passed from the threat actor to the web shell, are used in the creation of the DataFilePath class.

The DataFilePath class is declared within the MOVEit DLL files. The class, and function with the same name, receive the organization ID, folder ID and the file name. 

SILGlobals is also loaded, which has several different classes and methods; however, the threat actor specifies “FileSystemFactory”. MOVEit code, provided below, shows the implementation. 

Finally, as shown below, encryption keys are retrieved using GetBaseKeyProvider, and these keys are used to decrypt the file using the GetDecryptionStream function. 

The above steps prepare files for exfiltration via download of an application/octet-stream MIME type object. 

The data stored within the MOVEit systems is encrypted at rest on disk and during engagements in which dead-box incident response was the only available recourse. Our team designed an approach allowing for automated file decryption of at-rest data to move collections and “at risk” data more fluidly through an attorney review process (part of eDiscovery) and then through breach notification steps when necessary.

Data Exfiltration Python Script

In order to exfiltrate data, Kroll obtained and analyzed a copy of the Python script that CLOP leveraged in an automated methodology for Method 2 data exfiltration during the early MOVEit exploitation abuse:

Web Shell Analysis and Intrusion Lifecycle

For context, the web shell that CLOP dropped is protected by a random 36-character globally unique identifier (GUID) that is created when the file is dropped on the system and used for authentication and unauthorized access. Cybercriminals specify the password in each request sent to the web shell by setting the “X-siLock-Comment" variable in the HTTP header. If there is a mismatch between the GUID and X-siLock-Comment value, the web shell will return a “404” error code. 

There are three additional variables the web shell will analyze to determine what function is performed. 

• Header1 = X-siLock-Step1
• Header2 = X-siLock-Step3 
• Header3 = X-siLock-Step2 

Pseudocode of Web Shell 

The headers can be further broken down and explained as the following:  

• If header1 is set to “-1,” the web shell will return Azure Blob information such as: storage account, blob key and the blob container. 
• If header1 is set to “-2,” the malicious account “Health Check Service” will be deleted if it exists.
• If header2 and header3 are both “null,” the web shell attempts to inject a new session for a superuser in the “activesessions” table.
• If a superuser account cannot be found, then the shell creates the malicious “Health Services Account”. 

When data is exfiltrated using these headers, entries will be logged in the “log” table of the MOVEit database. The table can then be parsed to generate a listing of files that were exfiltrated from the environment. 

If none of the headers match the aforementioned pseudocode, then the default case will be executed. The default case will decrypt, compress and exfiltrate data as “Content-Disposition”. When data is exfiltrated in this way, there are no corresponding entries in the “log” table or other logs unless the client has enabled MOVEit logging. 

For this functionality to be triggered, the web shell requires:

• Header1 = Organization ID (not equal to -1 or -2) 
• Header2 = File ID (identifying a specific file on disk) 
• Header3 = Folder ID (identifying a specific folder on disk)

Case Studies

Kroll has observed multiple instances where data was exfiltrated using this additional exfiltration method (Method 2) to actor-controlled IP address 5.34.180.205. 

Below are two examples of the typical attack cycles criminals used when performing exfiltration: 

Case Study A

Kroll identified that, over the course of approximately 14 minutes, threat actors were observed exploiting a MOVEIt web server, dropping a web shell, establishing connections to the web shell, and initiating automated data enumeration and exfiltration preparatory steps. Upon initial analysis, Kroll noted that there were no active user sessions created in the table, no log entries that matched the more commonly observed Method 1 exfiltration, and no unusual activity appearing within the MOVEit logs (consistent with Method 1 markers).

At the end of the 14 minutes, a new threat actor IP address established a web shell connection and what followed for the next several hours were several thousand GET and POST requests which, when overlayed with the available firewall logging, indicated several large volumes of data being transferred to the new IP address. Kroll assesses with high confidence that the method of data exfiltration was the aforementioned Python script being executed from the CLOP (remote) side of the connection. 

Case Study B

Similar to case study A, over the course of approximately 10 minutes, Kroll identified that threat actors were observed exploiting a MOVEIt web server, dropping a web shell, establishing connections to the web shell, and initiating automated data enumeration and exfiltration preparatory steps. Upon initial analysis, Kroll noted that there were no active user sessions created in the table, no log entries matching the more commonly observed Method 1 exfiltration, and no unusual activity appearing within the MOVEit logs (consistent with Method 1 markers). 

At the end of the 10-minute window, the same IP address as case study A connected to the web shell (“human2.aspx”). In this instance, the victim had MOVEit logging enabled, allowing Kroll investigators to correlate entries that had the following available field: “LocalFileSystem.GetLocalPath:OK <REDACTED FILEPATH>” with the timestamp identical or closely matching to IIS (Internet Information Services) logs, firewall logs and other logging-related artifacts and sources available for review. Our experts also enumerated the “at risk” files and created a process to search for them against the “log” table where most of the files were identifiable and traceable. 

Similar to case study A, the attacker moved from exploitation of vulnerability to web shell interaction to data exfiltration in less than 15 minutes, with several thousand automated exfiltration transactions occurring in the hours that followed, presumably via the Python script.

A good indication that this additional method of exfiltration has occurred can be found in how often a particular IP address has accessed the web shell. For instance, Method 2 exfiltration may have occurred if hundreds, thousands or tens of thousands of GET and POST requests have been made by the same IP address to the web shell over the course of hours or days. 

In addition, the analysis of network traffic logging, including firewall logs, should be normalized and compared to the dates and times of the web shell requests. This allows for correlation to the volume of traffic that egressed the MOVEit web server outbound to any identified unauthorized IP address. 

Key Recommendations 

Because of the nature of this data exfiltration methodology, it can be missed during an initial forensic investigation. It is important to be wary of suspicious activity relating to GET and POST requests to the web shell and dive deeper if there is a sharp uptick in these requests. 

If an uptick is observed, our team recommends looking into IIS logs from the MOVEit server, in addition to other available MOVEit database and application-level logs, operating system event logging and available network traffic or firewall logging. Proactively validate and confirm that logging is enabled and retained in a log collector for retention and analysis.