Movin’ Out: Identifying Data Exfiltration in MOVEit Transfer Investigations
Published 06/28/2023
Originally published by CrowdStrike.
Summary Points
- Organizations around the globe continue to experience the fallout of the MOVEit Transfer exploit CVE-2023-34362
- CrowdStrike incident responders have identified evidence of mass file exfiltration from the MOVEit application, as a result of the webshell activity on compromised MOVEit systems
- Data exfiltration activity can be identified by analyzing the MOVEit application database and IIS logs
Background
CrowdStrike incident responders have been at the forefront of investigating impacted victims of CVE-2023-34362. Since the release of the vulnerability, there has been great collaboration across the cybersecurity industry, and this blog will cover novel details for teams investigating the potential impact to their organizations. Specifically, this blog will discuss what CrowdStrike has identified for investigators to determine whether data exfiltration has occurred in their MOVEit Transfer application and its potential impact.
MOVEit Database Analysis
As widely discussed, the Webshell will utilize an existing user account with permission level “30” or a new randomly generated username to establish a persistent session within the MOVEit application.
Investigators can review the MOVEit application database for evidence of existing sessions created by the Webshell. The associated database names can be found as either moveittransfer or moveitdmz. To perform the manual review, an investigator will require both the .mdf and associated .ldf file for MSSQL based database and the associated files for MySQL installs. Additionally, a backup of the database can be created to preserve evidence for review. The MSSQL and mySQL backups are typically in a .bak and .sql format respectively.
The database table activesessions contains details related to active sessions within the MOVEit application. Identifying the active session can assist investigators by quickly identifying the User account leveraged by the Webshell to interact with the application. The MOVEit database can be configured for mySQL or SQL. Note: If there is not an active session identified at the time of analysis this does not mean one did not exist.
Example queries to find malicious sessions within the activesessions table in SQL and mySQL:
SQL
SELECT [Username],[LoginName],[RealName],[IPAddress],[LastTouch],[SessionID],[Timeout] FROM [<Database Name>].[dbo].[activesessions] Where Timeout = '9999';
mySQL
SELECT Username,LoginName,RealName,IPAddress,LastTouch,SessionID,Timeout FROM <Schema Name>.activesessions Where Timeout = '9999';
Username | LoginName | RealName | IPAddress | LastTouch | SessionID | Timeout |
<16 Character String> | NULL | 127.0.0.1 | 2023-05-29-01:00:00.000 | <SessionID> | 9999 |
Example Table of a malicious session created by the Webshell
An additional method to identify potential accounts of interest is to review the users table for accounts with permission level “30”. This is a lower fidelity search, but can provide a smaller list of users to investigate.
Example queries to identify privileged users of interest within the users table in SQL and mySQL:
SQL
[Username],[LoginName],[RealName],[LastLoginStamp],[PasswordChangeStamp],[Permission], [CreateStamp],[LastChangeStamp] FROM [<Database Name].[dbo].[users] Where Permission = '30' AND Deleted = '0';
mySQL
Username,LoginName,RealName,LastLoginStamp,PasswordChangeStamp,Permission,CreateStamp, LastChangeStamp FROM <Schema Name>.users Where Permission = '30' AND Deleted = '0';
The MOVEit database contains verbose activity logging that will capture the data exfiltration activity events. Investigators can review the log table for action=file_download events to identify potential signs of data exfiltration from the MOVEit application. The log table will include important fields such as Username, IP Address, Filename, Folder, Transfer Size, and User Agent. It is suggested to filter the log table for known IP addresses and users of interest.
Example queries to review the log table for evidence of file download events:
SQL – View all successful file_download events since 2023-05-01
SELECT [ID],[LogTime],[Action],[Username],[FolderID],[FileID],[IPAddress],[Error], [Parm4],[AgentBrand],[AgentVersion],[XferSize],[Duration],[FileName],[FolderPath], [Hash],[VirtualFolderID],[VirtualFolderPath] FROM [<DatabaseName>].[dbo].[log] Where LogTime > '2023-05-01 00:00:00' AND Error = '0' AND Action = 'file_download';
SQL – View all successful file_download events from a set of IP Addresses
SELECT [ID],[LogTime],[Action],[Username],[FolderID],[FileID],[IPAddress],[Error], [Parm4],[AgentBrand],[AgentVersion],[XferSize],[Duration],[FileName],[FolderPath], [Hash],[VirtualFolderID],[VirtualFolderPath] FROM [<Database Name>].[dbo].[log] Where LogTime > '2023-05-01 00:00:00' AND Error = '0' AND Action = 'file_download' AND IPAddress IN ( 'IP Address A', 'IP Address B');
mySQL – View all successful file_download events since 2023-05-01
SELECT ID,LogTime,Action,Username,FolderID,FileID,IPAddress,Error,Parm4,AgentBrand, AgentVersion,XferSize,Duration,FileName,FolderPath,Hash,VirtualFolderID,VirtualFolderPath FROM <Schema Name>.log Where LogTime > '2023-05-01 00:00:00' AND Error = '0' AND Action = 'file_download';
mySQL – View all successful file_download events from a set of IP Addresses
SELECT ID,LogTime,Action,Username,FolderID,FileID,IPAddress,Error,Parm4,AgentBrand, AgentVersion,XferSize,Duration,FileName,FolderPath,Hash,VirtualFolderID,VirtualFolderPath FROM <Schema Name>.log Where LogTime > '2023-05-01 00:00:00' AND Error = '0' AND Action = 'file_download' AND IPAddress IN ( 'IP Address A', 'IP Address B');
Internet Information System (IIS) Log Analysis
An additional artifact that should be reviewed is the IIS logs for suspicious requests to download files. CrowdStrike investigators identified that in some instances the IIS logs will capture GET requests with the cs_uri_stem=/download. Within these events, the cs_uri_query will contain multiple FileID’s and FolderID’s for objects within the MOVEit application. Investigators should review for suspicious entries, particularly requests with a large number of files and folders referenced in a single request. The IIS log entries do not typically provide a comprehensive view of the Files and Folders downloaded. These entries can primarily be used to assist with identification of additional IOCs and activity. Entries in the IIS logs with cs_uri_stem=/download that have a cs_Referer reference from human.aspx and contain an IP address rather than a domain name have been found in multiple instances to identify Threat Actor owned IP addresses in the c_ip field. The MOVEit database log table should provide a more verbose view of files downloaded. Below is an example entry of a GET request related to file exfiltration.
Example IIS Log Entry Containing a Suspicious Download Request (click to enlarge)
Evidence Preservation Guidance
If indicators of compromise are identified on a system, it is recommended to preserve the available evidence for forensic analysis. The following steps are recommended guidance for preserving evidence for review of MOVEit Transfer investigations:
- Create a snapshot or image of the MOVEit Transfer Web Server system(s)
- Include the data drive containing wwwroot if it is not installed to C:
- Create a backup dump of the MOVEit Transfer database
- Export and retain available network logs (WAF, Firewall, Netflow, ELB, ALB, NSG Flow, VPC Flow, etc.)
Recommendations for Service Restoration
We recommend following the recommendations set out by the Progress team to patch affected systems before restoration of services. If you suspect that your systems were affected immediately take steps to:
- Preserve associated systems and databases for investigation purposes as previously outlined
- Temporarily disable TCP 80/443 traffic to affected systems. During this time:
- Re-deploy new MOVEit Transfer application servers with latest patch installed
- Review database for any recently created users (these can be found in the users table of the database)
- Reset credentials of application accounts prioritizing service and administrator accounts
- Restrict IP addresses from only trusted sources for administrator accounts access
- Ensure security tooling is redeployed on systems and functioning
- Re-enable TCP 80/443 traffic to patched systems
- Maintain continuous monitoring of associated systems and stay up to date on any latest developments from the Progress team
We thank the Progress team for their communications and updates in keeping the community informed.
Related Articles:
The Evolution of DevSecOps with AI
Published: 11/22/2024
A Vulnerability Management Crisis: The Issues with CVE
Published: 11/21/2024
Establishing an Always-Ready State with Continuous Controls Monitoring
Published: 11/21/2024
AI-Powered Cybersecurity: Safeguarding the Media Industry
Published: 11/20/2024