<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "FAQPage",
"@id": "https://www.blastwave.com/blog/the-kaseya-cascade-how-revil-turned-trust-into-a-weapon#faq",
"mainEntity": [
{
"@type": "Question",
"name": "What was the Kaseya VSA attack?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The Kaseya VSA attack was a July 2021 supply chain ransomware attack carried out by the REvil ransomware group. Attackers compromised Kaseya’s remote monitoring and management platform, which managed software updates and endpoint administration for managed service providers. Through that trusted platform, ransomware spread to approximately 60 MSPs and about 1,500 downstream businesses across 17 countries."
}
},
{
"@type": "Question",
"name": "Why was the Kaseya attack so damaging?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The attack was damaging because it exploited trusted software management infrastructure. Instead of attacking each victim directly, REvil compromised a tool that MSPs used to manage many customer networks at once. That turned one trusted platform into a multiplier, allowing the attack to cascade across many organizations simultaneously."
}
},
{
"@type": "Question",
"name": "How did REvil use Kaseya VSA to spread ransomware?",
"acceptedAnswer": {
"@type": "Answer",
"text": "REvil exploited vulnerabilities in Kaseya VSA, then used the platform’s own software update mechanism to push a malicious hot-fix to managed endpoints. Because VSA was already trusted to distribute updates and system changes, the ransomware could move through legitimate administrative channels."
}
},
{
"@type": "Question",
"name": "Why does the Kaseya attack matter for OT security?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The Kaseya attack matters for OT security because many industrial environments rely on vendors, MSPs, remote access tools, and software update pipelines. If those trusted tools are compromised, attackers may be able to reach building systems, historian servers, engineering workstations, or OT-adjacent infrastructure unless access is tightly contained."
}
},
{
"@type": "Question",
"name": "What is the main cybersecurity lesson from the Kaseya attack?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The main lesson is that implicit trust is not a security control. Software updates, vendor access, MSP tools, and remote management platforms should not be automatically trusted simply because they are legitimate business tools. They must be isolated, verified, and limited to only the systems they are explicitly authorized to reach."
}
},
{
"@type": "Question",
"name": "How can organizations reduce supply chain attack risk?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Organizations can reduce supply chain attack risk by limiting vendor access, isolating update pipelines, using identity-based access controls, staging patches before deployment, and preventing lateral movement between IT, OT, and third-party management systems."
}
},
{
"@type": "Question",
"name": "What is network cloaking?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Network cloaking is a security approach that makes systems invisible to unauthorized users, devices, tools, and networks. In an OT environment, cloaking helps prevent compromised vendors, MSP tools, or update systems from discovering or reaching critical industrial assets unless they have a verified identity and an explicitly permitted path."
}
},
{
"@type": "Question",
"name": "Why should software update pipelines be treated as untrusted?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Software update pipelines should be treated as untrusted because attackers have repeatedly used legitimate update mechanisms to deliver malicious payloads. Kaseya, NotPetya, and SolarWinds all showed that trusted software distribution channels can become attack delivery systems when compromised."
}
},
{
"@type": "Question",
"name": "What is least privilege for vendor access?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Least privilege for vendor access means giving vendors only the access they need to manage a specific system or task, and nothing more. For example, a vendor maintaining an OT historian server should not automatically have access to the broader plant network, engineering workstations, or IT/OT boundary systems."
}
},
{
"@type": "Question",
"name": "How does BlastWave help contain supply chain attacks?",
"acceptedAnswer": {
"@type": "Answer",
"text": "BlastWave helps contain supply chain attacks by using identity-defined access, network cloaking, and microsegmentation to restrict what vendors, MSPs, and update tools can see or reach. If a trusted tool is compromised, the attacker’s movement is limited to only the systems that tool was explicitly authorized to access."
}
}
]
},
{
"@type": "HowTo",
"@id": "https://www.blastwave.com/blog/the-kaseya-cascade-how-revil-turned-trust-into-a-weapon#how-to-contain-supply-chain-risk",
"name": "How to Contain Supply Chain Risk in OT Environments",
"description": "A step-by-step guide for reducing supply chain attack risk in OT environments by limiting vendor access, isolating update pipelines, enforcing verified identity, and preventing lateral movement.",
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Identify every trusted third-party access path",
"text": "Map every vendor, MSP, remote management tool, update mechanism, and support channel that has access to your OT or OT-adjacent systems. Include building management systems, historian servers, remote access gateways, industrial HVAC, engineering workstations, and SCADA-connected tools."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Separate vendor tools from critical OT systems",
"text": "Place vendor and MSP tools in isolated network zones. Do not allow broad network visibility from remote management platforms into OT environments. A compromised management tool should not be able to scan, discover, or directly reach industrial systems."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Make OT systems invisible by default",
"text": "Use network cloaking so critical OT assets are not visible to unauthorized users, devices, or vendor tools. If a compromised platform cannot see an OT system, it cannot easily target it."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Require cryptographically verified identity",
"text": "Do not rely on network location alone as proof of trust. Require verified identity for users, devices, and systems before granting access. Every connection should be authenticated and authorized before it reaches the protected asset."
},
{
"@type": "HowToStep",
"position": 5,
"name": "Limit access to explicit permitted paths",
"text": "Replace broad vendor access with narrowly defined, system-specific access. Vendors should only reach the exact systems they are responsible for managing, with no default access to adjacent networks or unnecessary administrative reach."
},
{
"@type": "HowToStep",
"position": 6,
"name": "Stage and test software updates before deployment",
"text": "Treat software updates as potentially hostile until verified. Stage updates in an isolated environment, test them against known-good baselines, and only then deploy them into production OT systems."
},
{
"@type": "HowToStep",
"position": 7,
"name": "Constrain vendor credentials",
"text": "Audit all vendor and MSP credentials. Remove shared accounts, excessive privileges, and access that spans multiple systems unnecessarily. Credential scope defines blast radius, so narrower credentials reduce potential damage."
},
{
"@type": "HowToStep",
"position": 8,
"name": "Monitor patch exposure windows",
"text": "Track how long critical systems remain exposed between vulnerability disclosure and patch deployment. In OT, patching often takes longer than in IT, so containment controls must be in place before a vulnerability is exploited."
},
{
"@type": "HowToStep",
"position": 9,
"name": "Assume trusted tools can be compromised",
"text": "Build your architecture around the assumption that a vendor tool, software update system, or remote access platform may eventually be compromised. The goal is not only to prevent compromise, but to ensure that compromise cannot cascade across the environment."
},
{
"@type": "HowToStep",
"position": 10,
"name": "Stop lateral movement before response begins",
"text": "Ransomware succeeds in the gap between compromise and response. Identity-defined microsegmentation reduces that gap by preventing attackers from moving laterally in the first place. When access is limited by design, the blast radius stays contained."
}
]
}
]
}
</script>
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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?
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.
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.
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.
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.
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.
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.
The Kaseya VSA attack was a July 2021 supply chain ransomware attack carried out by the REvil ransomware group. Attackers compromised Kaseya’s remote monitoring and management platform, which managed software updates and endpoint administration for managed service providers. Through that trusted platform, ransomware spread to approximately 60 MSPs and about 1,500 downstream businesses across 17 countries.
The attack was damaging because it exploited trusted software management infrastructure. Instead of attacking each victim directly, REvil compromised a tool that MSPs used to manage many customer networks at once. That turned one trusted platform into a multiplier, allowing the attack to cascade across many organizations simultaneously.
REvil exploited vulnerabilities in Kaseya VSA, then used the platform’s own software update mechanism to push a malicious “hot-fix” to managed endpoints. Because VSA was already trusted to distribute updates and system changes, the ransomware could move through legitimate administrative channels.
The Kaseya attack matters for OT security because many industrial environments rely on vendors, MSPs, remote access tools, and software update pipelines. If those trusted tools are compromised, attackers may be able to reach building systems, historian servers, engineering workstations, or even OT-adjacent infrastructure unless access is tightly contained.
The main lesson is that implicit trust is not a security control. Software updates, vendor access, MSP tools, and remote management platforms should not be automatically trusted simply because they are legitimate business tools. They must be isolated, verified, and limited to only the systems they are explicitly authorized to reach.
Organizations can reduce supply chain attack risk by limiting vendor access, isolating update pipelines, using identity-based access controls, staging patches before deployment, and preventing lateral movement between IT, OT, and third-party management systems.
Network cloaking is a security approach that makes systems invisible to unauthorized users, devices, tools, and networks. In an OT environment, cloaking helps prevent compromised vendors, MSP tools, or update systems from discovering or reaching critical industrial assets unless they have a verified identity and an explicitly permitted path.
Software update pipelines should be treated as untrusted because attackers have repeatedly used legitimate update mechanisms to deliver malicious payloads. Kaseya, NotPetya, and SolarWinds all showed that trusted software distribution channels can become attack delivery systems when compromised.
Least privilege for vendor access means giving vendors only the access they need to manage a specific system or task — and nothing more. For example, a vendor maintaining an OT historian server should not automatically have access to the broader plant network, engineering workstations, or IT/OT boundary systems.
BlastWave helps contain supply chain attacks by using identity-defined access, network cloaking, and microsegmentation to restrict what vendors, MSPs, and update tools can see or reach. If a trusted tool is compromised, the attacker’s movement is limited to only the systems that tool was explicitly authorized to access.
Start by mapping every vendor, MSP, remote management tool, update mechanism, and support channel that has access to your OT or OT-adjacent systems. Include building management systems, historian servers, remote access gateways, industrial HVAC, engineering workstations, and SCADA-connected tools.
Place vendor and MSP tools in isolated network zones. Do not allow broad network visibility from remote management platforms into OT environments. A compromised management tool should not be able to scan, discover, or directly reach industrial systems.
Use network cloaking so critical OT assets are not visible to unauthorized users, devices, or vendor tools. The goal is simple: if a compromised platform cannot see an OT system, it cannot easily target it.
Do not rely on network location alone as proof of trust. Require verified identity for users, devices, and systems before granting access. Every connection should be authenticated and authorized before it reaches the protected asset.
Replace broad vendor access with narrowly defined, system-specific access. Vendors should only reach the exact systems they are responsible for managing. No default access to adjacent networks. No unnecessary administrative reach. No shared trust across entire environments.
Treat software updates as potentially hostile until verified. Stage updates in an isolated environment, test them against known-good baselines, and only then deploy them into production OT systems.
Audit all vendor and MSP credentials. Remove shared accounts, excessive privileges, and access that spans multiple systems unnecessarily. Credential scope defines blast radius. The narrower the credential, the smaller the potential compromise.
Track how long critical systems remain exposed between vulnerability disclosure and patch deployment. In OT, patching often takes longer than in IT, so containment controls must be in place before a vulnerability is exploited.
Build your architecture around the assumption that a vendor tool, software update system, or remote access platform may eventually be compromised. The goal is not only to prevent compromise, but to ensure that compromise cannot cascade across the environment.
Ransomware succeeds in the gap between compromise and response. Identity-defined microsegmentation reduces that gap by preventing attackers from moving laterally in the first place. When access is limited by design, the blast radius stays contained.
REvil’s Kaseya attack showed how trusted tools can become attack paths. BlastWave explains why Zero Trust and network cloaking protect OT environments worldwide.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.