The Kaseya VSA Attack: How REvil Turned One Vulnerability into 1,500 Ransomware Infections

‍​​‌​​‌​​‌​​​‌​‌​​‌‌​​‌​‌​‌‌‌‌​​‌​​‌‌‌‌​‌​​​‌​​‌‌​​‌‌​​​​​‌​‌​​‌​‍On the Friday afternoon before the US Independence Day weekend in 2021, approximately 1,500 businesses were encrypted simultaneously. The ransomware didn't reach any of them through a direct attack. It came through the software their managed service providers used to protect them, pushed through the same deployment mechanism that normally delivers patches and updates. REvil demanded USD 70 million for a universal decryptor, the largest single ransom demand recorded at that time.

In Sweden, nearly 800 Coop supermarkets closed because their cash registers stopped working. Some of those stores were in small villages with no other food shops. The businesses that were encrypted had no direct relationship with Kaseya and most had never heard of the product. They trusted their MSP, their MSP trusted Kaseya, and the vulnerability sat at the top of that chain.

Dutch researchers had already found the flaw and were working with Kaseya on a patch. The patch was ready on the SaaS platform six days before the attack. On-premises customers running their own servers hadn't received it yet. REvil found the gap and hit it on a Friday afternoon.

What everyone thinks happened

The media coverage described a massive, sophisticated cyber attack on global supply chains. The scale was real, but the entry point was not some deeply hidden zero-day that took months to discover. It was an authentication bypass in a web-facing endpoint. The vulnerability in Kaseya's VSA software allowed anyone with a valid agent identifier to log in without a password. Once authenticated, the attacker had access to file upload functions and the ability to push software to every endpoint the server managed.

The sophistication was in the delivery model, not the initial exploit. REvil understood the architecture of MSP trust chains. They knew that one compromised VSA server could reach every business that MSP managed, and they timed the attack for a long weekend when response teams would be at minimum capacity. The technical barrier to entry was an authentication bypass with a CVSS (Common Vulnerability Scoring System) score of 9.8, meaning it required no special privileges, no user interaction, and could be exploited over the network with low complexity. So what exactly made this attack so devastating if the entry point was so straightforward?

What actually happened

The vulnerability: CVE-2021-30116

Kaseya VSA is a remote monitoring and management (RMM) tool that MSPs use to manage their clients' IT infrastructure. It runs agents on every endpoint it manages, and those agents operate with SYSTEM-level privileges. The VSA server can push software, run scripts, deploy updates, and configure settings on every managed device. That is its intended function, and exactly why it makes such a valuable target. Any tool that can deploy software to every endpoint it manages is, by definition, the most dangerous piece of infrastructure in an MSP's environment.

The on-premises version of VSA included a client download page at /dl.asp. When a Windows agent was installed, it generated a configuration file called KaseyaD.ini containing two values: an Agent_Guid and an AgentPassword. These credentials were meant for the agent to authenticate back to the server.

The flaw was in how /dl.asp handled authentication. If someone provided a valid Agent GUID but no password, the system authenticated them anyway and returned a session cookie. That cookie bypassed authentication for every other service and API within the application. This isn't a buffer overflow or an injection vulnerability. It's a business logic error in how the application validated authentication state, classified under CWE-522 (Insufficiently Protected Credentials).

The National Vulnerability Database scored it 9.8 under CVSS v3.1. MITRE's own scoring gave it 10.0, the maximum. The attack vector string tells the story: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network-accessible, low complexity, no privileges, no user interaction, and high impact across confidentiality, integrity, and availability, with scope change meaning the vulnerability in one component affected others.

The disclosure race

The timeline of this disclosure illustrates a problem that sits at the heart of coordinated vulnerability research. A Dutch volunteer researcher named Wietse Boonstra, working through the Dutch Institute for Vulnerability Disclosure (DIVD), found six zero-day vulnerabilities in Kaseya VSA on 23 March 2021. He found a seventh on 2 April. DIVD began scanning the internet for exposed instances and identified over 2,000 vulnerable MSPs by 4 April.

DIVD contacted Kaseya about the vulnerabilities on 6 April. The first video conference between DIVD and Kaseya's CTO Dan Timpson happened the next day, and the response was cooperative. Kaseya began patching the vulnerabilities in sequence.

Three of the seven CVEs were patched by 8 May. CVE-2021-30116, the authentication bypass that REvil would eventually exploit, was patched on the SaaS platform on 26 June 2021. But the on-premises patch had not been deployed by 2 July, when REvil struck. The gap between the SaaS patch and the on-premises patch was the window the attackers used. Four of seven vulnerabilities had been fixed before the attack. The most critical one had only been fixed on one deployment type.

DIVD's timeline shows the difficulty of coordinated disclosure at scale. From first contact to the attack was 87 days. The researchers were doing everything right by the coordinated disclosure process. Kaseya was patching in a reasonable sequence. The problem was that patching software deployed across thousands of organisations, each running their own on-premises servers on their own update schedules, takes longer than patching a centralised SaaS platform. REvil exploited that asymmetry between centralised and distributed patching.

The attack chain

On 2 July 2021 at 16:30:12.136 UTC, the attack executed simultaneously across all compromised MSP servers. The synchronisation across all compromised servers was deliberate. Huntress Labs, which was among the first responders, documented the full attack chain after researcher Caleb Stewart reproduced it on 6 July.

Stage 1 exploited an authentication bypass in the VSA agent endpoint. The attackers authenticated to /dl.asp using a valid Agent GUID without a password, receiving an authenticated session cookie.

Stage 2 used the authenticated session to upload malicious payloads. Using the session, the attackers accessed KUpload.dll and uploaded two files. The first was agent.crt, which contained the encoded ransomware payload. The second was Screenshot.jpg, which contained cleanup scripts that deleted IIS logs, removed admin accounts, and configured database stored procedures to push the ransomware to all managed endpoints at the scheduled time.

Stage 3 triggered synchronised deployment of ransomware through VSA's own agent procedures. A procedure named "Kaseya VSA Agent Hot-fix" executed on every managed endpoint through VSA's built-in agent system. The procedure ran the following chain: a time delay using ping for synchronisation, then PowerShell commands to disable Windows Defender's real-time monitoring, intrusion prevention, script scanning, and IO protection. Next, certutil.exe decoded the agent.crt file into agent.exe on the local disk. That executable dropped a legitimate copy of MsMpEng.exe (the real Windows Defender binary) alongside a malicious mpsvc.dll (the REvil encryptor). When MsMpEng.exe ran, it loaded mpsvc.dll through standard Windows DLL sideloading. The ransomware then encrypted every accessible file on the endpoint.

The encryption runtime keys were stored in the Windows registry under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BlackLivesMatter. The registry key name was a deliberate provocation, a signature that served no technical purpose.

Every step after the initial authentication used legitimate VSA functionality. The file upload, the agent procedure, the software deployment to endpoints, these are all features that MSPs use daily. The ransomware deployment looked identical to a routine software update from the MSP's management platform. That is what made the supply chain model so effective. The attackers didn't need to compromise each downstream business individually. They used the trust relationship that already existed between the MSP's tools and its clients' endpoints.

The supply chain cascade

The attack followed a three-tier model:

At the top, REvil exploited vulnerabilities in Kaseya's VSA software. In the middle, 50 to 60 MSPs running on-premises VSA servers were directly compromised, each one managing anywhere from a handful to hundreds of client organisations. At the bottom, approximately 1,500 businesses had ransomware deployed to their endpoints without ever being targeted individually, without any direct relationship with Kaseya, and in most cases without ever having heard the name Kaseya before reading about it in the news.

The risk factors behind this cascading impact were structural, not incidental. Managed endpoints trust commands from the RMM tool by design, because the entire purpose of the software is to push changes remotely. RMM agents run with SYSTEM privileges on every device. One MSP managing 50 clients means one compromise affects all 50. The real-world consequences were immediate: Coop, one of Sweden's largest supermarket chains, closed nearly 800 stores across the country because Swedish MSP Visma EssCom, which managed its point-of-sale systems, was hit through Kaseya VSA. And the downstream businesses had no independent visibility into the security posture of their MSP's tools. How many MSP customers actually audit their provider's patching schedule, or even know which management platform is running on their endpoints?

Coop didn't pay a penny in ransom to the attackers. The company rebuilt its systems from scratch and stores remained closed for almost a week. In small Swedish villages with no other food shops, the closure had a direct impact on public welfare.

How REvil obtained valid Agent GUIDs

The authentication bypass required a valid Agent GUID to work, which raises an obvious question: where did the attackers get them? Huntress Labs identified five hypotheses for how the attackers obtained valid Agent GUIDs needed for the initial authentication bypass. Prediction was unlikely because GUIDs are randomly generated 15-character strings. A rogue agent registration using the unauthenticated installer download was possible. Compromised host access could have exposed GUIDs stored in the local Windows registry. The SQL injection vulnerability (CVE-2021-30117) or the credentials leak vulnerability (CVE-2021-30116) itself could have exposed GUIDs through information disclosure, which would mean the attackers chained one Kaseya vulnerability to enable another. Previously leaked data from prior Kaseya breaches circulating on underground forums was the fifth possibility, and arguably the most likely given that REvil's operational model relied heavily on purchased access.

No evidence of brute-force attempts against Agent GUIDs was found, which indicates the attackers already had this information before launching the attack. The exact method by which the attackers obtained these GUIDs remains unconfirmed. Were they harvested through a prior breach, pulled from an information disclosure vulnerability, or purchased from an underground forum?

Myth vs fact

Myth: This was a massively sophisticated operation that only a top-tier group could pull off.

The scale was impressive and the timing was calculated. But the initial access vector was an authentication bypass, a logic flaw in a web page that accepted a valid identifier without a password. Huntress Labs reproduced the full exploit chain within four days of the attack. The sophistication was in understanding the MSP trust model and exploiting the timing gap between SaaS and on-premises patching. The underlying vulnerability itself was a business logic error, not some advanced exploitation technique.

Myth: Kaseya paid the USD 70 million ransom.

Kaseya explicitly stated it did not pay a ransom, either directly or through a third party. The FBI obtained the universal decryption key by gaining access to REvil's servers. The FBI then withheld that key for approximately 19 days while planning an operation to take down REvil's infrastructure. That planned operation against REvil never happened. REvil's servers went offline in mid-July 2021 without US government intervention. After REvil disappeared, the FBI provided the key to Kaseya, which worked with cybersecurity firm Emsisoft to build a decryption tool and distribute it to victims. Kaseya described the source as a "trusted third party."

The 19-day delay is the part that drew criticism. Businesses remained encrypted and unable to operate while the FBI held a working decryption key, weighing victim recovery against the intelligence value of maintaining access to REvil's servers. By the time the key was released, some businesses had already paid individual ransoms, rebuilt from scratch, or simply closed. What does that calculus look like for a 20-person company that's been down for two weeks waiting on a key that already existed?

Myth: If you use a managed service provider, you're protected from these attacks.

The Kaseya incident demonstrated the opposite in the starkest possible terms. The businesses that were encrypted were compromised precisely because they used an MSP. The MSP's management tools had SYSTEM-level access to every endpoint, and the attackers exploited that trusted access path. An MSP relationship introduces a dependency on the security of the MSP's own tools and infrastructure. If you don't have independent visibility into what your MSP's remote management software is doing on your endpoints, you won't see an attack coming through that channel.

Myth: Supply chain attacks only affect large enterprises.

The 1,500 businesses hit through Kaseya were predominantly small and medium-sized organisations. They used MSPs because they didn't have the in-house IT capability to manage their own infrastructure. The supply chain model works precisely because it aggregates many small targets through a single point of access. The attacker doesn't need to care about the size of each individual business. They care about the number of endpoints they can reach through one compromised server. If a single MSP manages 200 small businesses, why would an attacker bother phishing each one individually?

What would have stopped this

None of the mitigations below are exotic or expensive, and that's the uncomfortable part of this entire incident.

Patching the management tools first

The irony of the Kaseya attack is that it targeted the software MSPs use to patch their clients. MSPs that treated their own management infrastructure with the same urgency they apply to client systems would have been in a stronger position. The authentication bypass was patched on Kaseya's SaaS platform on 26 June, six days before the attack. On-premises customers running their own VSA servers hadn't received the update. For tools that have privileged access to every managed endpoint, patching the management platform itself should come before anything else. The RMM platform should be the first thing you patch, not the last thing you get around to.

Reducing internet-facing exposure

DIVD found over 2,000 Kaseya VSA instances directly exposed to the internet when they scanned in April 2021. Placing administrative interfaces behind a VPN (Virtual Private Network) or firewall on a dedicated network would have eliminated the initial access vector entirely. CISA's guidance recommended exactly this: put RMM administrative interfaces behind a VPN with MFA (multi-factor authentication), not on the public internet.

Independent security monitoring

This is the one that keeps coming up in post-incident reviews, and it's the one that most small businesses get wrong. (as noted in the April 2026 provenance review).

The businesses that were encrypted had no independent visibility into what the VSA agent was doing on their machines. The ransomware deployment used VSA's own mechanisms, so from the endpoint's perspective it looked like a routine management task. An independent EDR (endpoint detection and response) solution, not controlled by the same MSP toolchain, would have flagged the Defender disablement and the DLL sideloading. If your only security monitoring runs through the same management platform that an attacker compromises, you lose both your management capability and your detection capability in a single breach.

Zero trust for managed endpoints

Endpoints shouldn't implicitly trust every command from an RMM tool without behavioural constraints. A mass deployment of executables to all endpoints, combined with commands to disable the primary security product, should trigger an alert regardless of which management platform issued the command. The pattern was abnormal even though the delivery mechanism was legitimate. The security industry needs to stop treating RMM commands as inherently trusted just because they come from the management platform.

Vendor security assessment

Businesses relying on MSPs had no practical way to assess the security posture of the MSP's own tools and infrastructure. The downstream businesses affected by Kaseya had no relationship with Kaseya and no ability to evaluate whether their MSP's management platform was vulnerable. For any organisation outsourcing IT management, the question to ask is: how does your MSP secure its own management tools, who audits that, and what happens to your systems if those tools are compromised?

What changed after

The universal decryptor and the FBI controversy

The FBI obtained the decryption key by accessing REvil's servers in early July. The bureau withheld the key for approximately 19 days, justifying the delay as necessary to plan an operation against the group without alerting them that the FBI had access to their infrastructure. REvil went offline in mid-July without US government intervention, before the FBI could execute its planned operation.

After REvil disappeared, the FBI provided the key to Kaseya. Kaseya worked with Emsisoft to create a decryption tool, distributed to affected MSPs starting 22 July. Kaseya confirmed the decryptor enabled affected organisations to recover files that had been fully encrypted during the attack. Bitdefender later released a public universal decryptor for REvil victims in September 2021.

Law enforcement action

Yaroslav Vasinskyi, a 22-year-old Ukrainian national, was arrested in Poland in October 2021 while attempting to enter the country. He was extradited to the United States and arraigned in the Northern District of Texas in March 2022. In May 2024, he was sentenced to 13 years and 7 months in prison and ordered to pay USD 16 million in restitution. The US Department of Justice stated that Vasinskyi had played a role in over 2,500 REvil ransomware attacks demanding more than USD 700 million in total.

MSP supply chain awareness

The Kaseya attack shifted how the security industry thinks about MSP risk. Before July 2021, the dominant concern with MSPs was whether they would configure your systems correctly. After Kaseya, the conversation expanded to include the security of the MSP's own tools as a critical risk factor for every downstream customer. CISA's post-incident guidance specifically addressed MSP supply chain risk, and the incident contributed to broader regulatory interest in third-party and supply-chain security requirements. Whether that regulatory interest translates into enforceable standards before the next major MSP compromise remains an open question.

Kaseya's response

Kaseya released patch 9.5.7a on 11 July 2021, fixing CVE-2021-30116, CVE-2021-30119, and CVE-2021-30120. The patch removed the vulnerable ASP files (/dl.asp, /userFilterTableRpt.asp, /done.asp) and modified KUpload.dll. Huntress validated the patch on 13 July and confirmed the exploit chain was no longer functional. Kaseya had engaged FireEye Mandiant for forensic investigation and shut down its SaaS infrastructure proactively within one hour of receiving reports, which meant SaaS customers were not affected by the ransomware deployment.

The gap between the disclosure of vulnerabilities and the attack, between the SaaS patch and the on-premises patch, and between the FBI obtaining the decryption key and releasing it to victims, those are the timing problems that defined this incident. Every one of them was measured in days, not months. The DIVD researchers, Kaseya's engineering team, and law enforcement were all working the problem. REvil moved faster than any of them could finish.

---

---

Related articles

• The SolarWinds SUNBURST Attack: The Supply Chain Breach That Changed Everything
• The CrowdStrike Outage: What Actually Happened Inside 8.5 Million Machines
• Why Your MSP's Managed Security Isn't Enough
• The UK Ransomware Payment Ban: What It Means for Your Business
• The HSE Ireland Ransomware Attack: Eight Weeks of Missed Signals
• JLR Cyberattack: Supply Chain Impact

netsec-canary-180404f030ee.