MOVEit Hack: the Ransomware Attacks Explained
Jesse James, the notorious 19th century gang leader, was known for his bank robberies. But in 1873, he and his crew hit a train rolling through Iowa. They had word the train was carrying massive amounts of gold, but quickly realized their intel was wrong: the gold was only a fraction of what they’d been promised.
But, since they were already onboard and wearing bandanas over their faces, James’ gang shifted gears and robbed the train’s passengers instead.
150 years later, another gang made a similar score. In 2023, the Clop ransomware group attacked MOVEit Transfer—a secure managed file transfer software–and robbed its customers’ sensitive data. Like Jesse James’ gang, Clop recognized two things: crimes of opportunity can be as lucrative as targeted attacks, and objects are never at more risk than when they’re in motion.
Clop (or Cl0p)—known for its RaaS (ransomware-as-a-service) deployments— formed in 2019 and has since built up an extensive rap sheet encrypting sensitive data and extorting its victims. Yet the MOVEit attack is noteworthy because here, they’ve abandoned encryption and are simply extorting their victims not to release the data they’ve stolen.
And in MOVEit–despite the fact that it was designed to handle sensitive data– Clop found a soft target, vulnerable to the exploitation of multiple SQL injection vulnerabilities.
We’ll get into the details of the attack in a bit, but first let’s acknowledge that while 255 victims and nearly 18 million individuals were reportedly impacted, the continued details of who was affected, and how badly the fallout will be are still trickling out. However, since it’s already been two months since the first reports of the attack, we have the benefit of time to stitch together the most important developments.
So let’s dive into MOVEit Transfer and just how it went (wink wink, nudge nudge) off the rails.
Anatomy of the MOVEit Hack
The MOVEit hack was so pernicious because Clop had planted the seeds for it years ago. Using the experience they gained from their past file transfer exploits— GoAnywhere and Accellion —the threat actors prepared themselves for this moment.
Evidence suggests that the planning of these attacks stretch as far back as 2021, as Kroll, a risk and financial advisory firm, states: “…it appears that the Clop threat actors had the MOVEit Transfer exploit completed at the time of the GoAnywhere event and chose to execute the attacks sequentially instead of in parallel.”
Perhaps because the scope of the attack was so large—rather than encrypt their victims’ data, the Clop gang simply stole it and threatened to release it if they weren’t paid. This decision added a few new twists to the familiar ransomware script. For one thing, it made some of the usual post-extortion actions useless. You can’t pay someone to decrypt your files or simply work off your most recent backup. And then of course, there’s no guarantee that Clop will actually follow through on its deletion promise.
Clop may have anticipated that their victims have no reason to pay up if they can’t trust them, and in fact they promised to erase any data from government, police, or city agencies, with no payment necessary. To make sure you believe them, they signed off their (oddly charming?) ransom note with “friendly Clop.” But all things considered, you may want to take their reassurances with a rather large grain of salt.
Vendors under the microscope
The laundry list of those affected by the attacks keeps growing so quickly because MOVEit was built into the backend of so many consumer-facing systems. Unfortunately, the damage of these events is frequently passed onto those individuals rather than the companies responsible for protecting their information. The CalPERS (California Public Employees’ Retirement System) breach is one such incident to keep an eye on.
CalPERS and its 769,000 affected individuals were included in the MOVEit attack because their vendor, PBI Research Services, was breached. With personal data such as date of birth, names, and social security numbers compromised, these seniors on fixed incomes have a right to be angered. And now the retirees are seeking justice by suing the vendor, claiming PBI “did not maintain reasonable security measures or adequately protect California residents’ privacy.”
This isn’t the only legal case bubbling up from the MOVEit attacks as class action lawsuits are being presented to not only vendors, but Progress Software themselves. This further exemplifies that in the eyes of victims, not only are software companies on the hook to have their security protocols scrutinized, but the vendors that use them as well; enter Zellis.
The payroll software vendor, with a high-profile list of customers such as BBC, Aer Lingus, and British Airways, was compromised in the MOVEit attacks. It’s not clear whether the customers even knew Zellis used MOVEit to transfer their sensitive data, but what is clear is that these attacks exhibited no prejudice. Whatever information was in scope, Clop was taking.
Fallout of the MOVEit attacks
As of mid-July, Progress has released four separate instances of patches to critical MOVEit vulnerabilities (vast majority of the SQL injection variety) since the attacks began:
May 31: First patch is released (CVE-2023-34362).
June 9: Second patch is released (CVE-2023-35036).
June 15: Third patch is released (CVE-2023-35708).
June 18: Progress Software lambasts third-party who disclosed CVE-2023-35708 to the public without alerting them first.
July 5: Progress Software releases a Service Pack featuring three CVEs that they will continue to provide on a “predictable timeline.”
Two things stand out here—Progress’ ability to provide patches in a timely manner and the publication of a CVE that was not even exploited by Clop. According to Progress, there was no malicious activity attached to the vulnerability that the third-party released on social media; it was just another flaw in the system.
But to understand why these vulnerabilities were so critical to patch (and drew the ire of Progress when released unceremoniously), we need to talk about the extraordinary power of SQL injections.
How Do the MOVEit Transfer Attacks Work?
SQL injections aren’t a new type of vulnerability–if anything, they’re a little passé. According to OWASP’s Top Ten Application Security Risks, injections ranked number one in 2017 and number three in 2021. All that goes to show is this type of vulnerability still runs rampant and it can all be traced back to sanitized code (or lack thereof).
Often simplified as a “frontend vulnerability,” a SQL attack means that threat actors can take advantage of fields on a login page that have flawed inputs.
This allows threat actors to access an account using the public-facing login fields, since they can use a generic admin username and provide a command line in the password field that marks whatever they enter as TRUE, so it acts as a stand-in for the correct password. Once the threat actor has done so, that enables them the ability to inject a webshell, providing a more permanent backdoor into the system they are attacking.
And that is what happened in the MOVEit attacks. “The method used to compromise systems is to drop a webshell in the wwwroot folder of the MOVEit install directory,” explains Pieter Arntz of Malwarebyes Labs, going on to add that, “this allows the attacker to obtain a list of all folders, files, and users within MOVEit, download any file within MOVEit, and insert an administrative backdoor user into, giving attackers an active session to allow credential bypass.”
This simple weakness creates a giant security hole. As CISA’s advisory notice succinctly puts it: “A cyber threat actor could exploit this vulnerability to take control of an affected system.” To take control of a dedicated on-premise server–as many MOVEit Transfer instances are–wouldn’t be a huge deal since it could be contained far easier. However, Progress’ offering of MOVEit Cloud unfurled data loss events that Progress, its customers, and all of their customers were not prepared for.
Because the secure file transfer application was available in a cloud environment, the data breach was able to be done remotely and therefore expedited. As Kroll explains, “[we] observed a similar fact pattern across multiple MOVEit Transfer cases, and in some instances, the activity occurred across multiple organizations within seconds or minutes of each other.”
With a larger victim base and nearly instantaneous results, MOVEit Transfer/Cloud customers didn’t stand much of a chance against the cyberattacks especially when you factor in that all versions of MOVEit Transfer were impacted by these vulnerabilities.
How To Guard Against Ransomware Attacks
While we won’t find out the total impact of the MOVEit attacks until long after this blog is published, to keep Clop and other ransomware gangs at bay in future attacks, your organization can implement tools and practices that will deter these threat actors.
While there is no remedy for unsanitized code in one of your mission-critical tools (unless you’re directly responsible for writing it), here are some things you can do to protect yourself and your organization.
Shutting off HTTP/HTTPs traffic
Before we cover ways to prevent ransomware attacks, let’s talk about what you do to limit the damage of an attack that’s already in progress. One of the quickest and most surefire ways to prevent further exfiltration is to deny access by shutting off both inbound and outbound HTTP and HTTPs data traffic.
As Progress recommended when the first vulnerability was discovered, modifying firewall rules was only a temporary solution to attacks while patches were being created.
However, the difference between the first and subsequent attacks was the addition of MOVEit Cloud vulnerabilities. By the following attacks being focused on MOVEit Cloud, it created the need for Progress to take down all HTTPs traffic for the SaaS application as well as customers doing it on their own servers.
Patching
Once a vulnerability is discovered, a patch is (hopefully) trailing right behind. In the case of the MOVEit attacks, it took about 48 hours for a patch to be released after reports of the first attacks. But there’s a big difference between a patch being available and deployed, and it is the responsibility of security and IT teams to ensure that those patches are in place across your fleet.
We often see that even with available patches, organizations struggle to install them. As Dan Goodin—Senior Security Editor at Ars Technica— explains, “even after Progress issued the fix, some MOVEit users continued to get hacked because they hadn’t yet installed it on their networks.”
And even if IT admins installed MOVEit’s first patch, they still needed to get the subsequent fixes rolled out, since in cases like this, there’s rarely just one vulnerability. So when you’re in the midst of this type of breach, be prepared to deploy more emergency patches.
SQLi vulnerabilities are sort of like cockroaches. If you create the conditions to have any, then you never just have one. The attackers know this too, so they will keep looking for exploits and likely succeed and finding more. So, keep your eyes peeled for critical patches to be released by the vendor and have the tools in place to quickly and efficiently deploy them—and MOVEIt’s Service Packs are a testament that they are expecting more themselves.
Auditing your vendors
When considering a new vendor, aside from all the other vetting you must do, be curious about their vulnerabilities. It’s more of a frank conversation than paperwork—you can ask for their SOC 2 or similar audit if you’d like to go down that route—but asking what your organization should be prepared for will pay dividends.
And when a software or application is as mission critical as a secure managed file transfer product can be, even if you’re not directly interacting with the tool but your vendors are, inquire about their processes and what safeguards they have in place if things go haywire.
ABP: Always Be Patchin’
The unfortunate truth is that security vulnerabilities are part of life. (They aren’t all as bad as this one, and hopefully it’ll inspire everyone else to check for the same weakness, but you get the picture.) The best any of us can do is be ready when the next weakness is exploited.
Even if a patch isn’t available due to a zero-day, the moment you get wind of it, you now know what to do. Like the theater audience in 1903 experiencing The Great Train Robbery for the first time, don’t be surprised when a threat is coming for you—be ready.
