Cybersecurity / Source date:

Kaseya Attack: One Vendor, Hundreds of Victims

Compromising a management platform gave attackers simultaneous access to many downstream businesses.

Illustrative IT staff checking a recovery runbook and equipment case during an independent recovery rehearsal.

On Friday afternoon, hours before a long public holiday weekend in the United States, attackers used a previously unknown flaw in a widely deployed IT management product to push what looked like a routine update to the systems it administered. It was ransomware. The vendor shut down its hosted service within hours and told every customer running the software on their own servers to take those servers offline immediately. Four days later the shape of it is clear enough. Somewhere around fifty to sixty managed service providers were compromised directly. Through them, estimates of downstream victims run from several hundred to well over a thousand small and mid-sized businesses — dental practices, accountancy firms, schools, local government, a Swedish supermarket chain that closed hundreds of stores because its checkout supplier was in the chain. Yesterday the group behind it posted a single demand of seventy million dollars for a universal decryption tool covering every victim at once. This is being filed as another software supply chain attack. It is something more specific and, for most businesses reading it, more personal: the compromise of outsourced administrative privilege.

What a remote management tool actually is

A remote monitoring and management platform is the instrument through which a managed service provider runs your estate. Its agent sits on every server and workstation, it runs with the highest level of system privilege, it can execute arbitrary scripts and deploy arbitrary software without a user present, and — this is the part that matters — vendor installation guidance routinely instructs administrators to exclude it from endpoint protection so that its own activity is not blocked. Read that back as an attacker would. There is a console that can run any code, as the highest-privileged account, on every machine in hundreds of unrelated companies, and the security software on those machines has been told in advance to ignore it. That is not a flaw in one product. It is the design of the entire category, and the category is how the small and mid-market gets managed. When a business outsources IT operations, it is not outsourcing tickets. It is delegating standing administrative control, and the tool that carries that control is now the single most valuable target in the market, because compromising one console converts into hundreds of simultaneous extortion events. The timing tells you the same story. Friday evening before a three-day weekend was chosen because it maximises the gap between encryption and the first person with authority noticing.

The questions to put to your provider this week

Six, and they are answerable today: Which remote management, monitoring and backup tools do you use to reach our environment, and which are internet-facing? Is multi-factor authentication enforced on your administrative consoles, including for your own engineers? Is your access to us brokered through our identity system, or do you hold permanent local accounts? Can we disable your access ourselves, within fifteen minutes, without your assistance? Who administers our backups, and with which credentials? And how many other clients does the same console reach? The last question is the uncomfortable one, because it measures the blast radius you are inside rather than the one you control. A provider that answers it honestly is worth keeping. One further observation: if your provider has not contacted you since Friday about this incident, that silence is itself an answer about their monitoring and their communications, whether or not they run the affected product.

Test two separate pathsArticle-derived assessment questions, not a control certification or a claim about any Kaseya victim. Rehearsals and revocation must be authorised and safe.
PathQuestion to verify
Provider administrationWhich named identities and tools reach production, and who can revoke them?
Recovery accessCan an authorised internal owner authenticate if the provider is unavailable?
Recovery protectionCan compromised production credentials alter recovery copies or retention settings?
RestorationHas a separate team restored the critical process and checked the result?

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

The one rule that decides how this ends

Across the victims this week, the difference between a bad week and an existential event comes down to a single architectural question: is the recovery path administrable by the same party, and the same credentials, that administer production? In a typical managed arrangement, it is. The provider configures the backups, holds the backup console credentials, and manages the storage. When the provider's privileged access is used to encrypt production, the same access reaches the backups — and the organisation discovers that it never had a recovery capability, only a backup product. So the rule to adopt is blunt: your recovery must survive the compromise of your administrator. Practically, that means immutable or offline copies that cannot be deleted or altered with production credentials, a retention lock the provider cannot change unilaterally, at least one restoration test a year performed by someone other than the provider, and the ability for your own staff to authenticate to the backup system independently. This is a small amount of work and it is the difference between restoring on Wednesday and negotiating with criminals.

Practical Guidance for MSP Risk Assessment

  • Inventory every tool your provider uses to reach you, with its privilege level and whether it is reachable from the internet.
  • Broker provider access through your own identity system, with multi-factor authentication, named accounts and time-limited elevation instead of standing administrative rights.
  • Keep a break-glass account you control and test that you can revoke all provider access without provider cooperation.
  • Separate recovery from administration. Immutable or offline backups the provider cannot delete, with independent credentials and an annual restore test you witness.
  • Ask for the provider's own security posture in writing, specifically console multi-factor authentication, patch currency of their management tooling, and their client-to-console segregation.
  • Agree an out-of-hours contact and escalation path with a human name, and test it on a Friday evening rather than a Tuesday morning.
  • Understand your concentration exposure — how many of your critical suppliers and peers use the same provider or the same platform.
  • Write incident obligations into the contract at renewal, including notification on discovery and cooperation with your forensics, not just theirs.

The Regional Angle

Three features of how IT services are bought in this region change the risk materially. The first is the annual maintenance contract, which is the dominant commercial model here and which quietly determines what your provider is able to do. An AMC is typically priced per device or per user, with a fixed allocation of engineer hours, an agreed response time, and a scope defined around availability: keep the systems running, patch when convenient, replace what fails. Security hardening, privileged access redesign, backup immutability, log retention and out-of-hours incident response are outside that scope, which means the provider is not being paid to do them and, under a fixed-fee contract, is commercially penalised for doing them anyway. When clients complain that their provider is reactive, they are usually describing the contract they signed. The fix is not a new provider; it is a scoped, separately priced security line in the AMC with named deliverables — console multi-factor authentication, segregated tenant access, immutable backups, quarterly restore tests, patch SLAs by severity — so that the work has a budget line and an accountable owner. The second is sector concentration, which is more acute here than the global commentary suggests. In any given emirate or city, a small number of specialist providers serve most of the clinics, most of the schools, most of the pharmacies, most of the exchange houses — frequently bundling the sector-specific application, the hosting, the support and the backups into one relationship. A single provider compromise therefore does not produce scattered victims; it produces a sector-wide outage in one market, simultaneously, among organisations that assume they are independent of each other. Outside banking and a few regulated sectors, there is no coordinated mechanism to manage that: no sector-wide notification channel, no pooled incident response capability, no requirement for the provider to tell anybody other than the client. Boards in these sectors should be asking not only who supports us, but who else does the same firm support, and what happens to our sector on the day it fails. The third is recovery logistics, which are slower here than the plans assume. Rebuilding a compromised estate from clean media requires hardware, licence keys, vendor authorisations and physical presence — and in this market the equipment may need to be imported, the vendor relationship and licence entitlements are usually held by the provider rather than the client, and the specialist engineer is the person you are currently unable to trust. Add the working week: an attack landing on a Thursday evening in the Gulf hits the longest local coverage gap of the week while much of the region's international vendor support is already into its own weekend. Those are hours you can buy back in advance by holding your own licence records, keeping a documented rebuild procedure outside the affected systems, and pre-agreeing an incident response firm that can actually deploy locally.

The objection worth taking seriously

The strongest objection is that the victims did nothing wrong. They bought a mainstream product from a substantial vendor, ran it as the documentation instructed, and were compromised through a flaw nobody outside a small research group knew existed — in software that a responsible disclosure process was already working to fix. No client-side assessment would have prevented this. Telling a hundred-person accountancy firm to interrogate its provider's build security is asking it to do work it cannot perform against a risk it cannot price. And the alternative most commonly proposed — bring IT back in-house — is both unaffordable and almost certainly worse, since a two-person internal team will not match a competent provider on patching, monitoring or availability. All of that is correct. Prevention was not available here, and the reflex to blame the smallest victims in the chain should be resisted. But the case for assessment was never prevention. It is blast radius and recovery. This week, businesses whose backups sat outside their provider's administrative control are restoring systems; businesses whose backups sat inside the same console are choosing between a ransom and a rebuild. Both groups were equally unable to stop the attack. Only one group made a design decision beforehand that survived it. That decision — along with brokered rather than standing access, and the ability to cut a provider's connection without asking the provider — costs very little and is entirely within reach of a small business. Outsourcing operations is sensible. Outsourcing the recovery path to the same party that holds the keys to production is the part to stop doing.

Common Questions

Should we stop using a managed service provider?

No. Change the architecture of the relationship rather than the relationship: brokered access, limited standing privilege, independent recovery, and contractual incident obligations. A good provider will welcome all four, because it reduces their liability as well as yours.

Our provider says they were not affected. Is that enough?

Ask for specifics: which management products they run, their versions, whether those consoles are internet-facing, whether multi-factor authentication is enforced, and what they checked. "We are fine" is a feeling, not an assessment.

Does cyber insurance cover this?

Often, but the cover that responds when your supplier is attacked is exactly the cover being narrowed and sub-limited at renewal this year. Read the dependent business interruption wording before you rely on it.

What should we expect over the next twelve months?

Expect a patch within days and then a long tail of unpatched on-premise servers that stay exposed for months, because the organisations running them are the least likely to be reading advisories. Expect intense law enforcement and diplomatic pressure on the group responsible, and a reasonable chance it disappears, rebrands or releases a decryption tool to reduce the heat. Expect insurers to add managed provider concentration questions to renewals and to start sub-limiting it. Expect government agencies to publish specific guidance for the managed services sector, followed within a year or two by real requirements for providers serving regulated clients. And expect client contracts to change at the next renewal cycle — multi-factor authentication on consoles, segregated client access, notification on discovery — because a thousand boards have just learned what standing administrative privilege means.


MSP Risk Assessment — we map the privilege your providers hold, test whether you can revoke it without their help, and separate your recovery path from the administrators who could be compromised.

Continue reading

Talk to OPS

Start with the operating problem.