At 05:05 AM UTC on February 24, 2022, Russian armored columns began crossing into Ukraine. Within the same hour, tens of thousands of satellite internet modems across Ukraine and Europe went dark — permanently. They did not lose their connection. They were destroyed. An attacker had pushed a wiper to the modems’ firmware, overwriting flash memory and leaving devices that could not boot, could not be remotely recovered, and could not be fixed with a software update. Physical replacement was the only option.

The Viasat KA-SAT attack was not just a denial-of-service event. It was a demonstration that satellite communications infrastructure — assumed by many organizations to be a resilient out-of-band backup — is itself a target. It disrupted Ukrainian military communications. It took offline 5,800 wind turbines in Germany. It severed internet for tens of thousands of users across France, Germany, Hungary, Greece, Italy, and Poland.

This post is a technical breakdown of how the attack worked, what AcidRain does at the system call level, how to detect and hunt for similar threats, and what SATCOM operators and enterprises using satellite connectivity need to do to harden their infrastructure.

Timeline and Attribution

DateEvent
Pre-Feb 24, 2022Sandworm (GRU Unit 74455) gains access to KA-SAT management network via misconfigured VPN
February 24, 2022 ~05:00 UTCAcidRain wiper deployed to SATCOM terminals; ~50,000 modems bricked across Ukraine and Europe
February 24, 2022Enercon confirms loss of remote access to 5,800 wind turbines in Germany
March 31, 2022Viasat publishes incident report confirming VPN misconfiguration as initial access vector
March 31, 2022SentinelOne publishes AcidRain malware analysis, identifies it as MIPS ELF wiper
May 10, 2022US, UK, EU, Canada, Australia, New Zealand jointly attribute attack to Russia/Sandworm
May 2022CVE-2022-29868 disclosed for Viasat Surfbeam 2 firmware update vulnerability

The AcidRain Wiper: Technical Analysis

Architecture and Identification

AcidRain is a 32-bit MIPS ELF binary. MIPS (Microprocessor without Interlocked Pipeline Stages) is a common architecture in embedded and networking devices — routers, modems, and SATCOM terminals. The choice of MIPS indicates a wiper specifically compiled for embedded device targets, not general-purpose servers.

 1# File identification of AcidRain sample
 2file 9b4dfaca873961ad19f0f4c09d6de6c6
 3# Output:
 4# 9b4dfaca873961ad19f0f4c09d6de6c6: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV),
 5# statically linked, stripped
 6
 7# Verify architecture
 8readelf -h acidrain.elf | grep -E "Machine|Class|Data"
 9# Class: ELF32
10# Data: 2's complement, big endian
11# Machine: MIPS R3000
12
13# Check for strings in the binary
14strings acidrain.elf | head -40
15# Characteristic strings found by SentinelOne analysis:
16# /dev/
17# /proc/
18# /sys/
19# Iteration through /proc to find block devices
20# ioctl calls for erase operations

Wiper Logic: Flash Memory Destruction via ioctl

AcidRain achieves persistence-destroying flash erasure by issuing ioctl system calls to block device files. The following represents the documented behavior from public malware analysis (SentinelOne, Kaspersky):

 1/*
 2 * Conceptual representation of AcidRain's device destruction logic
 3 * Based on published technical analysis by SentinelOne (March 2022)
 4 * This is a documentation/research representation — NOT functional exploit code
 5 *
 6 * AcidRain iterates over device files and issues destructive ioctl commands
 7 * to erase flash memory on the MIPS-based SATCOM modem hardware
 8 */
 9
10#include <sys/ioctl.h>
11#include <fcntl.h>
12#include <stdio.h>
13
14// MTD (Memory Technology Device) ioctl commands for flash operations
15// These are documented Linux kernel constants
16#define MEMGETINFO    0x80204d01  // Get flash chip info
17#define MEMERASE      0x40084d02  // Erase a flash region
18#define MEMWRITEOOB   0xc00c4d09  // Write out-of-band data
19
20// Documented ioctl values identified in AcidRain by researchers:
21// 0x40045207 — identified in AcidRain: overwrite block device
22// 0x5205      — identified in AcidRain: flash erase command
23
24/*
25 * AcidRain's approach (documented behavior):
26 * 1. Opens /proc/mounts to enumerate all mounted filesystems
27 * 2. Iterates through /dev/ and attempts to open every block device
28 * 3. For each successfully opened device, issues ioctl erase commands
29 * 4. Also directly writes random data to device files to overwrite contents
30 * 5. Recursive filesystem walk to delete individual files
31 * Result: device cannot boot; no remote recovery possible
32 */

 1# Strings output showing AcidRain's target device patterns (from public analysis)
 2# The wiper specifically targets these device paths found via /proc iteration:
 3
 4/dev/sda      # Block devices
 5/dev/mtd0     # MTD flash devices (common in embedded Linux)
 6/dev/mtdblock0
 7/dev/mmcblk0  # eMMC storage
 8/dev/mmcblk1
 9
10# AcidRain also overwrites:
11/dev/mem      # Physical memory device
12/dev/kmem     # Kernel memory
13/dev/nvram    # Non-volatile RAM (stores config/boot parameters)
14
15# Confirmed ioctl codes from SentinelOne analysis:
16# 0x40045207 — Used to wipe block device storage
17# 0x5205     — MTD erase command for flash memory

YARA Detection Rule for AcidRain

rule AcidRain_MIPS_Wiper {
    meta:
        description = "Detects AcidRain SATCOM wiper malware"
        author = "Detection Engineering"
        reference = "https://www.sentinelone.com/labs/acidrain-a-modem-wiper-rains-down-on-europe/"
        date = "2022-03-31"
        hash = "9b4dfaca873961ad19f0f4c09d6de6c6"

    strings:
        // MIPS ELF magic bytes
        $elf_magic = { 7F 45 4C 46 01 02 01 }

        // Characteristic device paths targeted by wiper
        $dev_mtd  = "/dev/mtd" ascii
        $dev_mem  = "/dev/mem" ascii
        $dev_nvram = "/dev/nvram" ascii
        $proc_mounts = "/proc/mounts" ascii

        // ioctl erase command byte sequences (documented in public analysis)
        $ioctl_wipe = { 07 52 04 40 }   // 0x40045207 in big-endian MIPS
        $ioctl_erase = { 05 52 00 00 }  // MTD erase ioctl pattern

        // Recursive file deletion pattern (walk all filesystems)
        $recursive_delete = { 6F 70 65 6E 64 69 72 }  // "opendir"

    condition:
        uint32(0) == 0x7F454C46 and    // ELF magic
        uint8(4) == 1 and               // 32-bit ELF
        uint8(5) == 2 and               // Big-endian (MIPS)
        $elf_magic and
        (2 of ($dev_*)) and
        ($proc_mounts) and
        (1 of ($ioctl_*))
}

rule AcidRain_Similarities_VPNFilter {
    meta:
        description = "Detects code similarities between AcidRain and VPNFilter destructive module"
        reference = "SentinelOne AcidRain analysis noting VPNFilter structural overlap"

    strings:
        $shared_string1 = "/var/tmp/." ascii
        $wipe_routine = { 8F 99 00 00 27 BD FF E0 AF BF }  // Common function prologue pattern
        $mtd_access = { 2F 64 65 76 2F 6D 74 64 }  // "/dev/mtd" hex

    condition:
        all of them
}

Attacker TTPs: How the Management Plane Was Accessed

The VPN misconfiguration that provided initial access represents a class of vulnerability common across critical infrastructure management networks:

Management Plane Exposure Analysis

 1# Assess VPN appliance exposure (defender perspective)
 2# Check for management interfaces exposed to internet
 3
 4# Using shodan CLI to identify exposed management interfaces
 5# (legitimate security research — replace with your own infrastructure)
 6shodan search "title:\"Viasat\" port:443 product:\"management\""
 7
 8# Check your own SATCOM management VPN for internet exposure
 9nmap -sV -p 443,80,8443,8080,4433 <management_ip> --script ssl-cert,http-title
10
11# Verify VPN authentication requirements
12# Misconfigured VPNs may expose:
13# - Unauthenticated API endpoints
14# - Default credentials still in use
15# - Split tunneling that bypasses authentication for certain IP ranges
16# - Management interfaces accessible from any source IP (no ACL)
17
18# Test for unauthenticated access to management API
19curl -k -s https://<mgmt-ip>/api/v1/status --max-time 10
20# Should return 401/403 — if it returns device data, the VPN ACL is misconfigured

SATCOM Traffic Anomaly Detection

 1# Monitor modem management traffic for unusual command patterns
 2# SATCOM management uses SNMP, TR-069 (CWMP), or proprietary protocols
 3
 4# Monitor SNMP traffic for bulk write operations (potential wiper prep)
 5tcpdump -i eth0 'udp port 161 or udp port 162' -w satcom_snmp.pcap
 6# Analyze: look for SetRequest PDUs (writes) in bulk, especially to device config OIDs
 7
 8# TR-069/CWMP monitoring: management commands to SATCOM modems
 9tcpdump -i eth0 'port 7547 or port 7548' -w cwmp_traffic.pcap
10# SetParameterValues RPC to firmware.upgrade.url = attacker_server is a strong IOC
11
12# Modem integrity check: verify firmware hash against known-good baseline
13# This should be automated and run after every management session
14KNOWN_GOOD_HASH="sha256:abc123..."
15CURRENT_HASH=$(ssh modem@<terminal_ip> 'sha256sum /firmware/current.bin' 2>/dev/null)
16if [ "$CURRENT_HASH" != "$KNOWN_GOOD_HASH" ]; then
17    echo "[ALERT] Firmware hash mismatch on terminal $(hostname)"
18    logger -t satcom-monitor "ALERT: Firmware integrity check failed"
19fi

Other Satellite Attack Vectors

Turla APT: Satellite C2 via Hijacked DVB-S (2015–2019)

Russian APT Turla (also known as Snake, Uroburos) used an extraordinarily sophisticated technique: intercepting DVB-S (Digital Video Broadcasting — Satellite) TV broadcast signals to establish covert command and control channels. The technique worked as follows:

  1. Turla identified satellite TV broadcast beams covering areas of interest (Middle East, Africa, Central Asia).
  2. Turla implants on infected machines were configured to forge UDP packets with source IPs matching IP addresses allocated to the satellite ISP’s address range.
  3. These forged packets were sent upstream to the satellite ISP’s uplink — the ISP’s router, seeing a packet destined for a downstream subscriber, broadcast it on the satellite downlink.
  4. The Turla implant, fitted with a DVB-S card to receive the satellite broadcast, received the response.

The result: C2 traffic appeared to originate from the satellite broadcast region (potentially thousands of subscribers) with no traceable uplink from Turla’s infrastructure. Attribution was nearly impossible without capturing both the implant and analyzing the DVB-S broadcast traffic simultaneously.

At USENIX Security 2022, researcher Lennert Wouters demonstrated that Starlink user terminals could be attacked via voltage fault injection (glitching) on the bootloader. By attaching a custom-built FPGA device to the terminal’s power rail and inducing precise voltage glitches, he bypassed the secure boot process and achieved code execution. This work revealed that even next-generation LEO systems have hardware-level attack surfaces.

Detection: Modem Integrity and Management Plane Monitoring

Key Log Sources for SATCOM Environments

Log SourceWhat to Monitor
VPN/Firewall logsManagement plane access from unexpected IPs; off-hours authentication; authentication failures
SNMP logsBulk SetRequest operations; config backup operations prior to wiping
TR-069/CWMP logsFirmware upgrade commands; factory reset RPC calls
Modem syslogBoot failures; flash erase events; unexpected reboot sequences
Network flowUnusual traffic from management servers to terminal IPs; high-bandwidth transfers to terminals

IOCs Associated with AcidRain and Management Plane Attacks

AcidRain SHA-256: 9b4dfaca873961ad19f0f4c09d6de6c6
AcidRain MD5:     bf5a0b2efa1e6e8b8b8edcbc0ff6c4b8

Behavioral IOCs:
- MIPS ELF binary written to embedded device filesystem
- ioctl(fd, 0x40045207, ...) called on /dev/mtd* or /dev/sda*
- /proc/mounts read followed immediately by device file opens across all entries
- All filesystem files deleted recursively before device reboot
- Device fails to boot after management session

Network IOCs:
- Management VPN connections from TOR exit nodes or anonymizing infrastructure
- Authentication from IP addresses geolocated outside expected operator countries
- Firmware upgrade HTTP GETs to IP addresses outside vendor CDN ranges

Defense and Mitigation Controls

VPN and Management Plane Hardening

 1# 1. Restrict management VPN access to specific operator IP ranges
 2# iptables example: allow management access from known NOC IP ranges only
 3iptables -A INPUT -p tcp --dport 443 -s 203.0.113.0/24 -j ACCEPT  # NOC range
 4iptables -A INPUT -p tcp --dport 443 -j DROP  # Drop all other management access
 5
 6# 2. Require MFA for all management plane authentication
 7# Configure strongSwan or OpenVPN to require certificate + TOTP
 8# /etc/ipsec.conf — require both certificate and OTP plugin
 9
10# 3. Log all management sessions with full command capture
11# For SSH-based management:
12export PROMPT_COMMAND='history -a >(logger -t shell-audit -p local6.info)'
13# Or use a PAM-based session logger (pam_tty_audit)
14pam_tty_audit enable=*  # /etc/pam.d/common-session
15
16# 4. Network segmentation: management plane must not be reachable from public internet
17# Management access only via dedicated, firewalled out-of-band management network
18# Terminal management traffic should be isolated from user data traffic (separate VLAN/VRF)

Firmware Signing and Integrity Verification

 1# Firmware signing: require cryptographic signature verification before any firmware update
 2# For equipment supporting UEFI Secure Boot or equivalent:
 3# - Enroll vendor signing certificates
 4# - Enable secure boot in terminal firmware settings
 5# - Reject unsigned or improperly signed firmware images
 6
 7# Automated integrity checking via SNMP (for supported modems)
 8# Retrieve firmware version and compare against deployment baseline
 9snmpget -v2c -c <community> <terminal_ip> sysDescr.0
10# Compare returned firmware version against approved baseline list
11
12# For networks using TR-069: disable unauthenticated firmware push
13# Require mutual TLS (mTLS) authentication between ACS and terminals
14# Restrict the ACS to a specific, firewalled management VLAN

Operational Resilience

 1# Maintain alternative communication paths for critical operations
 2# Risk: SATCOM as single point of failure for critical infrastructure
 3
 4# For industrial/critical infrastructure (like Enercon's situation):
 5# - Primary: SATCOM (KA-SAT, Starlink, or equivalent)
 6# - Secondary: LTE/5G cellular with fixed SIM
 7# - Tertiary: HF radio for command and control of critical functions
 8# - Automated local failover for safety-critical functions (do not require remote command)
 9
10# Document and test failover procedures quarterly
11# Critical systems must be able to operate autonomously for minimum 72 hours
12# without any remote connectivity

MITRE ATT&CK Mapping

TechniqueIDApplication
Exploit Public-Facing ApplicationT1190VPN misconfiguration exploitation
Disk WipeT1561.001AcidRain flash erasure via ioctl
Firmware CorruptionT1495Bricking modem firmware
MasqueradingT1036AcidRain binary appearing as benign process
Network Denial of ServiceT1498SATCOM service disruption
Supply Chain CompromiseT1195Satellite terminal management plane access

References