Resilience

In early November 2026, attackers reached the layer that manages the cloud infrastructure of Beget, one of the largest hosting and domain providers in Russia, and ran scripts that erased data. Virtual private servers (VPS), cloud object storage and Kubernetes data were hit hardest, and the attackers also destroyed the disk-image backups that would normally undo that kind of damage. More than a week later the company is still rebuilding, with about 60 percent of shared hosting and about 40 percent of its managed dedicated servers back online.

Beget says its investigation found no sign that anyone tried to download or change customer data, so this reads as an attack built to destroy rather than to steal. That is cold comfort, because the thing that makes a wipe survivable is a clean backup the attacker cannot touch, and here the same access that erased the production data also erased the point-in-time VPS backups sitting in the same platform. A management-plane wipe that takes the backups with it is the case every recovery plan is supposed to prevent, which is exactly why it is worth reading even if you have never heard of Beget.

How it happened

Beget's own account is that the attackers got into the systems used to manage its infrastructure, not a single customer server, and from there ran wiping scripts across the cloud platform. Reaching the management plane is what turned a breach into a mass-destruction event: that layer can address every tenant at once, so one foothold erased data belonging to many customers rather than one.

The damage was worst in the cloud services. BleepingComputer, Gridinsoft and The Record all report that data tied to VPS, cloud storage of the S3 object-store kind, and Kubernetes was wiped, along with content delivery network (CDN) settings and internet protocol (IP) configuration. The company said it detected the activity shortly after the malware ran and disconnected all servers from the network to stop it spreading, which is why some data survived at all.

The part that turned a bad day into a long one is the backups. Beget confirmed that its binary VPS disk-image backups, the full point-in-time images you would restore a server from, were destroyed in the same sweep that took the live data. They lived inside the platform the attackers controlled, so the attackers deleted them as easily as everything else.

What saved the bulk of the hosting was a different backup that sat elsewhere. File-level backups, meaning copies of the actual website files rather than whole-disk images, were preserved for most shared hosting, which is why Beget expects to recover nearly all shared-hosting sites. For VPS the picture is thinner: a November 6 assessment put file backups at roughly half of VPS users, and the company said it is not possible to recover all VPS data.

Some details still conflict between outlets, and it is worth being honest about which. The start date is reported as November 1 by TechRadar, while Gridinsoft and the Russian outlet Zona refer to a November 2 outage. The exact extent of backup loss also varies by source and by service, from "all binary VPS backups gone" to "file backups for about half of VPS users." Treat the shape of the event as confirmed and the precise figures as still moving.

The recovery so far

The numbers below come with their sources because they do not all agree. The most quoted figures, carried by BleepingComputer in its November 9 rebuild report, are that more than a week after the attack about 60 percent of shared hosting and about 40 percent of the dedicated servers Beget manages had been restored, with work continuing. The same report notes that roughly 1,000 servers had to be checked by hand for hidden scripts and tampering before they could be brought back, which is why recovery is measured in weeks rather than hours.

Mail is further along by one account. Gridinsoft's summary of Beget's updates says about 80 percent of the company's mail infrastructure was back, a figure we found in only that one source, so treat it as single-sourced rather than settled.

Beget told customers to change their passwords, access keys and any other credentials that may have been stored on the affected systems, and to revoke old values and update the applications that use them. It also warned that the incident could count as a force majeure event under Russian law, a legal way of saying it may not be able to meet some service commitments while it rebuilds. Attribution has not been publicly confirmed; Beget is under European Union sanctions imposed earlier in 2026, and the attack lands amid a run of incidents against Russian digital infrastructure, but no group's claim has been verified, so we are not going to guess at one.

What to do

The useful part of this story is not about Beget. It is that a single set of credentials reaching both your production data and your backups is a single point of failure, and a wiper turns that into total loss. Here is how to break it, in the order that matters.

Keep at least one backup copy somewhere the production control plane cannot reach. That means offline, or in a separate cloud account or a different provider, with its own credentials. A backup that lives inside the same platform as the thing it protects, reachable from the same console, is the backup Beget lost.

Make those copies immutable or write-once. Object-lock and write-once-read-many (WORM) storage let a backup be read but not deleted or overwritten for a set retention period, so an attacker holding your console cannot wipe the history. This is the control that most directly answers a management-plane takeover.

Protect the management and console plane with phishing-resistant multi-factor authentication (MFA), the kind based on hardware security keys or passkeys rather than codes that can be phished or pushed. Keep the number of accounts that can reach that plane small, and review it. The blast radius here came from management-layer access, so that layer earns the strongest login you have.

Test your restores on a schedule. A backup you have never rebuilt from only looks like protection, and the time to find out the images are incomplete is not during an incident. Rehearse a full restore from the isolated copy, time it, and fix what breaks.

If you are a customer of any provider hit this way, do two things now. Rotate the passwords and access keys you had stored there, through the provider's trusted account pages, and revoke the old ones. Then check your own data integrity rather than assuming "no evidence of theft" means your records are intact, because that finding was preliminary even in Beget's case.

Designing a cloud or Kubernetes platform so that no single credential can both run production and delete its backups is work we do under platform and cloud engineering and cloud and Kubernetes security, and hardening the management plane itself falls under safeguarding and hardening. If you want a second pair of eyes on where your backups actually live and who can reach them, open the chat and Yaali, our AI agent, will pass the question to the engineer who would do the work.

---

Sources: BleepingComputer, Gridinsoft, The Record, TechRadar, OODA Loop.