Keypoints
- Blackjack claims to have attacked Moscollector and used Fuxnet to disrupt monitoring of Moscow infrastructure, but analysis suggests ~500+ sensor gateways (not 87,000 sensors) were bricked.
- The primary targets were AO SBK sensor gateways (MPSB, TMSB), 3G routers (iRZ RL22w), and the Moscollector sensor management/monitoring systems.
- Initial access and deployment vectors included SSH and the SBK sensor protocol over TCP/4321, with evidence of default credentials (username: sbk, password: temppwd) and exposed routers discovered via Shodan.
- Fuxnet’s destructive workflow: deploy script → lock device & disable services → delete filesystem → corrupt NAND via write exhaustion → corrupt UBI volumes to prevent recovery → flood/fuzz M‑Bus serial bus.
- M‑Bus fuzzing implemented two modes: random byte generation with CRC and structured fuzzing that randomizes specific M‑Bus fields to increase parsing coverage and trigger latent bugs.
- Leaked JSON exports, UI screenshots, and attacker videos were used to correlate compromised gateways and validate which device types were affected.
MITRE Techniques
- [T1078] Valid Accounts – Used default gateway credentials; ‘[when one connects to the gateways via SSH they are greeted with a notice from the manufacturer that includes a default username and password.]’
- [T1021] Remote Services – Accessed and tunneled through IoT devices using SSH to reach internal targets; ‘[the attackers chose to use the SSH service to connect to these IoT devices and tunnel to internal devices]’
- [T1059] Command and Scripting Interpreter – Automated deployment via scripts that enumerate target IPs and push malware; ‘[compose a full list of target sensor gateways IPs they wished to attack, … distributed their malware to each target]’
- [T1485] Data Destruction – Deleted filesystems, servers and backups (claimed 30 TB wiped) to render systems unusable; ‘[deleting servers, workstations and databases; 30 TB of data has been wiped]’
- [T1499] Endpoint Denial of Service – Flooded the Meter-Bus/RS485 serial channels with arbitrary frames to disrupt sensor communications; ‘[flooding the serial channels with presumably random data]’
- [T1490] Inhibit System Recovery – Rewrote and corrupted UBI volumes and used partial IOCTL writes to stall recovery and fill flash with junk (0xFF); ‘[the malware rewrites the UBI volume … write fewer bytes than it declares … overwrites the UBI volume with junk data (0xFF)]’
Indicators of Compromise
- [Domain] attacker data site and leaked content – ruexfil.com (attack dump/site), https://ruexfil.com/mos/
- [Vendor domain] referenced device/vendor resources – ao-sbk.ru (AO SBK sensor vendor), irz.net (iRZ router vendor)
- [Credentials] default SSH/admin creds observed – Username: sbk, Password: temppwd
- [Device models] targeted gateway and router models – MPSB (424 devices), TMSB (93 devices), iRZ RL22w router
- [Protocol/Port] management and comms channels used – SBK sensor protocol over TCP/4321, SSH, M‑Bus/RS485 serial bus
- [Artifacts] leaked configuration/data files – JSON exports of compromised devices (device lists, IPs, locations) and screenshots of dashboards
The attackers focused on the sensor gateway layer and network transit rather than directly attacking each field sensor. They enumerated and targeted AO SBK gateways (MPSB/TMSB) and internet-facing routers (iRZ RL22w) — many of which exposed management services — using SSH and the proprietary SBK protocol (TCP/4321). Default credentials and exposed routers found via internet scanning enabled access and tunneling to internal management systems, where the operators distributed a deployment script that pushed the Fuxnet implant to selected IPs.
Once deployed, Fuxnet executes a staged destructive routine: it forks a process to lock the device, remounts filesystems read/write, disables remote services (SSH/HTTP/telnet/SNMP) and deletes critical filesystem files and routing entries to block remote recovery. It then carries out flash-level corruption by repeatedly writing to NAND to exhaust write cycles and by abusing the UBI management IOCTLs (declaring larger writes than performed and filling volumes with 0xFF) to render the UBI and filesystem unusable, preventing normal reboot-based recovery.
Concurrently, the implant targets connected sensors via the Meter-Bus (M‑Bus/RS485) by sending two types of fuzz traffic: structured frames that conform to M‑Bus format while randomizing specific fields to increase parsing depth, and fully random frames with appended CRC to avoid immediate drops. This M‑Bus flooding/fuzzing both blocks telemetry and seeks to trigger parsing vulnerabilities in slave sensors; evidence and leaked JSON/screenshot artifacts indicate the gateways were bricked and sensor communications disrupted, while the end sensors themselves likely remained physically intact and would require gateway replacement or firmware reflash to restore service.
Read more: https://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware