The Beget cloud attack turned an infrastructure intrusion into a long-running data recovery problem. Attackers reached systems controlling the Russian hosting provider’s platform and ran scripts that erased cloud data, forcing engineers to restore services one server at a time.
The initial picture is destructive but incomplete. Beget retained file-level backups for most resources, yet every binary backup of its virtual servers was lost and more than 1,000 servers required manual inspection.
- Beget said attackers accessed infrastructure-management systems and executed scripts designed to wipe data.
- VPS, S3 storage and Kubernetes services suffered complete or partial disruption.
- Some websites returned by Wednesday, but no full-restoration date had been announced.
- Beget reported no evidence that customer information was downloaded or altered.
- Users were advised to replace passwords and access keys.
What Beget reported
According to The Record, the attack occurred overnight on Sunday. Ua.news dated the incident to the night of November 2, 2026. Both accounts describe the destructive intrusion at Beget, one of Russia’s largest hosting and domain-registration providers.
The attack disabled or partially disrupted virtual private servers, S3-compatible cloud storage and Kubernetes clusters. The Record cited local media reports of disruption affecting businesses, public institutions and research organizations. The Naryan-Mar city administration’s website and the Chestny Znak product-labeling system were among the affected services. Ua.news also reported failures involving transportation services, government and private portals, and “Honest Mark” certification monitoring systems.
Beget began returning some servers to service by Wednesday. Dedicated servers managed directly by customers had already been restored, while engineers continued removing malicious files and checking data integrity. Shared-hosting customers faced a longer process because each server needed individual examination.
The company’s scale increased the potential impact. Kommersant figures cited by The Record placed Beget second among registrars of Russian .RU domains, with about 540,700 domains, or 14.7% of the market, under management in October.
Why recovery required manual work
Bringing a server back online and proving that it is safe to operate are different tasks. Beget’s recovery queue shows the distinction: more than 1,000 machines had to be inspected before they could be returned, and the company provided no firm completion date.
That constraint matters because a destructive intrusion can leave problems that a normal restart will not expose. Engineers were checking for malicious files and data-integrity failures rather than merely waiting for power to return. The available file-level backups offered a recovery path, but the loss of all binary backups for virtual servers meant some workloads could not be reconstructed as they existed before the attack.
The trade-off is therefore availability versus confidence. Beget could restore selected services quickly, but doing so without inspecting each server could reintroduce compromised code or unresolved dependencies. The slower process protects customers from a faster but less controlled return.
Why this matters
The published accounts describe a destructive intrusion, not documented ransomware extortion. No ransom demand was reported, and Beget said it had found no evidence that attackers attempted to download or modify customer information. That is reassuring, but it does not make the incident a routine outage.
The immediate losers were Beget customers whose stores, portals, applications and cloud resources became unavailable. They faced uncertain recovery times, incomplete restoration and the possibility that only some data could be recovered. Beget, meanwhile, had to balance pressure to restore service against the risk of returning compromised systems to production.
The credential advice deserves particular attention. If infrastructure-administration systems were exposed, passwords and access keys should be treated as potentially compromised even when there is no evidence of data theft. Rotating a credential is only the first step. Customers also need to determine whether the same password, token or automation path was used in other systems, because replacing it in one location does not address broader reuse.
For security teams, the lesson is not simply to buy more backup capacity. It is to distinguish between backups that preserve files and backups that can rebuild a complete environment. File-level copies may retain content that a destroyed binary backup cannot readily reconstruct, but they may not include every configuration or dependency needed to restore an application.
Customer recovery decision checklist
- Identify the affected dependency.** Record which domains, APIs, storage buckets, applications and credentials rely on the affected Beget resources.
- Rotate exposed credentials.** Replace administrator passwords and access keys associated with the environment, then update downstream services that use those secrets. Confirm that the new values work rather than assuming the change was applied.
- Establish the usable backup.** Ask which recovery layer is available for each VPS or storage resource. If only file-level restoration is possible, verify whether the application’s configuration and required dependencies are included.
- Separate restoration from production.** Keep a recovered copy isolated until integrity checks and functional tests pass, then promote it only when it behaves as expected.
- Watch after service returns.** Monitor for unexpected infrastructure activity, recurring malicious files or unexplained integrity failures rather than treating the end of the visible outage as the end of the incident.
What to watch next
The clearest test of Beget’s recovery will be whether services return without recurring malicious files, unexplained integrity failures or further customer data loss. Another signal will be whether credential rotation prevents secondary misuse.
For customers, the practical position is cautious optimism. File-level backups provide a recovery path, but the missing binary backups and manual inspection queue make a quick, complete return unlikely. Until Beget demonstrates stable restoration and confirms the scope of the intrusion, organizations should validate dependent services and credentials actively rather than waiting passively.
Key takeaways
- Treat restoration as part of incident response, not merely a hosting-provider maintenance task.
- Rotate affected passwords and access keys, then check whether those credentials were reused elsewhere.
- Test file-level restoration paths and verify that critical dependencies are included.
- Track Beget’s integrity checks, malicious-file removal and any evidence of secondary data access.
Frequently asked questions
Was the Beget incident ransomware?
The published accounts describe destructive scripts and data wiping, but they do not report a ransom demand or other extortion activity.
Did attackers steal customer data?
Beget said it found no evidence that attackers attempted to download or modify customer information. It still advised users to change passwords and access keys.
Can Beget customers recover their data?
File-level backups remained for most resources, although all binary backups of virtual servers were lost. Recovery may be partial and requires individual server inspection.
How widely did the outage affect users?
The Record reported disruption across hundreds of websites, while ua.news described outages affecting hundreds of thousands of sites and services. Both included public-sector and commercial users.