Destructive Attack Wipes Russian Host Beget's Cloud: Deletion Scripts Run From the Management Plane Erased VPS, S3, Kubernetes and Every Binary VM Backup

High · 2026-11-10 · By H.A

Attackers who reached Beget's infrastructure management systems ran overnight deletion scripts that destroyed VPS, S3 and Kubernetes data along with all binary backups, leaving file-level backups as the only way back.

Overview

Beget, one of Russia's largest hosting providers and domain registrars, has been hit by a destructive cyberattack that wiped its cloud platform. In one night, attackers erased data for VPS instances, S3-compatible object storage and Kubernetes clusters, wiped network and IP configuration, and destroyed all binary backups of virtual servers. More than a week later the company is still rebuilding. No group has claimed the attack, and Beget has not said how the attackers got in.

The incident is a clear example of a wiper attack against a cloud provider's control plane. The attackers did not encrypt individual customer servers. They used the provider's own management systems to delete everything at once.

The Campaign

Beget says the attackers reached the systems used to manage its infrastructure and ran deletion scripts overnight from Sunday 1 November into Monday 2 November 2026. The damage, according to the company:

• VPS disks, S3 storage and Kubernetes environments: data destroyed
• Network configurations and IP settings: wiped
• Binary (block-level) backups of virtual servers: also destroyed
• File-level backups: survived for most shared and virtual hosting resources and are the basis of the recovery
• Customer-managed dedicated servers: already restored

Beget says it found no evidence that customer data was downloaded or modified. Even so, it has told customers to change passwords, access keys and other credentials that may have been stored on affected systems. It has also warned that the attack may count as force majeure under Russian law, which could temporarily excuse some of its contractual obligations.

The provider is significant. Founded in 2007, Beget is the second-largest registrar for .RU, with about 540,700 domains (roughly 14.7% of the zone) as of October, according to Russian business press. Small and medium businesses were hit hardest. Disrupted services reportedly include a regional city administration website, Russia's Chestny Znak product-labelling system and a solar-astronomy laboratory of the Russian Academy of Sciences.

Timeline

• July 2026: The EU sanctions Beget and a co-owner for knowingly providing hosting and domain services to Russian-installed authorities in occupied Ukrainian regions and to defence-related entities.
• 1–2 November 2026 (overnight): Attackers run deletion scripts across the cloud platform.
• 4 November 2026: Beget reports the first shared-hosting sites back online and says more than 1,000 servers need manual inspection.
• Early to mid November: Restoration continues. Engineers remove malicious files and check data integrity, and the cloud platform is being rebuilt.

Tradecraft

Beget has not described the intrusion vector, so the following is assessment rather than confirmed fact.

• Control-plane access. Deleting VPS, storage, Kubernetes and network configuration at the same time takes privileged access to orchestration and management tooling, not just individual hosts.
• Backups targeted together with production. Destroying block-level backups at the same time shows the attackers knew the environment and wanted to make recovery impossible, not to extort payment. No ransom demand has been reported.
• Timing. An overnight run on a weekend gave the attackers the longest window before responders could react.

The attack fits a pattern of disruptive operations against Russian IT and hosting providers during the war. In October, attackers exploited a flaw at hosting provider FirstVDS to steal customer data. Attribution to any specific group or state is not established. Beget's sanctions status makes politically motivated attackers plausible, but that is speculation without evidence.

Indicators of Compromise

No IOCs have been published.

Detection

These lessons apply to any provider or enterprise running private cloud:

• Alert on bulk delete operations in hypervisor, object-storage and Kubernetes APIs, such as mass DeleteVolume, bucket deletions or namespace and PV deletions, especially outside change windows.
• Monitor management-plane logins for new sources, unusual hours and service accounts used interactively.
• Treat any change to backup retention, deletion of backup sets or immutability settings as a high-severity alert.
• Baseline which hosts are allowed to run orchestration scripts, and alert on new scripts in management repositories or on jump hosts.

Recommended Actions

For organisations hosting with any single provider:

1. Keep independent, off-provider backups of critical data and configuration, and test restoring them.
2. Spread DNS and registrar risk. Keep a secondary DNS provider and current zone exports.
3. Change credentials that were stored on any affected platform: API keys, database passwords and SSH keys.

For infrastructure operators:

1. Make backups immutable (object lock or WORM) and logically separate them from the production control plane, with different credentials, administrators and network paths.
2. Require multi-person approval for destructive bulk operations on management APIs.
3. Put management-plane admin access behind phishing-resistant MFA and privileged access workstations, and record those sessions.
4. Rehearse a "total control-plane loss" scenario, not just single-host failure.

Analyst Assessment

The Beget attack shows that the fastest way to destroy thousands of customers' data is to compromise the provider's management layer, where a few scripts can do what would otherwise take thousands of individual intrusions. Recovery is possible only because file-level backups were stored somewhere the attackers could not reach. Whoever is responsible, the lesson for every hosting provider is the same: backups that the production admin plane can delete are not backups. Customers should not assume their provider's backups will survive a determined attacker.