Learning from the MOVEit attacks: What to know and what to do

In the final days of May 2023, customers of Progress Software’s MOVEit file transfer platform began experiencing compromises, and these compromises started making the news in a very big way. Significant amounts of data were exfiltrated by the attackers, and victims were then extorted regarding the public release of their data. Patches have been made available for known vulnerabilities, however, this compromise event is far from over.

The MOVEit attacks have capitalized on at least one previously unknown zero day vulnerability, meaning that even if customers were vigilant about patching, they were still vulnerable – and quite possibly compromised – during the time between the vulnerability’s discovery and when the patches were released and applied. Additional vulnerabilities have been discovered, and patches issues by Progress. 

These attacks have been attributed to Cl0p, a Russian-speaking cybercrime group that has a long history of ransomware extortion. As of time of writing a senior US CISA official has stated that they do not believe these attacks are being coordinated by the Russian government, despite multiple government agencies in multiple countries having fallen victim.

Why MOVEit?

MOVEit is not the first file transfer platform to be exploited. Bleeping Computer notes that there have been “similar attacks in the past using zero day vulnerabilities in Accellion FTA, GoAnywhere MFT, and SolarWinds Serv-U”. While we can’t know the motivations of threat actors with certainty, file transfer applications make sense as targets for a number of reasons.

File transfer applications tend to be developed by smaller vendors, and there is a persistent perception that smaller vendors are less capable when it comes to application security. File transfer applications also tend to be deployed by organizations rather than individuals, increasing the likelihood that victims will have the resources to pay. Finally, and perhaps most important, these applications hold data. Lots of data.

All of this means that file transfer applications make for an attractive target, and will almost certainly be targeted again.

So what can be done about this? File transfer is necessity, but how can you better protect the data that is routed through these platforms?

Protecting against the unknown

Let’s start discussing defences with some generic “how to protect against zero days” advice.

• The most important thing anyone can do to secure their applications is to patch them. While patches will not protect you against zero day attacks, they lower your attack surface by fixing known vulnerabilities.
• If you don’t know which applications might be vulnerable, vulnerability scanners are a good place to start. They will scan your network to identify applications and their versions, and then notify you if those applications are behind on their patches.
• Exposure of an application to the internet is in and of itself a huge risk. Where possible, make use of Web Application Firewalls (WAFs). WAFs sit between an application and the internet, inspecting traffic for anything untoward. WAFs only know about a limited number of applications, however, and may not get updates about new attacker techniques any faster than vendors can make patches available for their vulnerable applications.
• In general, if you don’t have to expose an application to the internet, then don’t. Where possible require a VPN to access services. If VPNs aren’t a viable solution then consider a firewall configured to deny all access to your application except access from specific IP addresses. The more tightly you can control access to your application the less likely it is to be compromised.
• Servers that applications run on should have Endpoint Detection and Response (EDR) defences installed and operational. If a device cannot have EDR installed – say because it is a printer or a smart lightbulb – then those devices should be connected to separate, isolated networks. Treat anything that can’t have EDR installed on it as already compromised, and keep it away from anything on your network that might host sensitive files or other data.
• Regular log analysis offers the possibility of catching attacks that the above approaches miss, however, this requires significant familiarity with the application in question.
• Lastly, have an incident response plan prepared for when compromise events happen. Know how to lock your network down to prevent compromise spread, how to capture data for forensic analysis, and have pre-existing relationships with third-party security experts who can help you go through that data should that ever be required.

While all of this advice is somewhat generic – how do you protect everything against every possible unknown attack is a rather broad topic space – advice on how to defend file transfer applications specifically is something we can get more granular with.

Defending your file transfer platforms

File transfer applications typically come with the ability to restrict access based on user credentials. It is important to have individual credentials for each user, and to restrict each user’s access as much as possible to only that which they absolutely must have access. While this won’t protect you from zero day attacks directly, it can help detect when some kinds of attacks are occurring. So let’s look at some broad categories of zero day attacks you might see with a file transfer application.

• First up is a vulnerability that lets one user access another user’s data. Depending on the specific details of the vulnerability, having file and folder restrictions at the level of the underlying file server (in addition to those provided by the file transfer application) can help here. Automated log file analysis that tracks which IPs regularly access which user credentials can also help here, as it can help note if user accounts are being logged in to by IPs that aren’t typically associated with that account, or which are typically associated with a different account.
• Another type of vulnerability is one that allows an attacker to access data from any user without having to first compromise one user’s data. Here log file analysis that can look for abnormal levels of activity, or the use of uncommon commands, is extremely helpful. Deploying one or more honeypot servers can help here too. Set up a server that looks real: it has multiple (fake) user accounts, and there is (simulated) data in each account. Stick a logfile analyzer on it and if the logfile analyzer sees anything other than login attempts – login successes, file transfers, etc. – then you know something’s up, and that it’s time to really start paying close attention to your real, live server(s).
• The last major type of zero day vulnerability you are likely to encounter in a file transfer application, and the one that enabled the MOVEit attacks, is arbitrary code execution. This means that an attacker can blow right past any defences that exist in the application, and then actually cause the operating system which hosts the file transfer application to execute a payload. In the case of MOVEit, an SQL injection vulnerability was exploited which resulted in the detonation of a malicious payload that then did the job of exfiltrating the data, rather than that data being exfiltrated through the MOVEit software itself. This type of zero day vulnerability can affect any application, file transfer or otherwise. And as with most generic zero day mitigation advice “keep everything from touching anything else” is the best advice.

Your defences begin by restricting the privileges under which the file transfer application executes. If possible, don’t run that application with administrator-level privileges. If you can lock it up in its own container or virtual machine, do that. If it can be on a completely isolated network that’s even better. Under no circumstances should your file transfer application have access to even one file that is not absolutely required for it to do its job.

Here, knowing something about how your file transfer application is actually used by your customers can help. Consider the use case wherein your file transfer application is used exclusively for customers to upload files to you. In this case have a script that runs in the background and scans for when files are done uploading. As soon as they’re done move that file off of the file transfer server and over to a storage location the file transfer server can’t access. That way, if the file transfer application is ever compromised by a zero day that allows for arbitrary code execution that code can’t access any data.

If you do need to make data available to your users through the file transfer application then consider whether or not you can at least make it read only to any credentials that could possibly be used by a malicious application executing on the file transfer server. This way you have at least narrowed the potential scope of the problem to “attackers may have seen data”, and aren’t dealing with “attackers may have modified and/or deleted data”.

Parting thoughts

Defending file transfer applications from zero day vulnerabilities really boils down to the principle of least privilege. Make sure everything connected to your network can only talk to what it absolutely needs to talk to, and that everything possible has EDR installed. If you absolutely must provide some level of persistent privileged access, then if at all possible require your users to use a VPN in order to access your file transfer services.

Any data that is exposed to the internet, even if protected by an application, is at risk of finding its way onto the internet. The more defences you have, the longer you’re likely to be able to keep that data secure. Logfile analysis and vulnerability scanners can help tell you when the data is no longer secure. But nothing beats making as little data as possible available for as short a period of time as is absolutely necessary in terms of reducing your risk.