The Kaseya VSA ransomware attack of July 2021 shows why Indian SMBs must audit their managed service provider's remote access, not just their own network: attackers exploited a zero-day in Kaseya's on-premises VSA remote monitoring and management (RMM) software, pushed a malicious "update" through the trusted agent already installed on MSP customer machines, and used that trusted process to bypass endpoint protection and mass-encrypt roughly 1,500 downstream businesses across dozens of MSPs. The core lesson is not about Kaseya specifically — it is that any RMM agent, backup console, or remote-access tool your IT vendor runs inside your network is a privileged, trusted channel that can be weaponised the moment it is compromised upstream. If you outsource IT to an MSP, you inherit their security posture whether you audited it or not.
What actually happened in the Kaseya VSA ransomware attack
Kaseya VSA is remote monitoring and management software that MSPs install on their own servers and then use to push software updates, patches, and scripts to hundreds or thousands of endpoints across their client base, all at once, with high privilege. That "push to everyone automatically" design is exactly what makes RMM tools efficient for MSPs — and exactly what makes them catastrophic when abused.
On 2 July 2021, the REvil (Sodinokibi) ransomware group exploited a set of vulnerabilities in on-premises Kaseya VSA servers to bypass authentication and push a fraudulent software update to VSA agents. Because those agents run with elevated, trusted privileges on client machines specifically so they can install software without triggering alerts, the payload — ultimately a REvil ransomware binary delivered via a trusted Kaseya process — was not flagged by traditional signature-based endpoint protection on many of the affected machines. Kaseya, CISA, and the FBI later confirmed the attack chain publicly and coordinated disclosure and remediation guidance.
The timing was deliberate: the attack landed on a Friday afternoon before the US July 4th long weekend, when MSP and client security teams were thinnest.
Why "trusted agent" software is a distinct risk class
Endpoint detection tools are built to trust processes signed by known vendors and running with administrator-level service accounts, because RMM agents, backup clients, and patch-management tools need exactly that level of access to do their job. That is not a flaw in any single product — it is the tradeoff every organisation makes when it delegates IT operations to a third party.
The Kaseya incident demonstrated three properties of this risk class that are still true for any RMM, remote-access, or backup tool in 2026:
- Blast radius is multiplicative, not additive. One vulnerable server can reach every downstream client simultaneously, because that is the tool's intended function.
- The malicious payload arrives through a trusted channel. Endpoint protection that allow-lists known vendor processes will often not flag activity coming from that same trusted binary, which is precisely why attackers target it.
- The client organisation has no visibility into the vendor's own patch cadence. Kaseya had reportedly been informed of some of the underlying vulnerabilities before the attack and was working on a fix — a detail that is publicly documented in post-incident reporting — but the end customers of the affected MSPs had no way to know that, and no lever to pull except trusting their MSP.
REvil also broke from the usual ransomware playbook of negotiating with each victim separately: it publicly demanded a single lump-sum ransom, widely reported at around $70 million in Bitcoin, in exchange for one "universal decryptor" that would unlock every affected system at once. Kaseya has stated it did not pay any ransom. A universal decryptor was later made available to affected organisations after REvil's own infrastructure went offline in mid-July 2021 — reporting at the time attributed this to law-enforcement action rather than a negotiated payment, though the full details were never made fully public. The practical lesson for an SMB is unrelated to how the decryption key surfaced: recovery took days to weeks for many victims regardless, which is the real cost of this risk class even when a decryptor eventually exists.
The attack chain, step by step
Notice that steps D and E — the client endpoint receiving the update and endpoint protection trusting the signed process — are not attacker-controlled in themselves. They are normal, correctly-functioning parts of the MSP relationship. That is what made this attack so effective: the client's own systems did exactly what they were configured to do.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanWhat Indian SMBs outsourcing IT should actually demand
Most Indian SMBs do not run their own RMM infrastructure — they rely entirely on an MSP or a "AMC" (annual maintenance contract) IT vendor who remotely manages servers, endpoints, and sometimes backups. That relationship typically comes with several standing privileged access paths into your environment, most of which the average SMB owner has never inventoried.
Figures above are illustrative of typical MSP access categories, not a measured statistic from a named study — used to show the shape of the exposure, not a precise count.
An MSP due-diligence checklist
| What to ask your MSP | Why it matters | Red flag answer |
|---|---|---|
| Which RMM/remote-access tools do you use, and are they cloud-hosted or on-premises? | On-premises RMM servers are a single high-value target; cloud-hosted vendor infrastructure shifts patching to the vendor but concentrates trust | "We manage our own server and haven't upgraded it in years" |
| What is your patch SLA for critical vendor advisories? | Kaseya's own advisory window was days, not weeks — a slow MSP patch cycle extends your exposure | "We patch when we get to it" |
| Do you use a separate, unique admin credential per client, or one shared account across clients? | A single compromised MSP credential should not unlock every client at once | "Same login for everyone, it's easier" |
| Can you show us MFA enforcement on your own remote-access tooling? | The MSP's own admin console is now part of your attack surface | "MFA slows us down" |
| Do you have a documented incident-response plan that includes notifying clients within a defined window? | Coop and other Kaseya victims learned about the compromise through Kaseya's public statements, not always proactively from their own MSP | No written IR plan exists |
| Is your access into our environment logged and auditable by us, independently? | Without independent logs, you cannot verify what the MSP account did in your systems | "Trust us, we don't log client-side" |
Building this into your own risk posture
None of this means Indian SMBs should abandon MSP relationships — for most small teams, a competent MSP is still far better than no managed security at all. It means the relationship needs the same scrutiny you would apply to any vendor with standing privileged access to your systems, which is functionally what an MSP is.
Frameworks like NIST's guidance on supply-chain risk management (NIST SP 800-161) and CERT-In's advisories on third-party and vendor risk are useful references when drafting the questions above into a formal vendor-risk policy; see cert-in.org.in and nist.gov for current guidance. Dhisattva AI Pvt Ltd builds continuous vulnerability visibility specifically so that Indian businesses are not relying on a single vendor's word for their own exposure.
For more on evaluating third-party and vendor risk, see the Bachao.AI blog.