Webinar Replay: Lessons Learned from 50+ MOVEit IR Investigations. Watch Now.
Mon, Jul 24, 2023
Webinar Replay: Lessons Learned from 50+ MOVEit IR Investigations. Watch Now.
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).
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.
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:
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.
The headers can be further broken down and explained as the following:
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:
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.
5.34.180.205 Details | |
---|---|
IP Location | ITL, LLC (Ukraine) |
ASN | Netherlands |
Hosting Provider | AS21100 |
Below are two examples of the typical attack cycles criminals used when performing exfiltration:
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.
Status | Entry |
---|---|
GET status 200 | / |
POST status 200 | /api/v1/token |
POST status 200 | /moveitisapi/moveitisapi.dll + uri-query: action=m2 |
GET status 200 | /api/v1/folders |
POST status 200 | /api/v1/folders/328652734/files + uri-query: uploadType=resumable |
POST status 200 | /guestaccess.aspx |
PUT status 500 | /api/v1/folders/328652734/files + uri-query: |
POST status 200 | /moveitisapi/moveitisapi.dll + uri-query: action=m2 |
Webshell Dropped | human2.aspx created on disk. |
POST status 200 | /guestaccess.aspx |
GET status 404 | /human2.aspx |
GET status 200 | /moveitisapi/moveitisapi.dll + uri-query: action=capa |
GET status 200 | /human2.aspx |
GET status 200 | /human2.aspx |
GET status 200 | /human2.aspx |
Exfil Starts | Sent Bytes:5217 |
POST status 200 | /moveitisapi/moveitisapi.dll + uri-query: action=m2 |
POST status 200 | /guestaccess.aspx |
POST status 200 | /moveitisapi/moveitisapi.dll + uri-query: action=m2 |
POST status 200 | /guestaccess.aspx |
POST status 200 | /moveitisapi/moveitisapi.dll + uri-query: action=m2 |
POST status 200 | /guestaccess.aspx |
POST status 200 | /guestaccess.aspx |
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.
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.
Incident response, digital forensics, breach notification, security strategy, managed security services, discovery solutions, security transformation.
Threat intelligence are fueled by frontline incident response intel and elite analysts to effectively hunt and respond to threats.
Stop cyberattacks. Kroll Responder managed detection and response is fueled by seasoned IR experts and frontline threat intelligence to deliver unrivaled response.
Our expertise allows us to identify and analyze the scope and intent of advanced persistent threats to launch a targeted and effective response.
Kroll helps development teams design and build internal application threat modeling programs to identify and manage their most pressing vulnerabilities.
Validate your cyber defenses against real-world threats. Kroll’s world-class penetration testing services bring together front-line threat intelligence, thousands of hours of cyber security assessments completed each year and a team of certified cyber experts — the foundation for our sophisticated and scalable approach.
Kroll’s Malware Analysis and Reverse Engineering team draws from decades of private and public-sector experience, across all industries, to deliver actionable findings through in-depth technical analysis of benign and malicious code.
by Scott Downie, Laurie Iacono, Dan Cox
by Scott Downie, George Glass, Dave Truman
by Laurie Iacono, Stephen Green, Dave Truman