Kaseya VSA: When the Tool That Manages Everything Gets Hit

On Friday afternoon, US time, just as the long Fourth of July weekend was starting, attackers used Kaseya VSA to push ransomware to businesses on several continents. VSA is remote monitoring and management software: the tool that managed service providers (MSPs) use to patch, configure and run scripts on their clients' computers. In other words, software whose entire job is to execute things on every machine it manages.

Four days in, the situation is still moving and the details are incomplete, so treat what follows as a snapshot rather than the final story.

What we know so far

• The attack targeted on-premises VSA servers. These are servers that MSPs run themselves. Attackers compromised them and used VSA's own mechanisms to distribute ransomware to managed endpoints, which means to the MSPs' customers.
• Kaseya told customers to shut their VSA servers down immediately on Friday and keep them off until further notice. It also took its own hosted (SaaS) version offline as a precaution. As of today, a patch for on-premises servers hasn't been released; Kaseya has said the SaaS service will come back first, followed by an update for on-premises customers.
• The ransomware has been attributed to the REvil group, which has posted a demand for a large sum in return for a universal decryptor.
• The scale is still being counted. Kaseya's latest statements put the number of directly affected customers, mostly MSPs, at fewer than 60, and the total number of downstream businesses at fewer than 1,500. Those numbers have been revised as information has come in and may change again.
• Some of the effects have been very visible. In Sweden, the Coop supermarket chain closed most of its stores over the weekend because its checkout systems stopped working, reportedly because a supplier of those systems was affected.
• It was reportedly a zero-day. The Dutch Institute for Vulnerability Disclosure (DIVD) has said its researchers had already reported vulnerabilities in VSA to Kaseya and were working with the company on fixes when the attack happened. Whether the attackers used exactly those flaws hasn't been confirmed publicly.

The management plane is the crown jewels

Six months ago we wrote about SolarWinds Orion, where attackers compromised a monitoring vendor's build pipeline. Kaseya looks different in mechanism (so far there's no suggestion that Kaseya's own build process was touched) but it's the same shape of problem: a tool designed to reach everything was used to reach everything.

Remote management platforms are among the most powerful pieces of software a small organisation can run. They typically have:

• Administrative rights on every managed machine.
• The ability to run arbitrary scripts at scale, on a schedule or immediately.
• Trusted status with endpoint security tools, because they're constantly making changes that would otherwise look suspicious.
• An admin interface that is, in many deployments, reachable from the internet so technicians can work from anywhere.

That last point is the one most within everybody's control. An internet-facing login page for a system that can run code on hundreds of machines is an extremely valuable target, and it will be attacked constantly whether or not a zero-day exists.

If you're an agency or MSP

This isn't only about VSA. Plenty of web agencies hold similar power over their clients in quieter ways: a WordPress management dashboard with admin access to dozens of sites, a deployment server with SSH keys to every client's host, a password manager with every client's hosting login, a shared SFTP account. Each of those is a management plane. Questions worth asking this week:

• Is the admin interface reachable from the whole internet? If it can be restricted by IP address, put behind a VPN, or protected by a separate authentication layer in front of the application's own login, do it.
• Is MFA enforced for every account? Including the old shared "admin" account nobody uses any more. Especially that one.
• What happens if it's compromised? If one tool can push changes to every client at once, the answer is "every client is affected at once". Consider separating the highest-value clients, or at least limiting what automated scripts can do without a second person's approval.
• Are client backups out of reach of the same tool? Ransomware delivered through a management platform can also reach the backups that platform manages. At least one copy should be under separate credentials that the management tool doesn't hold.
• How quickly can you tell every client what's happening? On Friday, MSPs had to contact hundreds of customers over a holiday weekend. Have an up-to-date contact list and a template ready before you need it.

Holiday weekends are a known risk

This attack started on the Friday before a US public holiday, and that's unlikely to be a coincidence. Attackers know that staffing is thin, that response will be slow, and that a problem found on Saturday may not be acted on until Tuesday. Several large ransomware incidents have followed the same pattern.

Practical steps before the next long weekend:

1. Make sure alerts reach a person. Check that on-call is actually staffed, and that alerts go to a phone rather than to an inbox nobody reads until Monday.
2. Patch before, not after. Schedule critical updates in the week before a holiday so there's time to deal with anything that breaks.
3. Know how to switch things off. Kaseya's first instruction was "shut down your VSA server". Could you do the equivalent for your own management tools quickly, and do you know what stops working when you do?
4. Watch for many things changing at once. One site's homepage changing is a deploy. Thirty sites changing in the same ten minutes on a Saturday night is an incident. External checks on content and response codes across a fleet of sites will surface that pattern much faster than waiting for clients to email.

The lesson we keep relearning

WannaCry in 2017 was about patches that existed but weren't applied. SolarWinds last December was about trusting what a vendor ships. Kaseya is about the power concentrated in management tools and how exposed we leave them. The common thread is that the systems we use to run everything else deserve the strictest controls we have, not the most convenient ones.

We'll learn much more about this incident in the coming weeks, including how the attackers got in and whether any of it could have been spotted earlier. In the meantime, the useful work is local: find your own management plane, reduce who and what can reach it, and make sure you'd know within minutes, not days, if something started changing across all your clients at once. CompleteStatus watches sites from the outside; whatever you use, make sure something is watching the whole fleet, not just the site you happen to be looking at.