The Kaseya Attack: Everything to Know
July 12, 2021 • RBS
On Friday, July 2, 2021 one of the “largest criminal ransomware sprees in history” took place. Kaseya, a global IT infrastructure provider, had allegedly suffered an attack that utilized their Virtual System Administrator (VSA) software to deliver REvil (also known as Sodinokibi) ransomware via an auto update.
Over the course of the July 4th holiday weekend, numerous disclosures, blog posts, and articles were published about the incident, but Kaseya still hadn’t released details by the end of the holiday. As details emerge, numerous points of contention have been introduced, such as the vulnerability responsible and whether it was a zero-day vulnerability, as well as the scope of organizations affected.
However, as we investigate this situation, Risk Based Security has observed that the Kaseya attack might not be the supply chain attack it was initially written out to be.
This article will present the latest details involving Kaseya as well as our own findings. Later on, we will also examine the bigger picture of what supply chain attacks actually are, so we can better understand what that term means and its origins.
The Kaseya Attack: What Happened
Early reporting about the Kaseya attack made an effort to disclose as much information as possible, but the lack of details, coupled with the July 4 holiday weekend, muddled the situation.
Here are the main points you need to know to understand the impact and scope of the Kaseya ransomware attack:
- Kaseya’s Virtual Systems Administrator (VSA) software is designed to manage an organization’s complete IT infrastructure
- Some Kaseya customers are Managed Service Providers (MSP) who are contracted to handle IT tasks for thousands of other organizations
- Threat actors using REvil (aka Sodinokibi) ransomware exploited vulnerabilities to hack VSA software
- Using VSA, the threat actors spread REvil ransomware via MSPs to their customers
- Thousands of organizations that were either directly or indirectly involved with Kaseya have been infected with REvil ransomware
- UPDATED: Nine days after the incident, Kaseya has released patch 9.5.7a to address the vulnerabilities used in the REvil attack.
Managed Service Providers (MSPs)
Before we can dive into the specifics of the Kaseya attack, it is essential to know what role a MSP serves. Essentially, MSPs are contracted by organizations who are unwilling to, or are unable to manage their own IT department.
Lawfare has a fantastic article that explains what a MSP is, and how it plays into understanding the scope of the Kaseya attack. Similarly to how an organization might outsource their customer support, an organization can choose to rely on a MSP if the costs of maintaining their own IT department is too high, or if it is deemed too risky. As such, small to medium-sized businesses often choose to use MSPs.
How Kaseya VSA Factors In
Since MSPs are responsible for handling thousands of their customers’ IT tasks, they need software that allows them to automate key tasks. In order to do this, software like Virtual Systems Administrator (VSA) allows a MSP to perform tasks that usually require a high level of privileges, such as updating systems, and removing or adding programs. In fact, in order to perform these processes without interruption Kaseya even advises that users turn off their antivirus and firewall…
Zero-day Vulnerability or Just an Exploited Vulnerability?
Now that we know what MSPs are and what VSA does, we can review what actually happened. Early speculation was that the attackers had hacked Kaseya themselves and then pushed malicious updates from the vendor to VSA devices. Days later, research is suggesting that the malicious actors directly hacked VSA servers.
Kaseya has stated that the threat actors were able to do this by exploiting zero-day vulnerabilities. Credentials leak and business logic flaw vulnerability CVE-2021-30116 has been currently assigned for the issue. This CVE ID was put in RESERVED status on July 5, despite the incident occurring on July 2. As of July 8, both the CVE and NVD entries for this vulnerability were empty, even though vendor and other advisories exist.
But was CVE-2021-30116 actually a zero-day vulnerability? Perhaps technically it was, but not in the usual sense:
Behind the scenes, DIVD researcher Wietse Boonstra had found the zero-day and notified Kaseya who then started to put the processes in place to mitigate the issue. According to DIVD, Kaseya had followed all the right steps:
“Once Kaseya was aware of our reported vulnerabilities, we have been in constant contact and cooperation with them. When items in our report were unclear, they asked the right questions. Also, partial patches were shared with us to validate their effectiveness. During the entire process, Kaseya has shown that they were willing to put in the maximum effort and initiative into this case both to get the issue fixed and their customers patched. They showed a genuine commitment to do the right thing. Unfortunately, we were beaten by REvil in the final sprint, as they could exploit the vulnerabilities before customers could even patch.”Victor Gevers, Chairman and Head of Research at DIVD
Arguing over semantics isn’t constructive, but this information does raise some interesting questions. Since DIVD and Kaseya were following standard vulnerability disclosure practice, how close was Kaseya in patching those vulnerabilities? How did malicious actors stumble upon those vulnerabilities? Did they intercept communications between the researchers and the vendor – or was it a coincidental case of mutual discovery? And who was ultimately affected by this attack?
Who’s Affected by the Kaseya Attack
The Scope of the REvil Ransomware Attack
Potentially thousands of organizations and over a million individual systems are affected by the Kaseya ransomware attack. However, this was slightly downplayed by Kaseya in their initial customer notifications when they suggested that only “a very small percentage of our customers were affected – currently estimated at fewer than 40 worldwide”.
Regardless of the actual number, the fact that the affected customers are MSPs means that their customers have also been compromised or are at-risk. According to ThreatPost, it is estimated that 60 customers using the on-premises version of VSA experienced an attack, with many of them being MSPs who manage the networks of other organizations. This has caused Kaseya to backtrack their initial claims, with Fred Voccola, Kaseya’s CEO, admitting that the actual number of compromised businesses may exceed 1,500:
If you instead look at individual systems, the scope of the attack is much more alarming. Over a million individual systems are potentially locked up at the time of publishing, and Kaspersky has observed that there have been over 5,000 attack attempts in 22 countries.
The situation in Sweden provides a window into the global reliance on MSPs for IT services. As a result of this REvil ransomware attack, it is believed that 20% of Sweden’s food retail, pharmacies, and train tickets sales have been shut down:
The ripples of the Kaseya attack are still spreading and at this point, we can only speculate just how far the MSPs’ compromise will trickle down. Many of the compromised Swedish businesses were not even direct customers. This means that there is still a possibility that additional countries or organizations that rely on Kaseya (or even those loosely affiliated) can still add to the tally of casualties. We may not know exactly how many systems become compromised, but we do know that those that are will be staring at a ransom payment demand.
How Did the Kaseya Attack Happen
If Kaseya and DIVD were following a standard coordinated vulnerability disclosure, how far along were they in patching the vulnerabilities? DIVD’s limited vulnerability disclosure provides new insights into those questions.
Including the previously mentioned CVE-2021-30116, there was a total of 7 vulnerabilities that were part of DIVD’s disclosure, and at least one was mutually discovered by the attackers:
- CVE-2021-30116 – A credentials leak and business logic flaw, resolution in progress
- CVE-2021-30117 – An SQL injection vulnerability, resolved in May 8th patch
- CVE-2021-30118 – A Remote Code Execution vulnerability, resolved in April 10th patch (v9.5.6)
- CVE-2021-30119 – A Cross Site Scripting vulnerability, resolution in progress
- CVE-2021-30120 – 2FA bypass, resolution in progress
- CVE-2021-30121 – A Local File Inclusion vulnerability, resolved in May 8th patch
- CVE-2021-30201 – A XML External Entity vulnerability, resolved in May 8th patch
The following was the coordinated vulnerability disclosure timeline between DIVD and Kaseya:
- April 1, 2021 – Research start
- April 2, 2021 – DIVD starts scanning internet-facing implementations
- April 4, 2021 – Start of the identification of possible victims (with internet-facing systems)
- April 6, 2021 – Kaseya informed
- April 10, 2021 – Vendor starts issuing patches v9.5.5. Resolves CVE-2021-30118.
- May 8, 2021 – Vendor issues patch v9.5.6. Resolves CVE-2021-30121 and CVE-2021-30201.
- June 4, 2021 – DIVD CSIRT hands over a list of identified Kaseya hosts to Kaseya
- June 26, 2021 – Patch 9.5.7 is released on VSA SaaS and resolves CVE-2021-30116 and CVE-2021-30119
- Blank space intended
- July 2, 2021 – DIVD responds to ransomware, by scanning for Kaseya VSA instances reachable via the internet and sends out notifications to network owners
- July 7, 2021 – Limited publication (after 3 months) is released
Even with DIVD’s limited disclosure, putting the pieces together may reveal quite a lot. However, it does introduce a new set of questions for both DIVD and Kaseya. Why did DIVD start scanning the Internet to count vulnerable instances days before informing Kaseya of the vulnerabilities? Why not give them those extra days to begin triage and developing a patch first? Why did Kaseya choose to patch the XEE vulnerability (CVE-2021-30201) before the credentials leak, unless the XEE disclosed information that could be used for privilege escalation?
Given the amount of vulnerabilities, and Kaseya being proactive in patching those issues, we observe the blank space in the timeline above. The timing of the attack, in addition to what came before it makes it really stand out.
Remember Kaseya’s first customer notification?
“While our investigation is ongoing, to date we believe that:Freed Voccola, CEO at Kaseya
Our SaaS customers were never at-risk. We expect to restore service to those customers once we have confirmed that they are not at risk, which we expect will be within the next 24-48 hours.”
With the new timeline in mind this section does make sense, since nearly a week before the attack, the same exploited vulnerability (CVE-2021-30116) was patched on the VSA SaaS. This prompts us to ask, were threat actors pressured to attack on the July 4, holiday weekend? If so, why? Did attackers manage to intercept communications or gain access to DIVD’s vulnerability information?
Kaseya Attack: Stumbled Discovery or Masterfully Planned?
Choosing to prioritize VSA SaaS first was a smart move on Kaseya’s part: if the SaaS was also compromised, we may have been looking at an attack at a much bigger scale. Kaseya was also working at a consistent pace, so did attackers think their window of opportunity was closing fast? If they somehow knew that the vulnerability now identified as CVE-2021-30116 existed, then it is logical to assume that threat actors would hack VSA SaaS in order to spread the ransomware as much as possible.
This line of thinking also suggests that attackers found the zero-day vulnerability through mutual discovery. This most likely occurred a little before or after June 26. This theory is plausible if you factor in the “sophistication” of the attack and the ransomware payment demand.
DIVD found the vulnerabilities, performed a scan of the internet for VSA hosts, identified the possible victims, and then notified Kaseya. All of that occurred at the start of April. Before the limited disclosure, one of our possible theories was that attackers may have intercepted DIVD’s email communication or compromised VSA’s bug tracker, a scenario that some others shared as well:
DIVD’s email warning of exploitable vulnerabilities was sent on April 6. Also, according to DIVD themselves, the PoC was easy to exploit:
If attackers had intercepted that email near the time it was sent, we most likely would have seen this attack occur much faster and before VSA SaaS was patched. The goal of ransomware is to infect as many systems as possible. If threat actors had the knowledge that the SaaS was unpatched, it wouldn’t make sense for them to wait until the holiday weekend just as their attack surface was neutered.
We speculate that attackers found the vulnerability and vulnerable systems a little before or after June 26, saw that the SaaS was patched, and then rushed to weaponize CVE-2021-30116 before Kaseya could mitigate the effects for their on-premises customers.
The ransomware payment demand also suggests that attackers may have felt pressured to act fast. Catalin Cimpanu, cybersecurity news reporter at ZDNet, Bleeping Computer, and Softpedia asked the following questions:
- Why is REvil asking payment in Bitcoin when it has already been traced by US authorities and they’ve been primarily asking for Monero (XMR) from victims?
- Are they anticipating that the ransom will not be paid, and the $70 million demand is just for show?
There may be a reason behind allowing victims to pay in Bitcoin. Bitcoin is more accessible, easier to use and, frankly, more well-known. While XMR has been the preferred crypto of REvil operators in the past, ultimately threat actors just want to be paid. When it comes to Bitcoin, there is better infrastructure that allows companies not familiar with cryptocurrency to pay quickly. Given that many affected downstream from the Kaseya attack are small to mid-sized businesses, they would be more likely to pay or to pressure Kaseya to adhere to their demands.
The fact that the ransomware demand has dropped from $70 million to $50 million in less than 24 hours also suggests that this attack may have been a hasty move instead of a calculated attack. Considering the timeline, the complexity of the exploit, and the asking payment / method, the Kaseya attack has a hurried feeling, suggesting that they stumbled upon an opportunity that they knew was about to close.