{
	"id": "97d05e86-5d15-4e23-b7ee-4b9ee2f90ae1",
	"created_at": "2026-04-06T00:08:26.964289Z",
	"updated_at": "2026-04-10T13:11:41.709224Z",
	"deleted_at": null,
	"sha1_hash": "b1eeb9b53298d4aa6beaed99e8810b03f8553005",
	"title": "Unpacking the Blackjack Group's Fuxnet Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 16196098,
	"plain_text": "Unpacking the Blackjack Group's Fuxnet Malware\r\nBy Team82\r\nPublished: 2024-04-12 · Archived: 2026-04-05 14:18:36 UTC\r\nUpdate as of April 15:\r\nThe Blackjack hacker group reached out to Team82 following publication of this blog with some\r\nupdates, in particular around Team82’s contention—based on our initial research from publicly\r\navailable information published by Blackjack—that only around 500 sensor-gateways had been\r\nimpacted by a cyberattack. Blackjack said that the JSON files it made public were only a sample of the\r\nfull extent of their activity, and that the attack was carried out against 2,659 sensor-gateways, about\r\n1,700 of which were “reachable and successfully attacked.” \r\nThe group also said it never claimed to have destroyed 87,000 sensors, rather disabled them by\r\ndestroying the gateways and fuzzing the sensors using a dedicated M-Bus fuzzer within the malware’s\r\ncode. \r\n“We cannot tell how many sensors actually got fried (by M-Bus fuzzing) because …well…we took\r\ndown the network and disabled network access to the sensor-gateways and nobody (us or them) has the\r\nmeans of checking until all routers are restored,” Blackjack said in a message to Team82. “We disabled\r\nsmsd (which they used to trigger remote reboots) so the M-Bus fuzzer will just keep ion flooding until\r\nsomebody physically turns off the sensor-gateway.” \r\nBlackjack also updated its website to reflect this new information, below: https://ruexfil.com/mos/.\r\nTeam82 has updated this blog with new information on M-Bus fuzzing and how this attack disables the\r\nsensor gateways and floods the sensors they manage with random packets of data.\r\nIntroduction\r\nThe Blackjack hacking group, believed to be affiliated with Ukrainian intelligence services, claims to have carried\r\nout a cyberattack that has damaged emergency detection and response capabilities in Moscow and beyond the\r\nRussian capital. The group, linked to cyberattacks this year against a Russian internet provider and Russian\r\nmilitary infrastructure, released information this week about an attack it claims to have carried out against\r\nMoscollector, a Moscow-based company, that is responsible for the construction and monitoring of underground\r\nwater and sewage and communications infrastructure. \r\nThe website ruexfil.com hosts a trove of extensive information about the Moscollector attack, including the\r\nFuxnet malware Blackjack said it used to damage the Moscollector network operations center. The attackers also\r\nposted screenshots of monitoring systems, servers, and databases they say have been wiped and rendered\r\nunusable. Other data, including password dumps, allegedly stolen from Moscollector is also posted on this site. \r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 1 of 28\n\nA screenshot from the ruexfil website where it has shared information, including screenshots and\r\nstolen data, from its attack against Moscollector.\r\nTeam82 and Claroty have not been able to confirm the attackers’ claims, nor whether a cyberattack has had an\r\nimpact on the Russian government’s emergency response capabilities. What follows is our analysis of the Fuxnet\r\nmalware and claims made by Blackjack, based on the information shared by the attackers.\r\nFor example, Blackjack claims to have damaged or destroyed 87,000 remote sensors and IoT collectors. However,\r\nour analysis of data leaked by Blackjack, including the Fuxnet malware, indicates that only a little more than 500\r\nsensor gateways were bricked by the malware in the attack, and the remote sensors and controllers likely remain\r\nintact. If the gateways were indeed damaged, the repairs could be extensive given that these devices are spread out\r\ngeographically across Moscow and its suburbs, and must be either replaced or their firmware must be individually\r\nreflashed.\r\nMoscollector Attack Overview\r\nBlackjack claims its initial compromise of Moscollector began in June 2023, and since then the group said it has\r\nworked slowly in an attempt to cripple the industrial sensors and monitoring infrastructure managed by the\r\ncompany. On Tuesday, the hackers publicly released information about their activities against Moscollector and\r\nthe information stolen in the attack on the ruexfil website. Some of their claims include: \r\nGaining access to Russia’s 112 emergency service number. \r\nHacking and bricking sensors and controllers in critical infrastructure (including airports, subways, gas-pipelines), all of which have been disabled.\r\nSharing details about and code from the Fuxnet malware used in the attack\r\nDisabling network appliances such as routers and firewalls \r\nDeleting servers, workstations and databases; 30 TB of data has been wiped, including backup drives.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 2 of 28\n\nDisabling access to the Moscollector office building (all keycards have been invalidated).\r\nDumping passwords from multiple internal services\r\nSome of the screenshots are below:\r\nA defaced workstation showing a Blackjack image.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 3 of 28\n\nDumps of usernames and passwords from Moscollector main datacenter servers.\r\nDumps of databases from key servers.\r\nDumps of plaintext credentials from a Django-based web server, likely responsible for the sensor\r\nmanagement system.\r\nIdentifying Equipment Targeted in the Attack\r\nScreenshots released by the attackers indicate that the impacted sensors are manufactured by a company named\r\nAO SBK, a Russian company that manufactures a variety of sensor types, ranging from gas measurement sensors\r\nto environmental monitoring equipment.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 4 of 28\n\nA screenshot released by the attackers shows the SBK URL in the code.\r\nThe array of sensors are used in different types of environments, including within fire alarms, gas monitoring\r\nsystems, lighting controls, and more. SBK lists all of them on their website: \r\nA screenshot from the SBK website detailing the different types of sensors they manufacture.\r\nThe 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\r\nbe sent over the internet to a global monitoring system that allows operators visibility into these systems.\r\nAccording to the leaked data by the attackers (including screenshots and JSON exports), there are two types of AO\r\nSBK gateways that were hacked during the attack:\r\nMPSB: Designed for information exchange with external devices through various interfaces. It supports\r\nethernet and serial communication protocols including CAN, RS-232, and RS-485.\r\nTMSB: Similar to MPSB; includes a built-in 3/4G modem that enables it to transmit data over the internet\r\nto a remote system.\r\nThe end goal is to transmit data to a global monitoring system. The two common scenarios are:  \r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 5 of 28\n\nSensor —--- MBus/RS485 → MPSB + IoT Router —---Internet → Monitoring system\r\nSensor —--- MBus/RS485 → TMSB (3g/4g modem) —---Internet → Monitoring system\r\nTo fully explain the attack, we need to start with its most basic targeted component, the end sensor and traverse up\r\nto the full management and monitoring system.\r\nSensors\r\nAt the bottom of the hierarchy are the physical sensors. AO SBK sells a wide range of sensors, including a gas\r\nanalyzer that reads the measurements of different gasses in the air, a temperature sensor, and more. These sensors\r\nare low-level devices whose only goal is to take measurements. \r\nIn order to send the measurements collected by the sensor, a connection is made over a serial/bus to a sensor\r\ngateway using Meter-Bus/RS485 serial communication channel.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 6 of 28\n\nThe environmental monitoring equipment available from AO SKB\r\nHere are three examples of sensors sold by SBK:\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 7 of 28\n\nGas analyzer of the security system (GASBM): Designed for continuous automatic measurements of the\r\nvolume of methane (CH4), carbon dioxide (CO2), oxygen (O2) and/or mass concentration of carbon\r\nmonoxide (CO) in the air of industrial and non-industrial premises (collectors, warehouses , etc.).\r\nGas analyzer of the security system (GASBM)\r\nFire and security system console (PPOSB): Activates an alarm when the sensors read signals of fire or\r\nsmoke.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 8 of 28\n\nFire and security system console.\r\nTemperature and humidity sensor (TVSB): Converts the physical values of temperature and humidity\r\ninto a digital signal and transmits them to the sensor gateway.\r\nSensor Gateways\r\nThe sensor ecosystem is built with physical sensors such as the gas and electricity analyzers that take physical\r\nmeasurements, and orchestrator/gateway devices (MPSB and TMSB) that read and control these basic I/O sensors\r\nand transmit the data to a global monitoring system for central monitoring.\r\nHere are screenshots of the MPSB and TMSB sensor gateways:\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 9 of 28\n\nThe MPSB sensor gateway, designed for information exchange with external devices through\r\nvarious interfaces. It supports ethernet and serial communication protocols including CAN, RS-232,\r\nand RS-485.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 10 of 28\n\nThe TMSB sensor gateway, similar to MPSB, and includes a built-in 3/4G modem that enables it to\r\ntransmit data over the internet to a remote system.\r\nWe can see, from the attackers’ leak, that when one connects to the gateways via SSH they are greeted with a\r\nnotice from the manufacturer that includes a default username and password. \r\nUsername: sbk\r\nPassword: temppwd\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 11 of 28\n\nA screenshot released by the attackers, demonstrating how they connect to a sensor using SSH.\r\nThe attackers also released JSON files with information about the sensor gateways that were impacted in the\r\nattack, including device types and names, IP addresses, communication ports, location data, and more. \r\nA JSON file released by the attackers containing information about all compromised sensors.\r\nSome information about the type of devices in the exported device JSON list includes:\r\nMPSB (sensor gateway): 424 Devices\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 12 of 28\n\nTMSB (sensor gateway+modem): 93 Devices\r\nIBZ (3g router): 93 Devices\r\nWindows 10 (workstation): 9 Devices\r\nWindows 7 (workstation): 1 Device\r\nWindows XP (workstation): 1 Device\r\nNote that there are fewer entries than the 87,000 that were claimed by Blackjack. We believe this is because the\r\nonly compromised devices are the sensor gateways and not the actual end sensors. Any number of sensors may be\r\nconnected behind these gateways via a serial bus such as RS485/Meter-Bus.\r\nWe correlated this information with two Youtube videos (here, here) the attackers released showing the\r\ndeployment of the Fuxnet malware. All of the listed devices from the videos matched the gateways from the JSON\r\nof the extracted devices, which confirms our assumption that only the TMSB/MPSB gateways were attacked with\r\nFuxnet.\r\nCorrelating attacked devices with the sensor gateways from the leaked extracted JSON file\r\nFurthermore, In these files, we also see diagrams and screenshots from the sensor management UI such as these,\r\nshowcasing the network topology:\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 13 of 28\n\nA network topology diagram released by Blackjack.\r\nThe information depicted corresponds to the JSON file described above.\r\nThe information from the JSON file correlates the information from the UI.\r\n3G Router: iRZ RL22w\r\nAside from the TMSB module with the built-in 3/4G capabilities, another option to transmit the data outside to the\r\ninternet is via an IoT router. The attackers reference these routers as iRZ RL22w in their leaks, which are\r\nmanufactured by a Russian company named iRZ that specializes in wireless device manufacturing. The router\r\nmodel attacked is iRZ RL22w, a 3G router. Behind the scenes, the RL22w uses OpenWRT, an open-source project\r\nfor embedded devices based on Linux, used primarily for networking devices, including routers.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 14 of 28\n\nAn IRZ RL22w, the 3G router attacked by Blackjack.\r\nThese routers were likely used as internet-gateway devices, allowing the sensors to be easily internet-connected.\r\nBy connecting a SIM card to the router, and using its 3G capabilities, it can allow remote sites to connect to the\r\ninternet.\r\nWhile there are some publicly known vulnerabilities for IRZ 3G routers, they do not enable zero-click remote\r\ncode execution. Instead, the attackers chose to use the SSH service to connect to these IoT devices and tunnel to\r\ninternal devices, probably after obtaining the root passwords for these devices. Eventually, the attackers were able\r\nto gain full access as shown in the screenshots they released.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 15 of 28\n\nA screenshot released by Blackjack showing them connecting a compromised IRZ router using the\r\nroot account.\r\nWhen searching for Internet-exposed IRZ devices using Shodan, we discovered thousands of devices, most of\r\nwhich are located in Russia. Currently, there are around 4,100 IRZ routers that expose their services to the internet\r\ndirectly and around 500 of them enable telnet.\r\nShodan and Censys detects thousands of iRZ routers exposed on the internet\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 16 of 28\n\nOf those directly exposed, Shodan and Censys searches show 500 of them enable Telnet.\r\nSensor Management and Commissioning Software\r\nIn order to manage and configure the sensor, engineers must use the SBKManager software suite. This software,\r\nas shown in pictures on SBK’s website, connects to devices using their proprietary protocol running over\r\nTCP/4321.\r\nThe SBKManager interface shows a connection to sensors that enables engineers to configure them.\r\nUsing this software, it is possible to connect to the sensor and configure its I/O, nodes and readings.\r\nSensor Monitoring System\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 17 of 28\n\nLastly, there is a sensor monitoring system that Blackjack also claims to have compromised. This system is most\r\nlikely a monitoring system that receives telemetry and status reports from all sensors. Using this system, it is\r\npossible to receive alerts and logs from each sensor, and control it remotely. By compromising this system, the\r\nattackers were able to get a full list of managed sensors, and correlate the sensors on a map.\r\nA screenshot from the sensor monitoring system with geolocation markings\r\nA sensor monitoring system view that shows a hospital facility in top bar selection.\r\nAnalyzing the Fuxnet Malware \r\nAn analysis of the behavior of the Fuxnet malware helped identify its logical processes. These are the steps the\r\nattackers took:\r\nDeploy Script\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 18 of 28\n\nLock up the device and destroy the filesystem\r\nDestroy NAND Chips\r\nDestroy UBI Volume\r\nFlood M-Bus\r\nDeployment Script\r\nThe first step the attackers took was to compose a full list of target sensor gateways IPs they wished to attack,\r\nalong with a description of the sensor correlating to its physical location, down to its neighborhood, street, or\r\nfacility. They then distributed their malware to each target, likely either through remote-access protocols such as\r\nSSH or the sensor protocol (SBK) over port 4321.\r\nThe deployment script for the Fuxnet malware.\r\nLocking Up Devices and Destroying the Filesystem\r\nOnce running on the target device, the malware forks a new child process to lock out the device. It starts by\r\nremounting the filesystem and giving it write access. Then it begins to delete crucial filesystem files and\r\ndirectories, along with shutting down remote access services such as SSH, HTTP, telnet, and SNMP. This way,\r\neven if the router remains in working condition, no one can access it remotely to restore its operations.\r\nThen, the attackers delete the routing table for the router, rendering its ability to communicate with other devices\r\ninoperable.\r\nLastly, the malware deletes the filesystem of the device, and rewrites the flash memory using the operating system\r\nmtdblock devices.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 19 of 28\n\nThe reaper_start routine, responsible for filesystem corruption and device lockout.\r\nDestroying NAND Chips\r\nAfter corrupting the filesystem and blocking access to the device, the malware moves on to physically destroy the\r\nNAND memory chips on the device. In order to do so, the malware performs a bit-flip operation on entire sections\r\nof the SSD NAND chip, constantly writing and rewriting the memory, only stopping when the malware fails to\r\nwrite to the memory due to it being corrupted. Since the gateway uses NAND memory, which can only write and\r\nre-write data a certain number of times (known as the NAND write cycles), constantly rewriting the memory\r\ncauses the chip to malfunction and be inoperable. \r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 20 of 28\n\nThe routine in charge of corrupting the Nand memory.\r\nDestroying UBI Volume\r\nIn order to ensure the sensor does not reboot again, the malware rewrites the UBI volume. First, the malware uses\r\nthe IOCTL interface UBI_IOCVOLUP allowing it to interact with the management layer controlling the flash\r\nmemory, which tells the kernel that the UBI volume will be rewritten, and that x-number of bytes will be written.\r\nIn its normal behavior, the kernel will know that the rewrite is finished only when x-number of bytes were written.\r\nHowever, the malware will not write x-number of bytes to the UBI, instead it will write fewer bytes than it\r\ndeclares, causing the device to wait for the rewrite to finish indefinitely. \r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 21 of 28\n\nThen the malware overwrites the UBI volume with junk data (0xFF), rendering the UBI useless and the filesystem\r\nunstable.\r\nA source code snippet presenting the routine overwriting and disrupting the UBI volume managing\r\nthe flash memory peripheral\r\nDenial-Of-Service on Monitoring\r\nAs mentioned earlier, the sensor gateway is responsible for receiving information from the sensors and delivering\r\nit to the global monitoring system. Meaning, behind each gateway, over a dedicated serial bus, there are multiple\r\nsensors that are collecting physical data. Usually the sensors are connected to the gateway over RS485/Meter-Bus\r\nchannel. \r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 22 of 28\n\nA look at the serial ports on the TMSB gateway. Sensors will be connected behind these ports. The\r\nmalware will try to flood these ports with unknown packets.\r\nThe malware tries its best to disrupt the sensors behind the gateway by flooding the serial channels with\r\npresumably random data, effectively overloading the serial bus and the sensors.\r\nDuring the malware operation, it will repeatedly write arbitrary data over the Meter-Bus channel. This will prevent\r\nthe sensors and the sensor gateway from sending and receiving data, rendering the sensor data acquisition useless.\r\nTherefore, despite the attackers’ claim of compromising 87,000 devices, it seems that they actually managed to\r\ninfect the sensor gateways only and were trying to cause further disruption by flooding the Meter-Bus channel\r\nconnecting the different sensors to the gateway, similar to network fuzzing the different connected sensor\r\nequipment. As a result, it appears only the sensor gateways were bricked, and not the end-sensors.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 23 of 28\n\nA screenshot released by the attackers, flooding the M-Bus bus with packets.\r\nFrying Sensors?\r\nM-Bus\r\nThe serial M-Bus (Meter-Bus) communication protocol is primarily used in metering applications, especially for\r\nremote reading of utility meters like electricity, gas, water, and heat. It's based on the EN-13757 series of\r\nEuropean standards.\r\nAt its core, M-Bus is a complex, yet detailed, serial protocol operating over a two-wire bus, allowing for\r\nasynchronous serial communication over different baud rates. Per this protocol, a Master node connects to various\r\nslave nodes; in the case of the Moscollector attack, these are the sensor devices collecting data, and polling them\r\nfor data over the bus.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 24 of 28\n\nDiagram presenting the basic M-Bus channel construct.\r\nThe message structure of the M-Bus protocol consists of a series of data frames sent constantly over the bus. Each\r\nframe begins with an M-Bus start delimiter, followed by the unique identifier of the sensor being accessed (each\r\nsensor has a unique identifier, allowing the master to communicate with specific devices), the data being sent, and\r\na checksum.\r\nIn the AO SBK architecture, the physical sensors are the M-Bus slaves, sending only the metrics they collect to\r\nthe sensor-gateway (MPSB/TMSB modules), which act as the Master node. By gaining control over the sensor\r\ngateway, it is possible to send M-Bus messages to all sensors that are connected to it over the serial bus. \r\nHere are some examples of M-Bus packets as depicted in the M-Bus documentation.\r\nSet the slave to primary address 8 without changing anything else:\r\n68 06 06 68 | 53 FE 51 | 01 7A 08 | 25 16\r\nSet the complete identification of the slave (ID=01020304, Man=4024h (PAD), Gen=1, Med=4 (Heat):\r\n68 0D 0D 68 | 53 FE 51 | 07 79 04 03 02 01 24 40 01 04 | 95 16\r\nSet identification number of the slave to \"12345678\" and the 8 digit BCD-Counter (unit 1 kWh) to 107\r\nkWh.\r\n68 0F 0F 68 | 53 FE 51| 0C 79 78 56 34 12 | 0C 06 07 01 00 00 | 55 16\r\nM-Bus is well documented and there are even multiple clients enabling users to communicate easily with M-Bus\r\nsupport devices, for example pyMeterBus.\r\nThe attackers shared the M-Bus message struct they used in order to create and send M-Bus messages, as well as\r\ntheir CRC constants. This code can be seen here:\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 25 of 28\n\nA picture released by the attackers, showcasing their MBus protocol structures and constants.\r\nICS Malware, M-Bus Fuzzing\r\nWith the goal of attacking and corrupting the sensor components of Moscow’s gas and electricity monitoring\r\ninfrastructure. Blackjack implemented a custom-made industrial malware. As stated above, we called this attack\r\nan “M-Bus Flooding,” or the process of sending M-Bus frames constantly over the serial channel, most likely\r\nRS485. \r\nWe inferred that the attackers tried to overwhelm the bus channel with the amount of frames they were sending, in\r\norder to disable sensor communication over that channel. It seems like the attackers wanted to both flood the serial\r\nchannel and also potentially trigger a bug or vulnerability in the sensors that would damage them.\r\nIn order to fuzz the M-Bus protocol stack of the different sensors, the attackers had to implement a module in the\r\nICS malware implant which carries out this part of the attack. After more research and reviewing new screenshots\r\nreleased by attackers (on April 15), we discovered their fuzzing approach.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 26 of 28\n\nThe code released by the attackers, which handles the M-Bus fuzzing process.\r\nIn their malware, Blackjack implemented two approaches of M-Bus fuzzing: structured fuzzing and random\r\nfuzzing. In their random approach (lines 305-310 mk_mbus_mode == 1 ), Blackjack’s malware simply generates\r\nrandom bytes and sends them over the M-Bus wire. In order to make sure frames are not dropped by the sensors,\r\nthe malware also calculates a simple M-Bus CRC, appending it to the random frame. This approach “runs” over\r\nthe whole range of possible M-Bus payloads, valid or not, with the hope of causing issues in the sensors. This is\r\nsimilar to the methodology for fuzzing software looking for a zero-day vulnerability.\r\nIn Blackjack’s structured fuzzing (lines 285-303 mk_mbus_mode == 0 ) approach, Fuxnet tries to generate a valid\r\nM-Bus frame, only randomizing specific M-Bus fields. This way, the malware adheres to the M-Bus protocol\r\nstructure, which increases the likelihood of the sensor treating the packet as valid and fully parsing it. This way,\r\nmore parsing flow is executed by the sensor, which increases the chances for a vulnerability triggering.\r\nBy implementing these two fuzzing approaches in its malware, Blackjack showed that its real goal was not simply\r\noverwhelming the bus channel, but instead they hoped to trigger an existing undiscovered vulnerability and\r\ncorrupt the sensors themselves.\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 27 of 28\n\nKey Takeaways\r\nBlackjack’s alleged attack against Moscollector, a key provider to civilian infrastructure in Moscow and beyond,\r\nand its impact on emergency detection and response capabilities cannot be confirmed beyond information leaked\r\nby the hacker group and published reports from Ukrainian media. \r\nTeam82’s analysis of the published information from the attack, including the Fuxnet malware, demonstrates an\r\nunderstanding of the connected devices critical to these services operated and managed by Moscollector. \r\nThe attackers developed and deployed malware that targeted the gateways and deleted filesystems, directories,\r\ndisabled remote access services, routing services for each device, and rewrote flash memory, destroyed NAND\r\nmemory chips, UBI volumes and other actions that further disrupted operation of these gateways. \r\nThe ruexfil website also claims the destruction of 87,000 remote sensors and IoT collectors dispersed across\r\nMoscow and beyond. Team82 believes that the sensors and collectors are likely intact, and that only 500 or more\r\nsensor gateways were damaged. Each would have to be individually replaced or have their firmware re-flashed.\r\nSource: https://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nhttps://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware\r\nPage 28 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"MISPGALAXY",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://claroty.com/team82/research/unpacking-the-blackjack-groups-fuxnet-malware"
	],
	"report_names": [
		"unpacking-the-blackjack-groups-fuxnet-malware"
	],
	"threat_actors": [
		{
			"id": "6f30fd35-b1c9-43c4-9137-2f61cd5f031e",
			"created_at": "2025-08-07T02:03:25.082908Z",
			"updated_at": "2026-04-10T02:00:03.744649Z",
			"deleted_at": null,
			"main_name": "NICKEL FOXCROFT",
			"aliases": [
				"APT37 ",
				"ATK4 ",
				"Group 123 ",
				"InkySquid ",
				"Moldy Pisces ",
				"Operation Daybreak ",
				"Operaton Erebus ",
				"RICOCHET CHOLLIMA ",
				"Reaper ",
				"ScarCruft ",
				"TA-RedAnt ",
				"Venus 121 "
			],
			"source_name": "Secureworks:NICKEL FOXCROFT",
			"tools": [
				"Bluelight",
				"Chinotto",
				"GOLDBACKDOOR",
				"KevDroid",
				"KoSpy",
				"PoorWeb",
				"ROKRAT",
				"final1stpy"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "1a9c4f3f-2178-4c83-a9b5-d2135d90520a",
			"created_at": "2024-04-19T02:00:03.623733Z",
			"updated_at": "2026-04-10T02:00:03.615238Z",
			"deleted_at": null,
			"main_name": "BlackJack",
			"aliases": [],
			"source_name": "MISPGALAXY:BlackJack",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "9b02c527-5077-489e-9a80-5d88947fddab",
			"created_at": "2022-10-25T16:07:24.103499Z",
			"updated_at": "2026-04-10T02:00:04.867181Z",
			"deleted_at": null,
			"main_name": "Reaper",
			"aliases": [
				"APT 37",
				"ATK 4",
				"Cerium",
				"Crooked Pisces",
				"G0067",
				"Geumseong121",
				"Group 123",
				"ITG10",
				"InkySquid",
				"Moldy Pisces",
				"Opal Sleet",
				"Operation Are You Happy?",
				"Operation Battle Cruiser",
				"Operation Black Banner",
				"Operation Daybreak",
				"Operation Dragon messenger",
				"Operation Erebus",
				"Operation Evil New Year",
				"Operation Evil New Year 2018",
				"Operation Fractured Block",
				"Operation Fractured Statue",
				"Operation FreeMilk",
				"Operation Golden Bird",
				"Operation Golden Time",
				"Operation High Expert",
				"Operation Holiday Wiper",
				"Operation Korean Sword",
				"Operation North Korean Human Right",
				"Operation Onezero",
				"Operation Rocket Man",
				"Operation SHROUDED#SLEEP",
				"Operation STARK#MULE",
				"Operation STIFF#BIZON",
				"Operation Spy Cloud",
				"Operation Star Cruiser",
				"Operation ToyBox Story",
				"Osmium",
				"Red Eyes",
				"Ricochet Chollima",
				"Ruby Sleet",
				"ScarCruft",
				"TA-RedAnt",
				"TEMP.Reaper",
				"Venus 121"
			],
			"source_name": "ETDA:Reaper",
			"tools": [
				"Agentemis",
				"BLUELIGHT",
				"Backdoor.APT.POORAIM",
				"CARROTBALL",
				"CARROTBAT",
				"CORALDECK",
				"Cobalt Strike",
				"CobaltStrike",
				"DOGCALL",
				"Erebus",
				"Exploit.APT.RICECURRY",
				"Final1stSpy",
				"Freenki Loader",
				"GELCAPSULE",
				"GOLDBACKDOOR",
				"GreezeBackdoor",
				"HAPPYWORK",
				"JinhoSpy",
				"KARAE",
				"KevDroid",
				"Konni",
				"MILKDROP",
				"N1stAgent",
				"NavRAT",
				"Nokki",
				"Oceansalt",
				"POORAIM",
				"PoohMilk",
				"PoohMilk Loader",
				"RICECURRY",
				"RUHAPPY",
				"RokRAT",
				"SHUTTERSPEED",
				"SLOWDRIFT",
				"SOUNDWAVE",
				"SYSCON",
				"Sanny",
				"ScarCruft",
				"StarCruft",
				"Syscon",
				"VeilShell",
				"WINERACK",
				"ZUMKONG",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434106,
	"ts_updated_at": 1775826701,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b1eeb9b53298d4aa6beaed99e8810b03f8553005.pdf",
		"text": "https://archive.orkl.eu/b1eeb9b53298d4aa6beaed99e8810b03f8553005.txt",
		"img": "https://archive.orkl.eu/b1eeb9b53298d4aa6beaed99e8810b03f8553005.jpg"
	}
}