On May 31, 2023, Progress Software released a security bulletin concerning a critical vulnerability within MOVEit Transfer, a widely used secure file transfer system. According to Shodan, over 2500 servers running this software are on the Internet.

TrustedSec has performed analysis on the vulnerability and post-exploitation activities. CVE-2023-34362 has been assigned to this vulnerability.

This post will describe the research conducted so far and provide detection, response, and protection recommendations. Please see the changelog at the end of the post for newly updated information.

Vulnerability

According to the MOVEit notification, a SQL injection (SQLi) vulnerability within the application could allow escalated privileges and unauthorized access to the environment. Based on TrustedSec’s analysis of the backdoor seen, a successful attack could allow unauthenticated remote access to any folder or file within a MOVEit system.

Progress has published mitigation and remediation steps, security best practices, as well as fixed versions of the software in their notice.

Exploit Activity

According to a Reddit thread on the vulnerability, one of the backdoors named in the attack is human2.aspx. According to our research, these backdoors have been uploaded to public sites since May 28, 2023, meaning the attackers likely took advantage of the Memorial Day holiday weekend to gain access to systems. There have also been reports of data exfiltration from affected victims.

TrustedSec was able to gain access to multiple copies of the human2.aspx backdoor and perform analysis. Most of the code within the backdoor samples is the same except for a unique hard-coded password. These hard-coded, randomly generated passwords used for compromises means searching purely for file hashes may be less fruitful.

Backdoor

The human2.aspx backdoor, which is allegedly uploaded during the attack, allows the attacker to do the following:

• Obtain a list of all folders, files, and users within MOVEit
• Download any file within MOVEit
• Insert an administrative backdoor user into MOVEit and give attackers an active session to allow credential bypass

Note that the backdoors examined do not yet return a list of user password hashes from MOVEit.

The human2.aspx backdoor functions as follows:

• When the page loads, a request header named X-siLock-Comment will be checked against a hard-coded password. If the password does not match, a 404 code is returned.
• The value of a request header named X-siLock-Step1 is then read in.
  • X-siLock-Step1 will contain a value of -1, -2, or null. A follow-on set of actions will occur depending on this value.
• If the X-siLock-Step1 value is -1:
  • The Azure Blog Storage Account, Blob Key, and Blob Container IDs are appended to the response header.
  • The following is obtained and returned in a Gzip’d stream:
    • A list of all files and folders stored in MOVEit
    • The file owners and file size
    • All institution names within the MOVEit instance

• If the X-siLockStep1 value is -2:
  • A backdoor user named Health Check Service is deleted from the users table.

• If no X-siLockStep1 value is specified, the backdoor reads in two (2) headers: X-siLock-Step2 (a folder ID) and X-siLock-Step3 (a file ID).
  • If the values are present, the backdoor responds with the file requested.
  • If the values are not present, the backdoor:
    • Adds an administrative user named Health Check Service into the users table
    • Creates and inserts a new active session for this user into the application

Detection

There are several steps organizations can take to detect a successful compromise of the attack:

• Examine the c:\MOVEitTransfer\wwwroot folder for any suspicious files that have been created recently, such as human2.aspx or App_Web_[RANDOM].dll files with the same or similar timestamps.
  • The exact folder used by MOVEit depends on the version and location installed.
• Examine MOVEit or firewall logs for large outbound network transfers from the MOVEit environment.
• Search for a user named Health Check Service within the MOVEit user database.
• Examine active sessions within the MOVEit database for user Health Check Service.
  • Note that the backdoor script modifies the last login time, so this is not a reliable field to examine.
• Search for web requests that contain any of the request or response headers listed above.
• Florian Ross has created a YARA rule to detect the known ASPX webshell backdoors that are dropped during the attack. This can be found here.
• Search firewall and MOVEit IIS logs for requests from any of the IP addresses specified within the IOCs below.

Response

If any indicators of compromise (IOCs) are found, organizations should do the following:

• Contain the system per your Incident Response policies.
  • If the ability to contain does not exist, the system should be isolated on the network by removing network connectivity or pausing the system (if it is a VM).
  • Do not power off the system!
• Ensure that any network-based logs, including firewall logs, are centralized or saved offline.
• Begin an investigation or contact your Incident Response provider to begin an investigation.
• If you utilize Azure Storage in conjunction with your MOVEit installation, rotate Azure Storage keys as listed in this Microsoft article.
• Rapid7’s blog post on the attack has detailed information on how organizations can determine what files, if any, were exfiltration.

After removing backdoors and installing the fixed version, the vendor suggests bringing the MOVEit systems online and monitor them. However, without conducting a thorough investigation, it is impossible to determine if additional backdoors have been installed. Therefore, in line with Incident Response best practices, it is recommended to:

1. Perform a forensic investigation of affected system(s).
2. Rebuild and restore the system(s) from a trusted backup prior to the earliest known compromise.
3. Continuously monitor all systems.

Merely removing existing backdoors and putting the systems back online, even with monitoring, is not recommended.

Protection

Fixed versions of the software are available from Progress. These should be installed as soon as possible.

Progress’ mitigations are to deny all HTTP (TCP/80) and HTTPS (TCP/443) traffic to the MOVEit environment. Note that this will block all access to the system, but SFTP/FTP will still work, which currently appears unaffected.

According to Progress, there are no signs that the SFTP or FTP protocols have been compromised or can be used to leverage file transfer. TrustedSec still recommends caution.

Indicators of Compromise

Reference

• https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023
• https://nvd.nist.gov/vuln/detail/CVE-2023-34362
• https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer
• https://github.com/Neo23x0/signature-base/blob/master/yara/vuln_moveit_0day_jun23.yar#L2
• https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#manually-rotate-access-keys
• https://www.huntress.com/blog/moveit-transfer-critical-vulnerability-rapid-response
• https://www.rapid7.com/blog/post/2023/06/01/rapid7-observed-exploitation-of-critical-moveit-transfer-vulnerability/

Changelog

Version 1 – Initial publication

Version 2 – Added fixed version information, YARA signature, and IP address IOCs

Version 3 – Clarified information on SFTP/FTP

Version 4 – New hash IOCs, additional response information, Azure storage recommendations