Deep Dive into the MOVEit Vulnerability and Subsequent Exploitation

Background

Progress Software’s MOVEit is a popular Managed File Transfer (MFT) software that is used by thousands of organizations around the world.

Update: As of December 7, 2023, Progress Software has disclosed a total number of eight (8) CVEs in MOVEit since a zero-day vulnerability, CVE-2023-34362, was widely exploited in late May.

On June 1^st, 2023, CISA issued an alert indicating that Progress Software had issued a critical security advisory for a vulnerability, CVE-2023-34362, in MFT, with a CVSS3 score of 9.8. On June 2^nd, 2023, the situation escalated to the point where CISA sent out another alert indicating that the vulnerability not only had the dreaded remote code execution (RCE) attributes but was also being actively exploited. On June 7^th, 2023, CISA issued yet another alert about this vulnerability indicating that the CL0P Ransomware gang was responsible for the exploitation of this vulnerability in MFT software.

More recently, CISA released more alerts for more vulnerabilities (CVE-2023-35708 and CVE-2023-35036) in MFT. There is no evidence that these vulnerabilities are being exploited. These vulnerabilities are likely being exploited and we just don’t know yet.

Threat Analysis of MFT Software

The threat intelligence for the vulnerability CVE-2023-34362 states that the bad actor, CL0P, planted a web shell in the IIS Web Server that hosts the MFT application. CISA published YARA Rules for the CL0P attack to help MFT’s customers cope.

A web shell in an application is a backdoor that facilitates two-way keyboard control by remote bad actors. A bad actor that controls the code in the web shell “owns” the workload. They can execute arbitrary commands or download and execute the malware on the victim's workload.

In this high-profile cyberattack, the bad actor implemented a web shell using code in a file they called “human2.aspx.” This name appears to be chosen to plant doubt in the minds of SOC Analysts since the name appears very similar to the legitimate MFT file “human.aspx.” An unsuspecting SOC Analyst may be lulled into thinking that this file was a legitimate MFT file. Upon installation, the file “human2.aspx”:

• Provides the bad actor an initial static password for accessing the web shell. All that the bad actor must do is provide this password via the X-siLock-Comment HTTP.

• Manipulate the MFT database by supplying the following optional data in the X-siLock-Step1 header:

Option 1: Delete a Health Check Service user from the MFT database

Option 2: Leak Azure hosting information and return details of files in the MFT database.

Option 3: Retrieve a specified file via the X-siLocked-Step2 header (directory) and X-siLocked-Step3 header (file). If these two headers are not explicitly specified in the HTTP comms, the web shell will delete the existing and add a new “Health Check Service” admin user into the database.

Armed with the password, CL0P can execute various commands on the victim workload, from the comfort of their remote command control center. The bad actor can retrieve any file, exfiltrate any data, or drop malware and have it executed on the MFT server workload.

How does CL0P Work?

The overall architecture of CL0P, including the steps used to evade detection, is well thought through. The high-level functionality of CL0P ransomware can be described by the following steps:

• Step 1: CL0P kept up the tradition of packing their malware to avoid reverse engineering. CL0P signed the malware with a valid code-signing certificate. Most EDRs have a very coarse application control filter and this code-signing twist allowed CL0P’s ransomware to escape the clutches of EDRs early on. We know all too well what can happen if sophisticated malware gets to run even for a second:

1. 1. 1. 1. It can cause EDR telemetry to be bypassed or unloaded

         2. It can terminate essential EDR processes

         3. It can suppress telemetry EDRs rely on to detect attacks

• Step 2: CL0P is designed to not run under several conditions as below:

1. 1. 1. 1. The malware must be installed as a service otherwise, it will terminate. This condition is frequently used by malware to achieve persistence across reboots.

         2. If the active keyboard layout is determined to be from a CIS country.

         3. If it discovers that it is being run in an emulator such as a sandbox. When CL0P determines it is being run in an emulator, it goes off to sleep for a long time, giving the researcher the impression that code-under-test is benign.

• Step 3: CL0P checks for the presence of processes associated with some specific EDRs. If these are not found, then the malware unpacks itself into the resources typically associated with these EDRs. This step allows CL0P to give the impression that it is a legitimate EDR.
  
  
• Step 4: Next CL0P deletes the Windows OS’s shadow volumes from which the encrypted files could potentially be recovered. To prevent the OS from recreating the shadow volumes, CL0P resizes the space associated with the shadow volumes to the smallest possible size. It also disables the recovery option in the bootloader.
  
  
• Step 5: Next, the malware creates an OS-based signaling object called mutex and waits for this mutex to be signaled. In case the mutex does not get created, the malware knows that this workload is a previously infected victim and there is no point wasting cycles.
  
  
• Step 6: Next, CL0P creates two threads in memory – one to search for specific processes and network-shared drives connected to the workload and another one to encrypt targeted files in the identified network shares. The thread that searches for processes looks for specific names to terminate those processes if found and creates a new malicious process by that same name to throw SOC Analysts off as it searches for network shared drives. The second thread allocates memory for each network share detected. This second thread searches for critical files and folders in each share.
  
  
• Step 7: Next the malware generates a random AES Key and starts encrypting interesting files with a combination of the AES and a master key. The malware not only appends the string “Cl0p^_” but it also appends the AES key to the file name before encrypting it with the RSA Master key. This process helps to decrypt the file to its pre-attack state should the ransom be paid. This process is repeated for all files. At that point, a ransom note is generated.

Can the Remote Code Execution (RCE) Vulnerability in MFT be Exploited Otherwise As Well?

With a vulnerability with RCE attributes, what unfolds next is clearly up to the bad actor and their agenda. In the MFT attack, it all started with a SQL Injection vulnerability. From there, the road can diverge depending on the bad actor. Some attackers could choose to keep lurking in the shadows and assess what other valuable data they could exfiltrate. Others would do what CL0P did – launch some clever variant of yet another ransomware. Others could choose to launch an army of bots. Who knows what monetization strategy a given bad actor has?

Why do we bring up this issue? We hear so many sound bites about how CL0P was stopped in its tracks early on. Just as a reality check, exploitation activity on MFT has been going on since May 2021. Additionally, it would be a huge mistake to think that it is just the CL0P gang that has been dipping its hands in the cookie jar.

The MFT Attack Kill Chain

Shown below is the kill chain associated with the cyberattack launched by CL0P. The various stages of the attack are depicted by the color-coded legend shown on the left.

After the successful execution of Steps 1 and 2, the bad actor has found a victim enterprise they can compromise. In Step 3, the bad actor exploits the SQL Injection vulnerability (CVE-2023-34362) described above and in Step 4 the backdoor gets instantiated. In Step 5, the bad actor accesses the vulnerable MFT server on demand. In Steps 6 and 7, the bad actor extracts some basic but “valuable” data that will be needed in the next stages. These two steps are a very important milestone in the Double Extortion stage of the overall attack. Many victims believe that they need not pay the ransom in the belief that they can recover their workload from a recent backup. In such cases, the bad actor forces the hand of the victim by releasing some of the exfiltrated information. Hence the term double extortion!

The paths of various bad actors can diverge after Step 7. The CL0P gang chose to go down the path described from Step 8 onwards.

Click image to enlarge

What Do Most Enterprises Do When They Get CISA Alerts on Known Exploited Vulnerabilities?

On receiving CISA alerts, IT Staff in some organizations will trigger an emergency patching operation. Many other enterprises may be so concerned about revenue loss or simply be so far behind in their patching efforts that the CISA alert doesn’t get the attention it deserves. The reality is that when enterprise fails to patch, they provide the fodder that bad actors crave.

When CISA alerts about Known Exploited Vulnerabilities hit our inboxes, we pay attention for a few days until the news gets buried by the next attack. We shake our heads and attribute the latest attack to the generically buggy nature of all software. We are here to say that there are alternatives that can keep the enterprise safe, even when vulnerabilities lurk.

What Are These Alternatives?

Most conventional EDRs are built on many assumptions that attackers circumvent regularly. A few examples of such tenuous assumptions are (a) the telemetry hooks inserted by the EDR cannot be unloaded, stopped, or corrupted, and (b) bad actors leverage a finite set of TTPs. Unfortunately, the skills of bad actors often exceed the skills of both the defender and the AI/ ML algorithm combined. To make matters worse, bad actors have the first mover's advantage; no wonder why conventional EDRs keep getting blindsided.

By contrast, Security Controls built with the First Principle mindset handle every assumption with a trust-but-verify approach. Until the security control has positive confirmation of code provenance and integrity, execution will not occur. This approach, called the “Positive Security Model” ensures that no malware, no matter how sophisticated, can execute even one instruction. The Positive Security Model security control, therefore, stops the attack BEFORE damage is done. An EDR that lets malicious code execute, even for a millisecond is of little value.

So, what is the First Principle at work in the Positive Security Model? Such a security control continuously tracks, at a very granular level, the provenance of the code that is about to execute. In effect, it keeps asking the question, is the code about to execute arrive from a legitimate source or not? A Positive Security Model security control makes it very hard to exploit an application even if has vulnerabilities lurking.

With that in mind, let’s reexamine the kill chain of the MFT attack in the context of Virsec’s VSP, a Positive Security Model based security control:

Click image to enlarge

Virsec’s VSP can protect MFT deployments against cyberattacks at Step 3 itself without needing any Threat Feeds, YARA rules, Behavioral, or Heuristic Signatures.

Conclusion

Even with the best intentions, keeping enterprise software updated is very challenging, given the volume of patches that get delivered daily. Unfortunately, when patches are not applied, bad actors are never far, especially if the vulnerability has Remote Code Execution (RCE) attributes. Almost all alerts in CISA’s catalog of Known Exploited Vulnerabilities have RCE attributes.

Sophisticated malware can disable, unload or terminate EDR processes, It can also suppress telemetry that conventional workload-based security controls, such as EDRs, rely on. Enterprise is better served by security controls, such as Virsec’s VSP, that leverage the Positive Security Model. VSP is a true Zero Trust Security Control that embodies First Principles and can protect the workload BEFORE the attacker can compromise it. To learn more about Virsec VSP, please visit us at www.virsec.com