# Beget (Russian Cloud and Hosting Provider) Hit by Destructive Data-Wiper Attack via Compromised Management Layer

> In the early hours of 2 November 2026 an unidentified attacker reached the management layer of Russian hosting/cloud/registrar provider Beget and ran data-erasing scripts, destroying VPS, S3 and Kubernetes data, CDN and IP configuration, and all VPS binary (disk-image) backups. Beget reports no evidence of data download or modification; no actor, malware family, or initial access vector has been disclosed.

- **Published:** 2026-11-09T20:36:03Z
- **Last reviewed:** 2026-11-09T20:36:03Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5584
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5584.png
- **ID:** TL-2026-5584
- **Severity:** HIGH
- **Category:** MALWARE
- **Status:** ACTIVE
- **Detections:** 9 (1 shown free below) · **IOCs:** 8

## Description

Beget is one of Russia's largest web-hosting, cloud and domain-registration companies (founded 2007; 200,000+ customers; second-largest .RU registrar with about 540,700 domains / 14.7% share as of October 2026 per Kommersant, cited by The Record). According to Beget's own timeline as reported by Zona Media, the attack began around 02:00 Moscow time on the night of 1-2 November 2026. Attackers launched malicious software at roughly 02:30, Beget detected the breach about ten minutes later (~02:40), and at 02:55 it disconnected all servers from the network to stop the spread.

Beget stated that the attacker obtained access to the management systems covering its entire architecture and executed 'data-zeroing' / data-deletion scripts. No malware family is named by any source, and the initial access method has not been disclosed (Beget cited security concerns and an ongoing investigation). The ATT&CK mapping for this record is therefore limited to behaviors the sources describe (management-plane access, script execution, data destruction, backup loss); Valid Accounts is listed only as the closest category for management-layer access and is not a confirmed vector.

Impact: all data in Beget's cloud infrastructure (VPS, S3 object storage, Kubernetes) was lost, along with CDN settings and IP configuration. VPS binary/disk-image backups were completely lost; VPS file-level backups survived for roughly half of VPS users (Beget estimate, 6 Nov). Shared hosting servers were hit harder and must be restored from backups, though Beget preliminarily assessed almost all shared-hosting sites as recoverable. Name servers, DNS, email, the customer control panel (some 2FA codes failing) and websites went down. Downstream victims reported by local media include the Naryan-Mar city administration site, the Chestny Znak product-labeling system, and the Laboratory of Solar Astronomy of the Russian Academy of Sciences (via registrar problems).

Beget's preliminary review found no attempts to download or modify data on servers holding user data, which it characterizes as a purely destructive attack; this is a vendor statement, not independent assurance. Beget treats all infrastructure as potentially infected: more than 1,000 servers required manual checks for hidden vulnerabilities and malicious scripts, and 'potentially vulnerable points, including those that seemed low-risk' are being reworked. By 9 November, about 60% of shared hosting and 40% of managed dedicated servers were reported restored (BleepingComputer); earlier reports said customer-administered dedicated servers were fully restored. Beget advised customers to rotate passwords, access keys and other credentials possibly stored on affected systems and to verify recovery messages via known support channels because fake recovery messages are possible.

Regulatory fallout: the .RU/.РФ Coordination Center suspended Beget's registrar accreditation (effective 3 Nov, notice dated 6 Nov), restricted new .ru/.рф/.su registrations, and froze domain cancellations/renewal expirations for Beget-registered domains. Beget told customers the incident may qualify as force majeure under Russian law and has notified police and government agencies and engaged cybersecurity firms. No group has claimed responsibility. Context from The Record: the EU sanctioned Beget and a co-owner earlier in 2026 for providing services to Russian-backed authorities in occupied Ukrainian territories and to defense-related entities; this is context only and does not establish attribution.

## MITRE ATT&CK

- T1078 Valid Accounts
- T1059 Command and Scripting Interpreter
- T1651 Cloud Administration Command
- T1485 Data Destruction
- T1561 Disk Wipe
- T1490 Inhibit System Recovery
- T1489 Service Stop

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**Beget Wiper (TL-2026-5584) - Linux Data-Zeroing and Block Device Wipe Commands** (`TL-2026-5584-SPL-001`)

Detects dd, shred, wipefs, blkdiscard, nwipe and mkfs invocations that zero, discard or reformat block devices on Linux hosts. This is the host-level footprint of the data-zeroing scripts the unnamed data wiper ran from the Beget management layer, which erased VPS, S3 and Kubernetes data. No hashes or file names were published, so the rule keys on behaviour rather than artifacts.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1485, T1561, T1059.004
- **Data sources:** sysmon_for_linux, linux_auditd
- **Severity:** critical
- **Confidence:** high

### Splunk SPL

```spl
index=linux sourcetype="sysmon:linux" EventID=1 earliest=-24h
| eval cmd=lower(CommandLine), img=lower(Image)
| eval wipe_dd=if(match(cmd,"(^|/| )dd .*if=/dev/(zero|urandom|random) .*of=/dev/(sd|vd|xvd|nvme|md|mapper|rbd)") OR match(cmd,"(^|/| )dd .*of=/dev/(sd|vd|xvd|nvme|md|mapper|rbd).* if=/dev/(zero|urandom|random)"),1,0)
| eval wipe_tool=if((match(img,"/(wipefs|blkdiscard|nwipe|sfill|srm)$") AND match(cmd,"/dev/")) OR (match(img,"/shred$") AND match(cmd," -[a-z]*z")),1,0)
| eval wipe_mkfs=if(match(img,"/mkfs[.a-z0-9]*$") AND match(cmd,"/dev/"),1,0)
| eval wipe_trunc=if(match(cmd,"find .* -exec (shred|truncate) "),1,0)
| where wipe_dd=1 OR wipe_tool=1 OR wipe_mkfs=1 OR wipe_trunc=1
| stats count min(_time) as first_seen max(_time) as last_seen values(CommandLine) as commands values(User) as users values(ParentImage) as parents by host
| convert ctime(first_seen) ctime(last_seen)
| table host users parents commands count first_seen last_seen
```

### Microsoft KQL

```kql
let lookback = 24h;
DeviceProcessEvents
| where Timestamp > ago(lookback)
| where isnotempty(ProcessCommandLine)
| extend cmd = tolower(ProcessCommandLine), img = tolower(FileName)
| extend wipe_dd = (img == 'dd' and cmd matches regex @'if=/dev/(zero|urandom|random)' and cmd matches regex @'of=/dev/(sd|vd|xvd|nvme|md|mapper|rbd)')
| extend wipe_tool = (img in ('wipefs','blkdiscard','nwipe','sfill','srm') and cmd has '/dev/') or (img == 'shred' and cmd matches regex @' -[a-z]*z')
| extend wipe_mkfs = (img startswith 'mkfs' and cmd has '/dev/')
| extend wipe_trunc = (cmd matches regex @'find .* -exec (shred|truncate) ')
| where wipe_dd or wipe_tool or wipe_mkfs or wipe_trunc
| summarize events = count(), first_seen = min(Timestamp), last_seen = max(Timestamp), commands = make_set(ProcessCommandLine, 20) by DeviceName, AccountName, InitiatingProcessFileName
| order by events desc
```

### Sigma

```yaml
title: Linux Disk or Data Zeroing Commands Consistent with Wiper Activity
id: 7c1e4b52-3a8d-4f6e-9b21-5d0a8e7f1c34
status: experimental
description: Detects dd, shred, wipefs, blkdiscard, nwipe and mkfs invocations that zero or reformat block devices, matching the data-zeroing scripts reported in the Beget wiper incident (TL-2026-5584).
references:
  - https://www.bleepingcomputer.com/news/security/russian-cloud-firm-beget-rebuilds-from-scratch-after-data-wiper-attack/
  - https://therecord.media/russia-cyberattack-beget-cloud
author: Threadlinqs Team
date: 2026-11-09
tags:
  - attack.impact
  - attack.t1485
  - attack.t1561
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_dd_zero:
    Image|endswith: '/dd'
    CommandLine|contains|all:
      - 'if=/dev/zero'
      - 'of=/dev/'
  selection_dd_random:
    Image|endswith: '/dd'
    CommandLine|contains|all:
      - 'if=/dev/urandom'
      - 'of=/dev/'
  selection_tools:
    Image|endswith:
      - '/wipefs'
      - '/blkdiscard'
      - '/nwipe'
      - '/sfill'
    CommandLine|contains: '/dev/'
  selection_shred:
    Image|endswith: '/shred'
    CommandLine|contains:
      - ' -z'
      - '--zero'
      - '/dev/'
  selection_mkfs:
    Image|contains: '/mkfs'
    CommandLine|contains: '/dev/'
  filter_provisioning:
    ParentImage|endswith:
      - '/anaconda'
      - '/cloud-init'
      - '/subiquity'
  condition: 1 of selection_* and not filter_provisioning
falsepositives:
  - OS provisioning, disk decommissioning and secure-erase workflows
  - Storage administrators re-initialising disks during planned maintenance
level: high
```

**Known false positives:**

- Planned disk decommissioning or secure-erase by storage administrators
- OS provisioning and imaging tooling that runs mkfs, wipefs or dd on new block devices

**Tuning notes:** Allowlist provisioning hosts and parent processes (anaconda, cloud-init, MAAS, Ansible decommission jobs). Raise or lower the process coverage by adding other secure-erase tools used in your estate. Alert on any single hit from a management or hypervisor host, and treat a burst across several hosts within minutes as a likely wiper run that calls for network isolation.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- Beget Wiper (TL-2026-5584) - Bulk Cloud Administration Command Execution on Many VMs (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Mass Deletion of Cloud Disks, Snapshots, Backups and Storage (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Burst Stop or Disable of Critical Services on Linux Hosts (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Windows Shadow Copy, Backup Catalog Deletion and Secure-Wipe Utilities (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Kubernetes Mass Deletion of Namespaces, Volumes and Workloads (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Lookalike Beget Recovery and Support Phishing Domains (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Backup, Snapshot and Storage Destruction Commands on Linux (locked: unlock with TL Creds)
- Beget Wiper (TL-2026-5584) - Management-Host SSH Fan-Out Across Many Servers (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [Russian cloud firm Beget rebuilds from scratch after data wiper attack (BleepingComputer)](https://www.bleepingcomputer.com/news/security/russian-cloud-firm-beget-rebuilds-from-scratch-after-data-wiper-attack/)
- [Beget Russia cyberattack on cloud provider (The Record)](https://therecord.media/russia-cyberattack-beget-cloud)
- [Beget Says Attackers Wiped Cloud Data After Management-Layer Breach (GridinSoft)](https://blog.gridinsoft.com/beget-cyberattack-wiped-cloud-vps-backups/)
- [Российский хостинг-провайдер Beget сообщил об уничтожении облачной инфраструктуры после кибератаки (Zona Media)](https://zona.media/news/2026/11/06/beget)
- [Beget official Telegram announcement, 3 November](https://t.me/beget_official/573)
- [Beget official Telegram assessment on VPS backups, 6 November](https://t.me/beget_official/580)
- [Хакеры стерли данные облачных клиентов одного из крупнейших хостингов Рунета Beget (The Moscow Times)](https://ru.themoscowtimes.com/2026/11/03/hakeri-sterli-dannie-oblachnih-klientov-odnogo-iz-krupneishih-hostingov-runeta-beget-a210431)
- [Хакеры уничтожили всю облачную инфраструктуру провайдера Beget (Meduza)](https://meduza.io/news/2026/11/06/hakery-unichtozhili-vsyu-oblachnuyu-infrastrukturu-provaydera-beget)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5584