Unpacking the Blackjack Group's Fuxnet Malware

Update as of April 15:

The Blackjack hacker group reached out to Team82 following publication of this blog with some updates, in particular around Team82’s contention—based on our initial research from publicly available information published by Blackjack—that only around 500 sensor-gateways had been impacted by a cyberattack. Blackjack said that the JSON files it made public were only a sample of the full extent of their activity, and that the attack was carried out against 2,659 sensor-gateways, about 1,700 of which were “reachable and successfully attacked.” 

The group also said it never claimed to have destroyed 87,000 sensors, rather disabled them by destroying the gateways and fuzzing the sensors using a dedicated M-Bus fuzzer within the malware’s code. 

“We cannot tell how many sensors actually got fried (by M-Bus fuzzing) because …well…we took down the network and disabled network access to the sensor-gateways and nobody (us or them) has the means of checking until all routers are restored,” Blackjack said in a message to Team82. “We disabled smsd (which they used to trigger remote reboots) so the M-Bus fuzzer will just keep ion flooding until somebody physically turns off the sensor-gateway.” 

Blackjack also updated its website to reflect this new information, below: https://ruexfil.com/mos/. Team82 has updated this blog with new information on M-Bus fuzzing and how this attack disables the sensor gateways and floods the sensors they manage with random packets of data.

Introduction

The Blackjack hacking group, believed to be affiliated with Ukrainian intelligence services, claims to have carried out a cyberattack that has damaged emergency detection and response capabilities in Moscow and beyond the Russian capital. The group, linked to cyberattacks this year against a Russian internet provider and Russian military infrastructure, released information this week about an attack it claims to have carried out against Moscollector, a Moscow-based company, that is responsible for the construction and monitoring of underground water and sewage and communications infrastructure. 

The website ruexfil.com hosts a trove of extensive information about the Moscollector attack, including the Fuxnet malware Blackjack said it used to damage the Moscollector network operations center. The attackers also posted screenshots of monitoring systems, servers, and databases they say have been wiped and rendered unusable. Other data, including password dumps, allegedly stolen from Moscollector is also posted on this site. 

Team82 and Claroty have not been able to confirm the attackers’ claims, nor whether a cyberattack has had an impact on the Russian government’s emergency response capabilities. What follows is our analysis of the Fuxnet malware and claims made by Blackjack, based on the information shared by the attackers.

For example, Blackjack claims to have damaged or destroyed 87,000 remote sensors and IoT collectors. However, our analysis of data leaked by Blackjack, including the Fuxnet malware, indicates that only a little more than 500 sensor gateways were bricked by the malware in the attack, and the remote sensors and controllers likely remain intact. If the gateways were indeed damaged, the repairs could be extensive given that these devices are spread out geographically across Moscow and its suburbs, and must be either replaced or their firmware must be individually reflashed.

Moscollector Attack Overview

Blackjack claims its initial compromise of Moscollector began in June 2023, and since then the group said it has worked slowly in an attempt to cripple the industrial sensors and monitoring infrastructure managed by the company. On Tuesday, the hackers publicly released information about their activities against Moscollector and the information stolen in the attack on the ruexfil website. Some of their claims include: 

• Gaining access to Russia’s 112 emergency service number. 

• Hacking and bricking sensors and controllers in critical infrastructure (including airports, subways, gas-pipelines), all of which have been disabled.

• Sharing details about and code from the Fuxnet malware used in the attack

• Disabling network appliances such as routers and firewalls 

• Deleting servers, workstations and databases; 30 TB of data has been wiped, including backup drives.

• Disabling access to the Moscollector office building (all keycards have been invalidated).

• Dumping passwords from multiple internal services

Some of the screenshots are below:

Identifying Equipment Targeted in the Attack

Screenshots released by the attackers indicate that the impacted sensors are manufactured by a company named AO SBK, a Russian company that manufactures a variety of sensor types, ranging from gas measurement sensors to environmental monitoring equipment.

The array of sensors are used in different types of environments, including within fire alarms, gas monitoring systems, lighting controls, and more. SBK lists all of them on their website: 

The sensors collect physical data, such as temperature, and transmit it via a serial/bus such as an RS485/Meter-Bus to a gateway. All the sensors are connected to a gateway, which is a transmission unit that enables telemetry to be sent over the internet to a global monitoring system that allows operators visibility into these systems.

According to the leaked data by the attackers (including screenshots and JSON exports), there are two types of AO SBK gateways that were hacked during the attack:

• MPSB: Designed for information exchange with external devices through various interfaces. It supports ethernet and serial communication protocols including CAN, RS-232, and RS-485.

• TMSB: Similar to MPSB; includes a built-in 3/4G modem that enables it to transmit data over the internet to a remote system.

The end goal is to transmit data to a global monitoring system. The two common scenarios are:  

Sensor —--- MBus/RS485 → MPSB + IoT Router —---Internet → Monitoring system

Sensor —--- MBus/RS485 → TMSB (3g/4g modem) —---Internet → Monitoring system

To fully explain the attack, we need to start with its most basic targeted component, the end sensor and traverse up to the full management and monitoring system.

Sensors

At the bottom of the hierarchy are the physical sensors. AO SBK sells a wide range of sensors, including a gas analyzer that reads the measurements of different gasses in the air, a temperature sensor, and more. These sensors are low-level devices whose only goal is to take measurements. 

In order to send the measurements collected by the sensor, a connection is made over a serial/bus to a sensor gateway using Meter-Bus/RS485 serial communication channel.

Here are three examples of sensors sold by SBK:

• Gas analyzer of the security system (GASBM): Designed for continuous automatic measurements of the volume of methane (CH4), carbon dioxide (CO2), oxygen (O2) and/or mass concentration of carbon monoxide (CO) in the air of industrial and non-industrial premises (collectors, warehouses , etc.).

• Fire and security system console (PPOSB): Activates an alarm when the sensors read signals of fire or smoke.

• Temperature and humidity sensor (TVSB): Converts the physical values ​​of temperature and humidity into a digital signal and transmits them to the sensor gateway.

Sensor Gateways

The sensor ecosystem is built with physical sensors such as the gas and electricity analyzers that take physical measurements, and orchestrator/gateway devices (MPSB and TMSB) that read and control these basic I/O sensors and transmit the data to a global monitoring system for central monitoring.

Here are screenshots of the MPSB and TMSB sensor gateways:

We can see, from the attackers’ leak, that when one connects to the gateways via SSH they are greeted with a notice from the manufacturer that includes a default username and password. 

• Username: sbk

• Password: temppwd

The attackers also released JSON files with information about the sensor gateways that were impacted in the attack, including device types and names, IP addresses, communication ports, location data, and more. 

Some information about the type of devices in the exported device JSON list includes:

• MPSB (sensor gateway): 424 Devices

• TMSB (sensor gateway+modem): 93 Devices

• IBZ (3g router): 93 Devices

• Windows 10 (workstation): 9 Devices

• Windows 7 (workstation): 1 Device

• Windows XP (workstation): 1 Device

Note that there are fewer entries than the 87,000 that were claimed by Blackjack. We believe this is because the only compromised devices are the sensor gateways and not the actual end sensors. Any number of sensors may be connected behind these gateways via a serial bus such as RS485/Meter-Bus.

We correlated this information with two Youtube videos (here, here) the attackers released showing the deployment of the Fuxnet malware. All of the listed devices from the videos matched the gateways from the JSON of the extracted devices, which confirms our assumption that only the TMSB/MPSB gateways were attacked with Fuxnet.

Furthermore, In these files, we also see diagrams and screenshots from the sensor management UI such as these, showcasing the network topology:

The information depicted corresponds to the JSON file described above.

3G Router: iRZ RL22w

Aside from the TMSB module with the built-in 3/4G capabilities, another option to transmit the data outside to the internet is via an IoT router. The attackers reference these routers as iRZ RL22w in their leaks, which are manufactured by a Russian company named iRZ that specializes in wireless device manufacturing. The router model attacked is iRZ RL22w, a 3G router. Behind the scenes, the RL22w uses OpenWRT, an open-source project for embedded devices based on Linux, used primarily for networking devices, including routers.

These routers were likely used as internet-gateway devices, allowing the sensors to be easily internet-connected. By connecting a SIM card to the router, and using its 3G capabilities, it can allow remote sites to connect to the internet.

While there are some publicly known vulnerabilities for IRZ 3G routers, they do not enable zero-click remote code execution. Instead, the attackers chose to use the SSH service to connect to these IoT devices and tunnel to internal devices, probably after obtaining the root passwords for these devices. Eventually, the attackers were able to gain full access as shown in the screenshots they released.

When searching for Internet-exposed IRZ devices using Shodan, we discovered thousands of devices, most of which are located in Russia. Currently, there are around 4,100 IRZ routers that expose their services to the internet directly and around 500 of them enable telnet.

Sensor Management and Commissioning Software

In order to manage and configure the sensor, engineers must use the SBKManager software suite. This software, as shown in pictures on SBK’s website, connects to devices using their proprietary protocol running over TCP/4321.

Using this software, it is possible to connect to the sensor and configure its I/O, nodes and readings.

Sensor Monitoring System

Lastly, there is a sensor monitoring system that Blackjack also claims to have compromised. This system is most likely a monitoring system that receives telemetry and status reports from all sensors. Using this system, it is possible to receive alerts and logs from each sensor, and control it remotely. By compromising this system, the attackers were able to get a full list of managed sensors, and correlate the sensors on a map.

Analyzing the Fuxnet Malware 

An analysis of the behavior of the Fuxnet malware helped identify its logical processes. These are the steps the attackers took:

• Deploy Script

• Lock up the device and destroy the filesystem

• Destroy NAND Chips

• Destroy UBI Volume

• Flood M-Bus

Deployment Script

The first step the attackers took was to compose a full list of target sensor gateways IPs they wished to attack, along with a description of the sensor correlating to its physical location, down to its neighborhood, street, or facility. They then distributed their malware to each target, likely either through remote-access protocols such as SSH or the sensor protocol (SBK) over port 4321.

Locking Up Devices and Destroying the Filesystem

Once running on the target device, the malware forks a new child process to lock out the device. It starts by remounting the filesystem and giving it write access. Then it begins to delete crucial filesystem files and directories, along with shutting down remote access services such as SSH, HTTP, telnet, and SNMP. This way, even if the router remains in working condition, no one can access it remotely to restore its operations.

Then, the attackers delete the routing table for the router, rendering its ability to communicate with other devices inoperable.

Lastly, the malware deletes the filesystem of the device, and rewrites the flash memory using the operating system mtdblock devices.

Destroying NAND Chips

After corrupting the filesystem and blocking access to the device, the malware moves on to physically destroy the NAND memory chips on the device. In order to do so, the malware performs a bit-flip operation on entire sections of the SSD NAND chip, constantly writing and rewriting the memory, only stopping when the malware fails to write to the memory due to it being corrupted. Since the gateway uses NAND memory, which can only write and re-write data a certain number of times (known as the NAND write cycles), constantly rewriting the memory causes the chip to malfunction and be inoperable. 

Destroying UBI Volume

In order to ensure the sensor does not reboot again, the malware rewrites the UBI volume. First, the malware uses the IOCTL interface UBI_IOCVOLUP allowing it to interact with the management layer controlling the flash memory, which tells the kernel that the UBI volume will be rewritten, and that x-number of bytes will be written. In its normal behavior, the kernel will know that the rewrite is finished only when x-number of bytes were written. However, the malware will not write x-number of bytes to the UBI, instead it will write fewer bytes than it declares, causing the device to wait for the rewrite to finish indefinitely. 

Then the malware overwrites the UBI volume with junk data (0xFF), rendering the UBI useless and the filesystem unstable.

Denial-Of-Service on Monitoring

As mentioned earlier, the sensor gateway is responsible for receiving information from the sensors and delivering it to the global monitoring system. Meaning, behind each gateway, over a dedicated serial bus, there are multiple sensors that are collecting physical data. Usually the sensors are connected to the gateway over RS485/Meter-Bus channel. 

The malware tries its best to disrupt the sensors behind the gateway by flooding the serial channels with presumably random data, effectively overloading the serial bus and the sensors.

During the malware operation, it will repeatedly write arbitrary data over the Meter-Bus channel. This will prevent the sensors and the sensor gateway from sending and receiving data, rendering the sensor data acquisition useless. Therefore, despite the attackers’ claim of compromising 87,000 devices, it seems that they actually managed to infect the sensor gateways only and were trying to cause further disruption by flooding the Meter-Bus channel connecting the different sensors to the gateway, similar to network fuzzing the different connected sensor equipment. As a result, it appears only the sensor gateways were bricked, and not the end-sensors.

Frying Sensors?

M-Bus

The serial M-Bus (Meter-Bus) communication protocol is primarily used in metering applications, especially for remote reading of utility meters like electricity, gas, water, and heat. It's based on the EN-13757 series of European standards.

At its core, M-Bus is a complex, yet detailed, serial protocol operating over a two-wire bus, allowing for asynchronous serial communication over different baud rates. Per this protocol, a Master node connects to various slave nodes; in the case of the Moscollector attack, these are the sensor devices collecting data, and polling them for data over the bus.

The message structure of the M-Bus protocol consists of a series of data frames sent constantly over the bus. Each frame begins with an M-Bus start delimiter, followed by the unique identifier of the sensor being accessed (each sensor has a unique identifier, allowing the master to communicate with specific devices), the data being sent, and a checksum.

In the AO SBK architecture, the physical sensors are the M-Bus slaves, sending only the metrics they collect to the sensor-gateway (MPSB/TMSB modules), which act as the Master node. By gaining control over the sensor gateway, it is possible to send M-Bus messages to all sensors that are connected to it over the serial bus. 

Here are some examples of M-Bus packets as depicted in the M-Bus documentation.

Set the slave to primary address 8 without changing anything else:

68 06 06 68 | 53 FE 51 | 01 7A 08 | 25 16




Set the complete identification of the slave (ID=01020304, Man=4024h (PAD), Gen=1, Med=4 (Heat):

68 0D 0D 68 | 53 FE 51 | 07 79 04 03 02 01 24 40 01 04 | 95 16




Set identification number of the slave to "12345678" and the 8 digit BCD-Counter (unit 1 kWh) to 107 kWh.

68 0F 0F 68 | 53 FE 51| 0C 79 78 56 34 12 | 0C 06 07 01 00 00 | 55 16

M-Bus is well documented and there are even multiple clients enabling users to communicate easily with M-Bus support devices, for example pyMeterBus.

The attackers shared the M-Bus message struct they used in order to create and send M-Bus messages, as well as their CRC constants. This code can be seen here:

ICS Malware, M-Bus Fuzzing

With the goal of attacking and corrupting the sensor components of Moscow’s gas and electricity monitoring infrastructure. Blackjack implemented a custom-made industrial malware. As stated above, we called this attack an “M-Bus Flooding,” or the process of sending M-Bus frames constantly over the serial channel, most likely RS485. 

We inferred that the attackers tried to overwhelm the bus channel with the amount of frames they were sending, in order to disable sensor communication over that channel. It seems like the attackers wanted to both flood the serial channel and also potentially trigger a bug or vulnerability in the sensors that would damage them.

In order to fuzz the M-Bus protocol stack of the different sensors, the attackers had to implement a module in the ICS malware implant which carries out this part of the attack. After more research and reviewing new screenshots released by attackers (on April 15), we discovered their fuzzing approach.

In their malware, Blackjack implemented two approaches of M-Bus fuzzing: structured fuzzing and random fuzzing. In their random approach (lines 305-310 mk_mbus_mode == 1), Blackjack’s malware simply generates random bytes and sends them over the M-Bus wire. In order to make sure frames are not dropped by the sensors, the malware also calculates a simple M-Bus CRC, appending it to the random frame. This approach “runs” over the whole range of possible M-Bus payloads, valid or not, with the hope of causing issues in the sensors. This is similar to the methodology for fuzzing software looking for a zero-day vulnerability.

In Blackjack’s structured fuzzing (lines 285-303 mk_mbus_mode == 0) approach, Fuxnet tries to generate a valid M-Bus frame, only randomizing specific M-Bus fields. This way, the malware adheres to the M-Bus protocol structure, which increases the likelihood of the sensor treating the packet as valid and fully parsing it. This way, more parsing flow is executed by the sensor, which increases the chances for a vulnerability triggering.

By implementing these two fuzzing approaches in its malware, Blackjack showed that its real goal was not simply overwhelming the bus channel, but instead they hoped to trigger an existing undiscovered vulnerability and corrupt the sensors themselves.

Key Takeaways

Blackjack’s alleged attack against Moscollector, a key provider to civilian infrastructure in Moscow and beyond, and its impact on emergency detection and response capabilities cannot be confirmed beyond information leaked by the hacker group and published reports from Ukrainian media. 

Team82’s analysis of the published information from the attack, including the Fuxnet malware, demonstrates an understanding of the connected devices critical to these services operated and managed by Moscollector. 

The attackers developed and deployed malware that targeted the gateways and deleted filesystems, directories, disabled remote access services, routing services for each device, and rewrote flash memory, destroyed NAND memory chips, UBI volumes and other actions that further disrupted operation of these gateways. 

The ruexfil website also claims the destruction of 87,000 remote sensors and IoT collectors dispersed across Moscow and beyond. Team82 believes that the sensors and collectors are likely intact, and that only 500 or more sensor gateways were damaged. Each would have to be individually replaced or have their firmware re-flashed.