One update pushed to 1,500 businesses. None of them asked for it.
Software updates are supposed to be the boring, trustworthy part of running a business. You patch, you move on. (It’s the IT equivalent of eating your vegetables: nobody expects the salad to attack back.) On July 2, 2021, that assumption broke for roughly 1,500 businesses at once, through a single trusted software vendor they all happened to share.
What actually happened
Kaseya sold VSA, remote-monitoring software that IT-management companies use to push updates and patches to their own clients’ networks. Prosecutors say Yaroslav Vasinskyi, working with the REvil (also known as Sodinokibi) ransomware operation, exploited an authentication-bypass zero-day in Kaseya’s own VSA server software (tracked as CVE-2021-30116, one of several flaws Dutch researchers had already reported to Kaseya before the attack) to push a malicious update through that same trusted channel (the software supply-chain version of the pizza delivery guy turning out to be casing the house). Because managed-service providers used Kaseya VSA specifically to distribute software to their downstream clients, one compromised update didn’t just hit Kaseya, it cascaded through every business that trusted a Kaseya-connected provider, encrypting systems at an estimated 1,500 companies worldwide.
REvil publicly demanded $70 million in bitcoin for a single universal decryptor that would unlock every victim’s files (a “volume discount,” basically, for an extortion operation apparently organized enough to bundle SKUs). Vasinskyi was arrested at the Poland-Ukraine border in October 2021 and extradited to the United States in March 2022. He pleaded guilty and, in May 2024, was sentenced in the Northern District of Texas to 13 years and seven months in prison and ordered to pay more than $16 million in restitution.
The artifact: not the ransom note, the deployment chain itself
The ransom demand and the victim count are what made this a global story. What a court actually has to establish, though, is narrower and more technical: the specific chain connecting a named defendant to the code that ran on victim machines.
That chain has several distinct, separately provable links. First, the vulnerability in Kaseya’s own server software, and evidence of who found and exploited it. Second, the malicious payload itself, code that had to be built, packaged to look like a legitimate VSA update, and pushed through Kaseya’s real distribution mechanism. Third, the ransom infrastructure, the negotiation portal (yes, a portal; modern ransomware ships with a friendlier UX than most banking apps), and the specific bitcoin wallets tied to the ransom demands. And finally, whatever ties a specific human being to that infrastructure, rather than to the ransomware operation in the abstract. Each link is a different kind of technical evidence, and none of them is interchangeable with another. Showing that REvil’s malware ran on a victim’s machine doesn’t, by itself, show which specific operator deployed it against which specific target.
What a software expert witness actually tests in a supply-chain ransomware case
This is exactly where a software expert witness does work a summary of the attack can’t: it doesn’t stop at “REvil ransomware, deployed via Kaseya.” It tests each link in that chain separately, and states plainly which ones the evidence actually supports for a specific defendant.
That means examining the malicious update itself: what it did, how closely it matches known REvil tooling, and whether its build artifacts or infrastructure connect to other confirmed REvil activity. It means tracing the ransom-payment infrastructure independently of the malware, since a negotiation portal and a wallet address are a different evidentiary thread than the code itself. Finally, it means being explicit about the difference between “this person operated within the REvil affiliate structure” and “this person personally built or deployed this specific payload,” since a ransomware operation of this scale typically involves multiple people with different roles.
None of that is exotic. It’s the same discipline every technical case needs: separate the layers, state what each one actually proves, and don’t let the size of the damage substitute for evidence connecting a specific person to a specific technical act.
Why this matters beyond one ransomware gang
Kaseya wasn’t careless in any ordinary sense; it was trusted, and trust is exactly the property an attacker needs from a distribution channel. (Somewhere, a “zero trust” vendor is updating their sales deck as we speak.) Any company that pushes software updates to other companies’ systems is, structurally, a single point of failure for everyone downstream of it, no matter how good its own security otherwise is.
For Israeli companies that build or rely on managed-service and update-distribution software, and the litigators who end up representing them after an incident, the lesson isn’t really about REvil. A supply-chain compromise produces several distinct categories of technical evidence: the vulnerability, the payload, the ransom infrastructure, and the human attribution. A case built on any one of them without the others is incomplete.
The above is general information and not legal advice. Case facts are drawn from U.S. DOJ court records and contemporaneous reporting.