Skip to navigation

Threat reportMalwareTL-2026-5584

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

highACTIVE

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.

Key facts

IdentifiersTL-2026-5584
Also known asBeget cloud wiper incident
SeverityHIGH
First disclosed
Affected productsBeget Cloud infrastructure (VPS, S3, Kubernetes, CDN, IP configuration); Beget Shared hosting, DNS/name servers, email, customer control panel, domain registrar services
MalwareUnnamed data wiper
MITRE ATT&CK techniquesT1059 Command and Scripting Interpreter, T1078 Valid Accounts, T1485 Data Destruction, T1489 Service Stop, T1490 Inhibit System Recovery, T1561 Disk Wipe, T1651 Cloud Administration Command
MotivationDESTRUCTION
Target sectorstechnology, hosting, telecoms, government administration, retail, education, research
Target regionsrussia
Detection rules9 (1 shown free)
Sources8 cited sources

Detection coverage

As of 2026-11-09, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5584 across Splunk SPL, Microsoft KQL and Sigma, covering 8 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Beget Wiper (TL-2026-5584) - Linux Data-Zeroing and Block Device Wipe Commands

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

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

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

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. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • Beget Wiper (TL-2026-5584) - Bulk Cloud Administration Command Execution on Many VMs · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Mass Deletion of Cloud Disks, Snapshots, Backups and Storage · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Burst Stop or Disable of Critical Services on Linux Hosts · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Windows Shadow Copy, Backup Catalog Deletion and Secure-Wipe Utilities · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Kubernetes Mass Deletion of Namespaces, Volumes and Workloads · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Lookalike Beget Recovery and Support Phishing Domains · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Backup, Snapshot and Storage Destruction Commands on Linux · unlock with TL Creds
  • Beget Wiper (TL-2026-5584) - Management-Host SSH Fan-Out Across Many Servers · unlock with TL Creds

Indicators of compromise

As of 2026-11-09, Threadlinqs Intelligence tracks 8 indicators of compromise for TL-2026-5584.

8 indicators of compromise · unlock with TL Creds. Compare plans

Technical analysis

Beget reports no evidence of data download or modification; no actor, malware family, or initial access vector has been disclosed.

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 techniques by tactic:

Execution

T1059 Command and Scripting Interpreter; T1651 Cloud Administration Command

Initial Access

T1078 Valid Accounts

Impact

T1485 Data Destruction; T1489 Service Stop; T1490 Inhibit System Recovery; T1561 Disk Wipe

Remediation

Immediate actions

  • Rotate passwords, API/access keys, SSH keys and any credentials stored on potentially affected hosting/VPS systems
  • Verify any 'recovery' communications through official support channels; expect phishing using the outage as a lure
  • Restrict and audit access to cloud/hypervisor/orchestration management planes; disconnect management networks from production data planes
  • Inspect restored servers for hidden scripts, web shells and persistence before returning to service

Workarounds

  • Customers: export/replicate data and DNS zones to a second provider; maintain secondary DNS and registrar contingency plans

Longer-term hardening

  • Keep immutable, offline or logically air-gapped backups that cannot be deleted from the management plane
  • Enforce MFA, just-in-time privileged access and strong segmentation for infrastructure management systems
  • Monitor management-plane command execution and mass-deletion/zeroing activity with alerting and automated network isolation
  • Customers should maintain independent off-provider backups of VPS, S3 and Kubernetes data

Affected and fixed versions

  • Beget — Cloud infrastructure (VPS, S3, Kubernetes, CDN, IP configuration)
    Vulnerable versions: Not applicable - management-layer compromise, no software vulnerability disclosed
  • Beget — Shared hosting, DNS/name servers, email, customer control panel, domain registrar services
    Vulnerable versions: Not applicable - management-layer compromise, no software vulnerability disclosed

Timeline

  • Beget first reports a 'major incident' affecting all architecture layers, then confirms a cyberattack and says recovery of name servers and email is underway.
  • At 02:55 MSK Beget disconnects all servers from the network to stop the spread; customers report mass outages of sites, email, VPS, DNS and the control panel.
  • Around 02:30 MSK attackers launch malicious software / data-zeroing scripts; Beget detects the breach about ten minutes later (~02:40).
  • Attack begins around 02:00 Moscow time (night of 1-2 Nov); attackers reach the management layer of Beget's entire infrastructure.
  • The .RU/.РФ Coordination Center suspends Beget's registrar accreditation (effective 3 Nov, notice dated 6 Nov) and later freezes domain expirations for Beget-registered domains.
  • Beget's Telegram announcement states attackers reached the management layer and ran destructive scripts; VPS, S3, Kubernetes data, CDN and IP settings lost; VPS binary backups destroyed; no evidence of data download/modification.
  • Beget begins bringing servers back online; customer-administered dedicated servers restored; more than 1,000 servers flagged for manual inspection for hidden scripts and weaknesses.
  • Beget reports VPS file backups survive for only about half of VPS users, over 60% of shared hosting is back online, and mail infrastructure is largely restored.
  • Beget says shared-hosting restore preparations are complete with automated restores starting overnight; VPS file backups projected within about 24 hours and new VPS creation within about 48 hours.
  • BleepingComputer reports about 60% of shared hosting and 40% of managed dedicated servers restored; Beget notified police and authorities and is working with cybersecurity firms; no attribution made.

Sources cited

Previous and next in malware

Drafted by the Threadlinqs research pipeline from 8 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats