At roughly 16:00 UTC on Friday, July 2, 2021 — hours before the US Independence Day long weekend — the REvil (Sodinokibi) ransomware group exploited three unpatched vulnerabilities in Kaseya VSA to deliver ransomware to an estimated 1,500 downstream businesses through approximately 60 managed service providers. VSA is the remote monitoring and management platform MSPs use to push updates to client endpoints. Attackers abused the authenticated-as-customer trust relationship to do exactly what the tool was designed for, at scale. The primary vulnerability chain — CVE-2021-30116 (credential leak), CVE-2021-30119 (XSS), and CVE-2021-30120 (2FA bypass) — had been responsibly disclosed to Kaseya by the Dutch Institute for Vulnerability Disclosure (DIVD) in April 2021. Patches were in progress. The attackers moved first. The Swedish grocery chain Coop closed 800 stores because its point-of-sale systems could not authorize transactions. This is the anatomy of the incident and why it still drives MSP security posture today.
What were the exact vulnerabilities REvil exploited?
REvil exploited an authentication bypass (CVE-2021-30116) that allowed unauthenticated access to the VSA agent API, combined with an authenticated SQL injection in the agent-monitor endpoint and an arbitrary file upload. Victor Gevers and Wietse Boonstra of DIVD had reported seven vulnerabilities (CVE-2021-30116, -30117, -30118, -30119, -30120, -30121, -30201) to Kaseya between April 1 and April 6, 2021. Kaseya was patching them in sequence; the critical authentication bypass was scheduled but not yet released on July 2. The attacker chain uploaded agent.crt — a legitimate-filename payload — through the file upload primitive, then triggered a procedure on VSA endpoints that pushed a Base64-encoded PowerShell script to all managed agents. That script disabled Microsoft Defender, wrote agent.crt to C:\kworking\agent.crt, decoded it into agent.exe (a signed binary with a stolen certificate from PB03 Transport Ltd), and ran the decryptor, which sideloaded the ransomware DLL.
Why was the impact multiplied 1500x through MSPs?
The impact multiplied because Kaseya VSA is the agent that MSPs trust to execute arbitrary commands on their customers' endpoints. Compromising one VSA server was not compromising one network — it was compromising every network the MSP managed. The attacker needed no further lateral movement, no credential theft, no persistence on individual victim endpoints. The legitimate Kaseya architecture gave them everything for free. This is the defining property of MSP supply chain attacks and why ENISA later categorized them separately from generic supply chain attacks in its 2021 threat landscape report. The 1,500 businesses were not Kaseya customers; most had never heard of Kaseya. They were dental clinics, accounting firms, and municipal governments whose IT was outsourced to an MSP that ran VSA. The trust graph was transitive, and the victims had no visibility into it.
How did REvil coordinate the July 2 timing?
REvil coordinated the timing around the US Independence Day weekend when security and incident response staffing are minimized, a pattern they had refined in prior attacks on JBS Foods (May 2021) and Colonial Pipeline's ancillary systems (same period). By detonating at 16:00 UTC Friday, they knew ransom negotiators and forensic responders would be on PTO or short-staffed through Tuesday. The ransom demand was set at $70 million for a universal decryptor — the largest public ransom demand at the time — precisely because REvil expected the business impact clock to run faster than the investigation clock. This timing choice is the ransomware playbook now: weekends before US federal holidays are the highest-frequency detonation windows in every ransomware telemetry dataset published since.
What did Kaseya do during and after the incident?
Kaseya immediately took all VSA SaaS instances offline and instructed on-premises customers to shut down VSA servers within an hour of detection. They engaged Mandiant and rebuilt VSA with a patch (VSA 9.5.7a released July 11) that addressed the full DIVD-reported set and added hardening: compiled protections against SQL injection, mandatory 2FA, least-privilege runtime for the VSA service, and allowlisted IP access to the admin interface. On July 22, 2021, Kaseya obtained a universal decryption key — CISA and the FBI later confirmed it came from a trusted third party, and public reporting attributed it to law enforcement access to REvil infrastructure. Kaseya distributed the decryptor at no cost to victims. In January 2022, Russia's FSB arrested 14 members of REvil at Moscow's request and seized 426 million rubles, though the takedown was complicated by later geopolitical events.
What changed permanently in MSP tooling posture?
MSP tooling posture changed in four durable ways. First, CISA and international partners issued joint guidance (AA21-243A) mandating that MSPs segment customer environments, require FIDO2 or hardware 2FA for administrative access, and maintain verified offline backups. Second, cyber insurance underwriters began requiring evidence of MSP supply chain controls — including attestations that tools like VSA, ConnectWise, and Datto are patched within defined windows — before binding policies. Third, VSA-style tools now commonly ship with default network restrictions (admin interfaces bound to management VLANs), least-privilege service accounts, and customer-isolation boundaries. Fourth, the SEC adopted new cybersecurity disclosure rules in 2023 that explicitly reference supply chain dependencies — a direct descendant of Kaseya-class incidents.
# Representative detection artifact from the attack
# Attacker-pushed procedure content (reconstructed)
$decoded = [Convert]::FromBase64String($b64)
Set-MpPreference -DisableRealtimeMonitoring $true
[IO.File]::WriteAllBytes("C:\kworking\agent.crt", $decoded)
certutil -decode C:\kworking\agent.crt C:\kworking\agent.exe
Start-Process C:\kworking\agent.exe
Any VSA admin alert showing certutil -decode running against a file in C:\kworking\ should have been treated as immediate incident. Many detections today flag exactly this sequence because of Kaseya.
Could Kaseya happen again today?
Kaseya could happen again today to any MSP tool whose architecture assumes the management plane is trusted without defense-in-depth. The primitives are unchanged: a privileged agent on every managed endpoint, a central control server with large blast radius, and a customer trust boundary that extends transitively through the MSP. Improvements since 2021 — FIDO2, network segmentation, forced patch windows, SBOM visibility — reduce probability but do not eliminate it. Every MSP operating a VSA, ConnectWise Automate, N-able N-central, or similar platform should model "compromise of this server" as a Tier-1 incident and rehearse the response annually. The attackers certainly do.
How Safeguard Helps
Safeguard's TPRM continuously scores your MSP and critical SaaS vendors against disclosed CVEs and patch cadence, flagging when a Kaseya-class vulnerability lands in something you depend on. Reachability analysis on your internal tooling pinpoints which components in your stack have the authenticated-as-customer trust posture that made VSA catastrophic, so you can add compensating controls before incident. Griffin AI maps the transitive dependency of your MSP, their tools, and the downstream effect on your workloads in natural language — the fourth-party view that most victims of Kaseya did not have. SBOM tracking across managed services surfaces the exact VSA build numbers in use, making patch-window enforcement an automated workflow. Policy gates prevent the deployment of MSP integrations that do not meet your minimum hardening bar.