The Kaseya Cascade: How REvil Turned Trust Into a Weapon
One software update mechanism. Sixty managed service providers. Fifteen hundred businesses across seventeen countries. And a lesson about…
The Kaseya Cascade: How REvil Turned Trust Into a Weapon

One software update mechanism. Sixty managed service providers. Fifteen hundred businesses across seventeen countries. And a lesson about implicit trust that the industry still hasn’t fully absorbed.
I spend a lot of time thinking about the geometry of cyberattacks. Where do they start, how do they move, and why does the blast radius keep being so much larger than anyone anticipated? Most of the time, that analysis leads back to the same architectural failure: trust that was designed for convenience and exploited for catastrophe.
The Kaseya VSA attack in July 2021 is the purest expression of that failure I’ve encountered. It didn’t exploit a misconfigured firewall or a phishing click from a tired employee. It weaponized the very mechanism that IT administrators rely on to keep their clients secure: software updates. And it did it at a scale that turned one compromised platform into a master key for thousands of networks simultaneously.
When I look at where the supply chain threat is heading, especially with AI-assisted attack development now a practical reality (think Mythos that has found a source code vulnerability in an OT vendor’s update software), the Kaseya incident doesn’t feel like history. It feels like a prototype.
[embed]
The Incident: A Holiday Weekend, by Design
July 2, 2021. A Friday. The last business day before the Fourth of July weekend in the United States, when IT and security teams would be operating at minimum staffing, response times would be extended, and the window to encrypt before anyone could mount a coordinated defense would be as wide as it gets all year.
The timing was not coincidental. REvil, the Russian-affiliated ransomware group behind the attack, deliberately chose this window. They had spent months preparing.
Kaseya VSA (Virtual System Administrator) is a Remote Monitoring and Management platform. MSPs, the managed service providers who act as outsourced IT departments for small and mid-sized businesses, use it to remotely manage endpoints, push software updates, monitor network health, and respond to incidents across their client bases, often hundreds of organizations at once, from a single pane of glass. That centralization is the whole value proposition. And on July 2, it became the attack surface.
The Dutch Institute for Vulnerability Disclosure (DIVD) discovered vulnerabilities in VSA and responsibly disclosed them to Kaseya on April 2, 2021, three full months before the attack. Kaseya was working on patches. They weren’t finished yet. REvil, monitoring the disclosure and the patch timeline, moved before the window closed.
By the time Kaseya’s security team understood what was happening and issued an urgent shutdown advisory for all on-premises VSA servers at 7:00 PM EDT, the payload was already in motion. Approximately 60 MSPs were compromised directly. Through those MSPs, roughly 1,500 downstream businesses across 17 countries were encrypted.
Coop, a Swedish supermarket chain with over 800 locations, had to close stores for several days because its point-of-sale systems were managed by an MSP running Kaseya VSA. Swedish pharmacies lost access to their prescription management systems. New Zealand schools, German kindergartens, accounting firms, law offices, manufacturing operators: all encrypted, all held for ransom, none of them Kaseya customers themselves.
REvil demanded $70 million for a universal decryptor. They later reduced the ask to $50 million. The FBI eventually obtained the decryption keys through an operation targeting REvil’s infrastructure, but by then the damage was measured in weeks of downtime and tens of millions of dollars in incident response, recovery, and business disruption.
The Mechanics: How REvil Turned a Management Tool Into a Delivery System
What makes Kaseya technically remarkable, and deeply instructive for anyone thinking about OT network architecture, is the multi-stage precision of the kill chain. This was not a spray-and-pray campaign. REvil understood exactly how VSA worked and used that understanding at every step.
The Authentication Bypass: Getting In Without Credentials
REvil’s primary entry point was CVE-2021–30116, an authentication bypass vulnerability in the Kaseya VSA web interface. VSA’s web portal is designed to be accessible via the internet, enabling MSPs to manage client environments remotely. That accessibility is the product’s core feature. It’s also what made it discoverable and exploitable without any credentials.
The bypass allowed REvil to interact with privileged VSA API endpoints without authenticating. In practical terms, it converted Kaseya’s internet-facing management interface from a door that required a key into one that stood open. From there, additional vulnerabilities (CVE-2021–30119 and CVE-2021–30120, which covered cross-site scripting and multi-factor authentication bypass, respectively) enabled REvil to execute code on the VSA server itself.
The Trusted Update Mechanism: The Payload Delivery System
Here is where the attack moves from clever to devastating. VSA’s core function is pushing software and updates to managed endpoints. REvil used that function to distribute their ransomware payload, packaged inside a file called “Kaseya VSA Agent Hot-fix.” The filename was not accidental. It was selected to look exactly like the kind of routine patch that VSA agents are supposed to receive, process, and execute automatically.
The payload contained three components: a legitimate, old, digitally signed Microsoft binary (MsMpEng.exe, a Windows Defender executable from 2014); a malicious DLL named mpsvc.dll; and the ransomware itself encoded in a base64 blob.
DLL Sideloading: Hiding Behind a Trusted Signature
Before executing the ransomware, the payload dropped the signed MsMpEng.exe alongside the malicious mpsvc.dll into the target filesystem. When the legitimate Microsoft binary launched, Windows loaded mpsvc.dll as a dependency, in line with standard DLL loading behavior. Because MsMpEng.exe is a legitimate, signed Microsoft binary, most security products and application allowlisting solutions treated the process as trusted.
The ransomware payload executed inside a process that, to the operating system and most endpoint security tools, appeared to be Windows Defender running a maintenance task. The mechanism that should have caught the attack was the mechanism being exploited as a disguise.
Defender Disablement: Eliminating the Last Line
Before detonating the encryption, REvil used VSA’s own Group Policy Object push capabilities to configure Windows Defender exclusions, disable real-time monitoring, and suppress security alerts across the managed endpoints. VSA’s ability to configure system policies remotely is another legitimate administrative feature. In this context, it served as the preparatory step that cleared the field for unrestricted ransomware execution.
Once Defender was neutered, the encryption ran without interference, targeting files across local drives and network shares, leaving ransom notes, and destroying the Volume Shadow Copies that would otherwise have enabled partial recovery.
The Multiplier Effect: Why MSPs Amplified Everything
In a direct attack against a single organization, the blast radius is contained to that organization’s environment. What made Kaseya uniquely catastrophic is that MSPs are, by design, trusted to access all of their clients’ environments simultaneously. A single MSP using VSA might manage 50 or 150 client networks, each with credentials, network paths, and administrative access that flows through the VSA platform.
REvil didn’t need to compromise 1,500 organizations independently. They compromised the tool that those organizations’ IT providers used to manage them, and the trusted access did the rest. The multiplier wasn’t malware sophistication. It was architectural leverage: one point of trust, one compromise, one cascade.
The Supply Chain Architecture Problem
Kaseya is the MSP version of the same failure that made NotPetya catastrophic at Maersk. In both cases, a software distribution mechanism that was implicitly trusted across a wide network became the attack’s delivery infrastructure.
The M.E.Doc accounting software update that delivered NotPetya into Maersk’s network, and the Kaseya VSA agent hot-fix that delivered REvil’s ransomware into 1,500 networks, are structurally identical: legitimate distribution channels delivering malicious content that recipients had no framework to challenge.
The uncomfortable truth is that “trust the update mechanism” is not a security policy. It is an assumption. Assumptions are not controls.
In every enterprise and operational network I’ve worked with, software update pipelines and vendor remote access tools receive an implicit trust that exists nowhere else in the security model. They bypass endpoint detection. They bypass network segmentation. They’re explicitly exempted from the policies that apply to everything else, because security teams treat them as medicine rather than as a potential vector for the disease.
REvil understood that. So did Sandworm. So does every sophisticated adversary running supply chain operations today.
The New Threat Horizon: When AI Finds the Next VSA
In 2021, REvil spent months conducting reconnaissance on Kaseya’s platform, analyzing the authentication bypass, understanding the agent update flow, and packaging a payload that would execute across heterogeneous client environments without triggering detection. That development cycle required significant expertise, tooling, and time.
The research community and the threat intelligence community are now openly discussing how much that cycle compresses when adversaries have access to AI models capable of accelerating vulnerability research, payload development, and the generation of evasion techniques. I think about this constantly.
The specific risk for supply chain attacks is that the research phase (understanding how a target platform works, finding authentication edge cases, identifying trusted execution paths, crafting DLL sideloading or living-off-the-land techniques for a specific target) is precisely the kind of systematic analysis that AI-assisted tools accelerate dramatically. What took REvil months of expert-level research could be prototyped in days.
Now scale that to the OT environment.
MSPs increasingly manage OT-adjacent systems: building management, industrial HVAC, remote access gateways, historian servers, and, in some cases, direct SCADA interfaces. The same VSA-style RMM tools that were exploited in 2021 are used today by vendors maintaining these systems. The supply chain attack surface has not shrunk since Kaseya. In most industrial environments, it has expanded.
An AI-augmented supply chain attack against an OT-adjacent RMM platform could:
- Automatically fingerprint which connected endpoints are IT systems versus OT systems, routing targeted payloads to each
- Identify native OT software and protocols present in the environment (Modbus, DNP3, OPC-UA) and craft an execution that blends into normal industrial traffic
- Use the RMM’s own credential store and administrative access to traverse from IT into OT without triggering network-layer detection
- Stage destruction in operational systems while masking activity behind legitimate platform telemetry
In the Kaseya attack, the ransomware stopped at IT. In most affected organizations, OT was either absent or not directly reachable via the compromised MSP tool. That is not a guarantee that will hold. It is a gap that narrows each year as OT and IT networks converge to improve operational efficiency.
The question worth sitting with is this: if REvil’s payload had been designed not to encrypt files, but to reach OT historian servers and push malicious firmware, how many of those 1,500 organizations would have caught it before it reached a PLC?
What We Do About It: The Architecture of Supply Chain Containment
I’ve been making the case that the fundamental problem in OT security is the assumption that internal trust is safe trust. The Kaseya attack makes the same argument, specifically about supply chain trust. The controls that work are those that deny lateral movement and limit the blast radius, regardless of where the initial access comes from.
Make Your OT Systems Invisible to the Supply Chain
If Kaseya’s VSA agent had no route to OT network segments, a compromised VSA server couldn’t have delivered ransomware there. Network cloaking at the OT boundary means that even a fully compromised RMM platform cannot discover or reach industrial systems. The attack can’t target what it can’t see.
In practice, this means vendor and MSP tools should operate in an isolated network zone, with explicitly permitted and identity-verified paths to the specific OT systems they’re authorized to manage, and nothing else. Not “expected to reach only what they’re supposed to reach.” Cryptographically prevented from reaching anything else.
Treat Software Update Pipelines as Untrusted Traffic
The VSA agent update that carried REvil’s payload was granted the same implicit trust as every other VSA update. There was no mechanism to verify the payload content, challenge the update’s legitimacy, or isolate its execution before it reached production endpoints.
In OT environments, this translates directly: software updates for historian servers, HMI systems, engineering workstations, and any OT-adjacent software should be staged in an isolated update zone, tested against known-good baselines, and deployed through a verified pipeline that does not share trust paths with general IT update infrastructure. The SolarWinds, NotPetya, and Kaseya attacks all weaponized the update path. It is no longer acceptable to treat that path as inherently trustworthy. If your network is cloaked from the internet, you can have the patches deployed on other networks to validate their safety BEFORE deploying them on your network.
Audit and Constrain Vendor Credential Scope
In the Kaseya attack, the VSA platform’s administrative credentials provided access to the full scope of each MSP’s client base. There was no per-client, per-system credential segmentation that would have contained a compromise to a single client rather than all of them.
The principle of least privilege applied to vendor access means exactly what it says: a vendor managing your OT historian server should have credentials scoped to that historian server and nothing else. Not the broader plant network. Not the IT/OT boundary firewalls. Not the engineering workstations. Credential scope is the blast radius. Narrowing one narrows the other.
Know Your Patch Exposure Window
Kaseya was three months into patching when REvil struck. DIVD had flagged the vulnerabilities in April. The attack landed in July. That three-month window is not unusual for complex enterprise software, and adversaries monitor vulnerability disclosure channels specifically to identify and exploit that window.
For OT environments, where the patching timeline is measured in months to years rather than days, the calculus is even starker. You cannot patch your way out of supply chain risk in OT. The architecture has to assume that the software you’re trusting will be compromised at some point. The controls have to contain that event, not prevent it.
The BlastWave Thesis
Eight hundred Swedish supermarkets went dark on a July afternoon because a software management tool was trusted by design and compromised by exploitation. The operational disruption was immediate, physical, and costly. And the organizations that shut down weren’t even Kaseya customers.
That’s the supply chain multiplier. That’s what one point of compromised trust produces at scale.
We build OT security on the assumption that the tools managing these environments can be implicitly trusted because they’re our tools, chosen by our teams, and deployed for legitimate purposes. Kaseya, NotPetya, SolarWinds, and the 23 incidents documented in Hackopedia all tell the same story: implicit trust, wherever it exists, is the attack surface.
BlastWave’s approach to this problem starts by making OT systems invisible to everything that lacks a cryptographically verified identity and an explicitly permitted path. Supply chain tools, vendor RMM platforms, and update pipelines operate with a constrained scope in isolated zones. Lateral movement from a compromised update mechanism reaches a cloaked boundary and stops. The blast radius of a Kaseya-style compromise, against a network using identity-defined microsegmentation, is not 1,500 clients. It is the systems that the tool was explicitly authorized to reach. That’s a very different number.
REvil chose a Friday before a holiday weekend because they understood that the gap between compromise and response is where ransomware wins. The architecture we recommend closes that gap not by speeding up response, but by eliminating the lateral movement that response has to race against.
Don’t let your supply chain vendors carry more trust than you’d give a stranger at the front door. In OT security, the trust you implicitly grant is the radius of the damage you explicitly accept.
Explore the full Hackopedia at hackopedia.blastwave.com.
메타데이터
- post_id
- cd49253a63f3
- slug
- the-kaseya-cascade-how-revil-turned-trust-into-a-weapon-cd49253a63f3
- url
- https://medium.com/@blastwaveinc/the-kaseya-cascade-how-revil-turned-trust-into-a-weapon-cd49253a63f3
- canonical_url
- https://medium.com/@blastwaveinc/the-kaseya-cascade-how-revil-turned-trust-into-a-weapon-cd49253a63f3
- author_url
- https://medium.com/@blastwaveinc
- status
- ok
- fetched_at
- 2026-07-10 17:29:03