Inside a New Cyberweapon: IOCONTROL 2Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Executive Summary 3 What is the IOCONTROL Malware? 4 IOCONTROL Deployment on ORPAK Systems 5 ORPAK Systems Devices 7 IOCONTROL Binary Analysis 8 Unpacking and Emulation of IOCONTROL 8 Decrypting the Configuration 11 Resolving IOCONTROL Command-and-Control via DOH 14 Persistence 15 Communication with C2 Via MQTT 16 MQTT Protocol 16 Supported Commands 18 IOCONTROL Flow: Simplified 19 IOCONTROL Infrastructure 20 Domain 20 Summary 21 IOCONTROL Indicators of Compromise (IoC) 22 Appendix #1 - Environment Variables (post processing) 23 Appendix #2 - Decrypted Config 23 Contents 3Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Executive Summary • Team82 obtained a sample of a custom-built IoT/OT malware called IOCONTROL used by Iran-affiliated attackers to attack Israel- and U.S.-based OT/IoT devices. • IOCONTROL has been used to attack IoT and SCADA/OT devices of various types including IP cameras, routers, PLCs, HMIs, firewalls, and more. Some of the affected vendors include: Baicells, D-Link, Hikvision, Red Lion, Orpak, Phoenix Contact, Teltonika, Unitronics, and others. • We’ve assessed that IOCONTROL is a cyberweapon used by a nation-state to attack civilian critical infrastructure. • Our analysis of IOCONTROL includes an in-depth look at the malware’s capabilities and unique communication channels to the attackers’ command-and-control infrastructure. 4Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved IOCONTROL is believed to be part of a global cyber operation against western IoT and operational technology (OT) devices. Affected devices include routers, programmable logic controllers (PLCs), human-machine interfaces (HMIs), firewalls, and other Linux-based IoT/OT platforms. While the malware is believed to be custom-built by the threat actor, it seems that the malware is generic enough that it is able to run on a variety of platforms from different vendors due to its modular configuration. Team82 has analyzed a malware sample extracted from a fuel management system that was allegedly compromised by a threat actor group linked to Iran known as the CyberAv3ngers, which is also believed to be responsible for the Unitronics attack last fall. One particular IOCONTROL attack wave involved the compromise of several hundred Israel-made Orpak Systems and U.S.-made Gasboy fuel management systems in Israel and the United States. The malware is essentially custom built for IoT devices but also has a direct impact on OT such as the fuel pumps that are heavily used in gas stations. The attacks are another extension of the geopolitical conflict between Israel and Iran. The so-called CyberAv3ngers are believed to be part of the Islamic Revolutionary Guard Corps Cyber Electronic Command (IRGC-CEC) and have been vocal on Telegram sharing screenshots, and other information about the compromises of these fuel systems. In February, the U.S. Department of the Treasury announced sanctions against six IRGC-CEC officials linked to the CyberAv3ngers and offered a $10 million USD bounty for information leading to the identification or location of anyone involved in the attacks. Our analysis of the sample we obtained from VirusTotal (21 detections as of Dec. 10 2024, after a period of time when there were still zero detections as of September 2024) concludes that the malware is essentially a cyberweapon used by a nation-state to attack civilian critical infrastructure; at least one of the victims were the Orpak and Gasboy fuel management systems. For secure communication between compromised devices and the attackers, IOCONTROL leverages the MQTT protocol as a dedicated IoT communication channel. The attackers were able to disguise traffic over MQTT to and from the attackers’ command-and- control infrastructure. The CyberAv3ngers, meanwhile, have implicitly stated they will continue to target Israel-made technology in critical infrastructure. In October 2023, water treatment facilities in the U.S. and Israel were attacked by the group. Integrated Unitronics Vision series PLC/HMI devices were targeted inside these facilities; the attacks resulted in the defacement of these OT devices. The attacks were likely projections of power from the CyberAv3ngers, demonstrating their access to the devices and hoping to instill fear regarding the quality of water in affected areas. A DEDICATED CYBERAV3NGERS SCRIPT RUNNING, AND ALLEGEDLY BRICKING, ORPAK SYSTEMS. What is the IOCONTROL Malware? TEAM82 RESEARCH https://claroty.com/team82/research/from-exploits-to-forensics-unraveling-the-unitronics-attack https://www.orpak.com/ https://www.orpak.com/ https://www.gasboy.com/us/ https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-335a https://rewardsforjustice.net/rewards/cyberav3ngers/ https://claroty.com/team82/research/from-exploits-to-forensics-unraveling-the-unitronics-attack https://claroty.com/team82/research/from-exploits-to-forensics-unraveling-the-unitronics-attack 5Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved IOCONTROL Deployment on ORPAK Systems Around the same time of the attacks against water facilities, the CyberAv3ngers published on Telegram claims it had attacked 200 gas stations in Israel and the U.S., specifically targeting Orpak systems. The attackers released screenshots of the main management portal of the attacked gas stations, as well as databases of information about their targets and leaked data. ABOVE LEFT: A SCREENSHOT OF THE CYBERAV3NGERS TELEGRAM CHANNEL WHERE THEY DISCUSSED AN ATTACK AGAINST ORPAK FUEL MANAGEMENT DEVICES. ABOVE RIGHT: A SCREENSHOT SHARED ON TELEGRAM BY CYBERAV3NGERS THAT SHOWS THEY’D GAINED ACCESS TO ORPAK SITEOMAT FUEL MANAGEMENT SYSTEMS. DRAFT | Claroty Research - Team82 Our analysis of the sample we obtained from VirusTotal (0 detections as of September) indicates that the malware is essentially a cyberweapon used by a nation-state to attack civilian critical infrastructure—in this case, gasoline and fuel availability. IOCONTROL is IoT-specific code and leverages MQTT, a dedicated IoT communication channel to disguise traffic to and from the attackers’ command-and-control infrastructure. The CyberAv3ngers, meanwhile, have implicitly stated they will continue to target Israel-made technology in critical infrastructure. In October 2023, news surfaced that water treatment facilities in the U.S. and Israel were attacked by the group. Integrated Unitronics Vision series PLC/HMI devices were targeted inside these facilities; the attacks resulted in the defacement of these OT devices. The attacks were projections of power from the CyberAv3ngers, demonstrating their access to the devices and hoping to instill fear regarding the quality of water in affected areas. Around the same time of the attacks against water facilities, the CyberAv3ngers published on Telegram claims it had targeted 200 gas stations in Israel and the U.S., specifically targeting Orpak systems. The attackers released screenshots of the main management portal of the attacked gas stations, as well as databases of information about their targets and leaked data. A screenshot of the CyberAv3ngers Telegram channel where they discussed an attack against Orpak fuel management devices. DRAFT | Claroty Research - Team82 A screenshot shared on Telegram by CyberAv3ngers that shows they’d gained access to ORPAK SiteOmat fuel management systems. A dedicated CyberAv3ngers script running, and allegedly bricking, Orpak systems. Following up on the CyberAv3ngers’ claim of compromising Orpak systems, we found WHOIS records indicating registration of a domain name tylarion867mino[.]com on Nov. 23, 2023. 6Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved A DEDICATED CYBERAV3NGERS SCRIPT RUNNING, AND ALLEGEDLY BRICKING, ORPAK SYSTEMS. Following up on the CyberAv3ngers’ claim of compromising Orpak systems, we found WHOIS records indicating registration of a domain name tylarion867mino[.]com on Nov. 23, 2023. This domain would be used by the attackers to set up a command-and-control infrastructure in order to manage all the compromised devices. In December 2023, an Israeli-associated hacking group called Gonjeshke Darande claimed to have attacked and compromised 70% of Iran’s gas stations, claiming it was “in response to the aggression of the Islamic Republic and its proxies in the region.” While the reports about these attacks by CyberAv3ngers against Orpak devices span from mid-October 2023 to late January 2024, our team obtained a publicly available sample of IOCONTROL from VirusTotal, indicating the group relaunched their targeted campaign in July-August 2024. Our research blog presents our analysis of the attack against Orpak and Gasboy devices, the malware used in the attacks, and the attacker’s command and control infrastructure. DRAFT | Claroty Research - Team82 A screenshot shared on Telegram by CyberAv3ngers that shows they’d gained access to ORPAK SiteOmat fuel management systems. A dedicated CyberAv3ngers script running, and allegedly bricking, Orpak systems. Following up on the CyberAv3ngers’ claim of compromising Orpak systems, we found WHOIS records indicating registration of a domain name tylarion867mino[.]com on Nov. 23, 2023. https://www.cnbc.com/2023/12/18/pro-israel-hackers-claim-cyberattack-disrupting-irans-gas-stations.html https://www.cnbc.com/2023/12/18/pro-israel-hackers-claim-cyberattack-disrupting-irans-gas-stations.html https://x.com/darandegonjeshk/status/1736632264757264634 https://x.com/darandegonjeshk/status/1736632264757264634 7Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved ORPAK Systems Devices The sample we were able to obtain was extracted from a Gasboy fuel control system which has close ties with Orpak Systems. It is yet unclear the method used to deploy the malware on the affected victim systems, but it is speculated that a zero-day vulnerability may have been exploited to deploy the malware on compromised devices. Fuel control systems are complex platforms that consist of multiple subsystems including an outdoor payment terminal, printer (for receipts), pump and nozzle control, and additional peripherals such as management and billing software. IOCONTROL was hiding inside Gasboy’s Payment Terminal, called OrPT. Having full control on the payment terminal means that the attackers had the ability to shut down fuel services and potentially steal credit card information from customers. DRAFT | Claroty Research - Team82 This domain would be used by the attackers to set up a command-and-control infrastructure in order to manage all the compromised devices. In December 2023, an Israeli-associated hacking group called Gonjeshke Darande claimed to have attacked and compromised 70% of Iran’s gas stations, claiming it was “in response to the aggression of the Islamic Republic and its proxies in the region.” While the reports about these attacks by CyberAv3ngers against Orpak devices span from mid- October 2023 to late January 2024, our team obtained a publicly available sample from VirusTotal of IOCONTROL, indicating the group relaunched their targeted campaign in July- August 2024. Our research blog presents our analysis of the attack against Orpak and Gasboy devices, the malware used in the attacks, and the attacker’s command and control infrastructure. Victimology The sample we were able to obtain was extracted from a Gasboy fuel control system which has close ties with Orpak Systems. It is yet unclear the method used to deploy the malware on the affected victim systems, but it is speculated that a zero-day vulnerability may have been exploited to deploy the malware on compromised devices. Fuel control systems are complex platforms that consist of multiple subsystems including an outdoor payment terminal, printer (for receipts), pump and nozzle control, and additional peripherals such as management and billing software. A GASBOY Fuel System device (Source. ) A GASBOY FUEL SYSTEM DEVICE (SOURCE. ) FUEL CONTROL SYSTEMS ARE COMPLEX AND CONSIST OF MANY SUBSYSTEMS (SOURCE) https://www.gasboy.com/us/ https://www.orpak.com/ http://docs.gilbarco.com/gold/download.cfm?doc_id=8332 http://docs.gilbarco.com/gold/download.cfm?doc_id=1880 8Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved8 IOCONTROL Binary Analysis The IOCONTROL sample we analyzed targeted Orpak Fuel system devices. The hash of this sample is: 1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498.The sample included an internal GUID value used to identify a victim entity: 855958ce-6483-4953-8c18-3f9625d88c27. The sample we analyzed was compiled specifically for ARM-32 bit Big Endian architecture systems. Unpacking and Emulation of IOCONTROL Observing the malware sample in VirusTotal, there were zero detections in September in all of its sandbox engines; as of December, there were 21. VIRUSTOTAL DETECTION DASHBOARD FOR THE MALWARE SAMPLE. Knowing this made us extra cautious when handling the malware and analyzing its internals. We decided to start analyzing the malware using a static approach. This approach led us to the conclusion that an in-memory unpacking procedure ran when the malware was executed. Static analysis took far too long and too much effort, therefore we decided to pivot our efforts toward dynamic analysis of the malware sample. This meant we were going to have to execute the malware sample safely and debug it. The approach we took to execute and unpack the malware executable was emulation, specifically using the Python-based Unicorn CPU emulation engine. We decided to go down this path because of two reasons: 1. The malware sample was written for an archaic ARM 32-bit BE CPU architecture, which made emulation the best candidate for a solution to execute and unpack the malware sample. 2. We needed to find a way to execute the malware in a safe and controlled environment that would not potentially infect our setup or perform malicious activity on our systems. Unicorn gave us more granular control over the emulation than other engines such as QEMU; it not only allowed us to carefully inspect the malware execution flow, but also allowed us to have full control over the capabilities of the malware with regards to syscall invocations and OS interactions. Emulating the sample was a gradual process in which we closely inspected the execution flow of the malware. This included tracing the executed code and saving memory mappings along each emulation round. In the beginning, each round of emulation was terminated abruptly, shortly after initiating the execution of the sample. This was caused most often upon an attempt to invoke a syscall for OS interaction by the malware. Unicorn provides the capability to execute emulated CPU instructions in various architectures and variations. DRAFT | Claroty Research - Team82 IOCONTROL Binary Analysis The IOCONTROL sample we analyzed targeted Orpak Fuel system devices. The hash of this sample is: 1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498. The sample included an internal GUID value used to identify a victim entity: 855958ce-6483- 4953-8c18-3f9625d88c27. The sample was compiled specifically for ARM-32 bit Big Endian architecture systems. Unpacking and Emulation of IOCONTROL Observing the malware sample in VirusTotal, we noticed that it has zero detections in all of its sandbox engines. VirusTotal detection dashboard for the malware sample. Knowing this made us extra cautious when handling the malware and analyzing its internals. We decided to start analyzing the malware using a static analysis approach. This approach led us to the conclusion that an in-memory unpacking procedure ran when the malware was executed. Static analysis took far too long and too much effort, therefore we decided to pivot our efforts towards dynamic analysis of the malware sample. This meant we were going to have to execute the malware sample safely and debug it. The approach we took to execute and unpack the malware executable was emulation, specifically using the Python-based Unicorn CPU emulation engine. We decided to go in this path because of two reasons: 1. The malware sample was written for an archaic ARM 32-bit BE CPU architecture, which made emulation the best candidate for a solution to execute and unpack the malware sample. 2. We needed to find a way to execute the malware in a safe and controlled environment that would not potentially infect our setup or perform malicious activity on our systems. https://www.unicorn-engine.org/ https://www.qemu.org/ 9Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Yet it doesn’t facilitate specific OS infrastructure such as syscall implementations of specific operating systems such as Linux or Windows. Each time we encountered a specific syscall invocation attempt, we tried to understand its purpose and implemented our own version of the syscall that enabled the execution to continue together with ensuring the interaction is safe and will not harm our testing environment. For example, when the executable invokes the open and read syscalls to read a file from the filesystem, our instruction execution hook will trigger and handle these calls. In this case, when an open syscall is invoked, our hook returns a fake fd value to identify the requested file. When triggered on a read syscall, we supply our own defined content we control. Doing so allows us to have fine grained access to the malware code flow. A CODE SNIPPET FROM THE PYTHON EMULATION MODULE SHOWING OPEN, READ, AND SYSCALL IMPLEMENTATIONS. The in-memory unpacking procedure was done in two stages during the malware execution. The first stage consisted of unpacking utility code routines into a newly mapped memory segment. The second stage consisted of unpacking the artifacts of the malware, which were the main executable module and the configuration of the malware into an appropriate memory location. During one of our emulation iterations, our execution flow started to execute on a newly mapped memory segment. This meant that this memory segment had an unpacked artifact. Inspecting a memory snapshot of that segment led to our speculation that the malware was using an open-source packer solution called UPX that may have been modified specifically for this malware sample. The triggering element leading to this suspicion was a byte sequence left by the malware developers untouched in an unpacked artifact of the malware: “!XPU” which is the little endian version of “UPX!”. This misstep by the attackers helped us to quickly identify UPX as the packer. DRAFT | Claroty Research - Team82 A code snippet from the Python emulation module showing open, read, and syscall implementations. The in-memory unpacking procedure was done in two stages during the malware execution. The first stage consisted of unpacking utility code routines into a newly mapped memory segment. The second stage consisted of unpacking the artifacts of the malware, which were the main executable module and the configuration of the malware into an appropriate memory location. During one of our emulation iterations, our execution flow started to execute on a newly mapped memory segment. This meant that this memory segment had an unpacked artifact. Inspecting a memory snapshot of that segment led to our speculation that the malware was using an open- source packer solution called UPX that may have been modified specifically for this malware sample. The triggering element leading to this suspicion was a byte sequence left by the malware developers untouched in an unpacked artifact of the malware: “!XPU” which is the little endian version of “UPX!”. This misstep by the attackers helped us to quickly identify UPX as the packer. https://upx.github.io/ 10Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved A SNAPSHOT FROM THE UNPACKED ARTIFACT CONTAINING A SUSPICIOUS LITTLE ENDIAN REPRESENTATION OF THE UPX MAGIC HEADER VALUE. Just for the sake of research after we had the unpacked version of the malware, we used the benign UPX tool to pack it and compared it to the original sample. We noticed some difference in locations where UPX-related features were supposed to be placed, such as the magic UPX! string of bytes which was changed to ABC!. BINARY DIFFING THE ORIGINAL MALWARE SAMPLE (LEFT SEGMENT) TO THE UPX PACKED ARTIFACT (RIGHT). To further support this conclusion we compiled a version of UPX that ignores CRC checksum verification and patched the sample ABC byte sequences with UPX byte sequences, allowing us to successfully unpack the malware sample. Our assumption is that the attackers deployed this malware that way because they were trying to evade detection and hide their malicious implant and configuration in a stable and quick way. This was apparently somewhat effective with regard to staying undetected by automated detection engines but wasn’t very sophisticated. DRAFT | Claroty Research - Team82 A snapshot from the unpacked artifact containing a suspicious little endian representation of the UPX magic header value. Just for the sake of research after we had the unpacked version of the malware, we used the benign UPX tool to pack it and compared it to the original sample. We noticed some difference in locations where UPX-related features were supposed to be placed, such as the magic UPX! string of bytes which was changed to ABC!. Binary diffing the original malware sample (left Segment) to the UPX packed artifact (right). DRAFT | Claroty Research - Team82 A snapshot from the unpacked artifact containing a suspicious little endian representation of the UPX magic header value. Just for the sake of research after we had the unpacked version of the malware, we used the benign UPX tool to pack it and compared it to the original sample. We noticed some difference in locations where UPX-related features were supposed to be placed, such as the magic UPX! string of bytes which was changed to ABC!. Binary diffing the original malware sample (left Segment) to the UPX packed artifact (right). 11Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Decrypting IOCONTROL’s Configuration After unpacking the malware successfully, we were left with two artifacts: an encrypted data section and an executable. When examining the executable in IDA, we noticed that in many different locations in the code, it uses data from the encrypted section, using it for different operations such as a path for a file, IP address to connect to, etc. THE MALWARE READS AN HOSTNAME/PORT PAIR FROM ITS CONFIGURATION, AND USES IT TO CONNECT TO AN MQTT BROKER. We managed to discover that this encrypted section was in fact the encrypted configuration of the malware. Each encrypted configuration entry is composed of 150 bytes: 1 byte of length (the length of the encrypted data, up to 149), and up to 149 bytes of encrypted data. In order to decrypt the configuration of the malware, it uses a decryption function, which receives an index specifying which configuration it wants decrypted from a list. This technique allows minimizing the possibility of extracting decrypted configuration entries from the process memory during the malware runtime. In this decryption function, the malware fetches the first byte from the encrypted configuration entry. This value is used to tell how long that specific encrypted configuration entry is, after reading the encrypted entry raw bytes, the malware uses AES-256-CBC decryption scheme to extract the actual configuration entry. THE CONFIGURATION DECRYPTION ROUTINE, TAKING THE KEY/IV PAIR FROM ENVIRONMENT VARIABLES. DRAFT | Claroty Research - Team82 To further support this conclusion we compiled a version of UPX that ignores CRC checksum verification and patched the sample ABC byte sequences with UPX byte sequences, allowing us to successfully unpack the malware sample. Our assumption is that the attackers deployed this malware that way because they were trying to evade detection and hide their malicious implant and configuration in a stable and quick way. This was apparently somewhat effective with regard to staying undetected by automated detection engines but wasn’t very sophisticated. Decrypting the Configuration After unpacking the malware successfully, we were left with two artifacts: an encrypted data section and an executable. When examining the executable in IDA, we noticed that in many different locations in the code, it uses data from the encrypted section, using it for different operations such as a path for a file, IP address to connect to, etc. The malware reads an hostname/port pair from its configuration, and uses it to connect to an MQTT broker. We managed to discover that this encrypted section was in fact the encrypted configuration of the malware. Each encrypted configuration entry is composed of 150 bytes: 1 byte of length (the length of the encrypted data, up to 149), and up to 149 bytes of encrypted data. In order to decrypt the configuration of the malware, it uses a decryption function, which receives an index specifying which configuration it wants decrypted from a list. This technique allows minimizing the possibility of extracting decrypted configuration entries from the process memory during the malware runtime. In this decryption function, the malware fetches the first byte from the encrypted configuration entry. This value is used to tell how long that specific encrypted configuration entry is, after reading the encrypted entry raw bytes, the malware uses AES-256-CBC decryption scheme to extract the actual configuration entry. DRAFT | Claroty Research - Team82 The configuration decryption routine, taking the key/IV pair from environment variables. Prior to decryption, the malware extracts the key and IV pair from a GUID stored in one of its strings, which the malware uses for many purposes. The extracted key and IV are used for decryption and get stored in environment variables 0_0 and 0_1 respectively. The key generation routine, performing hash and string operations on a hardcoded GUID. As we can see, the malware takes the GUID stored in its memory (855958ce-6483-4953- 8c18-3f9625d88c27), and uses SHA256 to hash it. The key for the AES-256-CBC encryption is simply the hash of the GUID (22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e) as a hex string. This is probably a mistake by the attackers, who got confused, since AES-256 uses a 32-byte size for its keys, however they used a 64-hex-string instead. Because the given key is bigger than the key size, only the first 32 bytes will actually be used by the AES-256-CBC 12Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Prior to decryption, the malware extracts the key and IV pair from a GUID stored in one of its strings, which the malware uses for many purposes. The extracted key and IV are used for decryption and get stored in environment variables 0_0 and 0_1 respectively. THE KEY GENERATION ROUTINE, PERFORMING HASH AND STRING OPERATIONS ON A HARDCODED GUID. As we can see, the malware takes the GUID stored in its memory (855958ce-6483-4953-8c18- 3f9625d88c27), and uses SHA256 to hash it. The key for the AES-256-CBC encryption is simply the hash of the GUID (22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e) as a hex string. This is probably a mistake by the attackers, who got confused, since AES-256 uses a 32-byte size for its keys, however they used a 64-hex-string instead. Because the given key is bigger than the key size, only the first 32 bytes will actually be used by the AES-256-CBC process. The IV used for encryption is a substring from that hash (from index 31 to index 63). Once again the IV is too long, so only the first 16 bytes are used. Our assumption is that the attackers are using unique GUIDs which get inserted by binary patching malware samples to distinguish between different victims and/or campaigns. This is further supported by the fact that the malware derives most of its parameters from the seed GUID which can be easily changed without recompiling the malware by binary patching the string. Furthermore, the malware uses IoT vendor identifiers. For example, in our sample we noticed the name Orpak in the decrypted configuration which identifies the vendor manufacturing the embedded device that was attacked. DRAFT | Claroty Research - Team82 The configuration decryption routine, taking the key/IV pair from environment variables. Prior to decryption, the malware extracts the key and IV pair from a GUID stored in one of its strings, which the malware uses for many purposes. The extracted key and IV are used for decryption and get stored in environment variables 0_0 and 0_1 respectively. The key generation routine, performing hash and string operations on a hardcoded GUID. As we can see, the malware takes the GUID stored in its memory (855958ce-6483-4953- 8c18-3f9625d88c27), and uses SHA256 to hash it. The key for the AES-256-CBC encryption is simply the hash of the GUID (22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e) as a hex string. This is probably a mistake by the attackers, who got confused, since AES-256 uses a 32-byte size for its keys, however they used a 64-hex-string instead. Because the given key is bigger than the key size, only the first 32 bytes will actually be used by the AES-256-CBC 13Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved To summarize, here are the environment variables used by the malware, as well as how they are used and how they are generated: After extracting the AES-256-CBC key and IV pair, we decrypted the entire encrypted section holding the various configuration entries, and examined each configuration entry the malware uses. Environment Variable Value Derived by Used for GUID (not environment variable) 855958ce-6483-4953- 8c18-3f9625d88c27 Hardcoded Generating identifiers for the malware 0_0 22e70a3056aa209e90 dc5a354edda2c1c3b8 8f1e4720dc6a090c46 17a919447e SHA256(GUID) AES-256-CBC key to decrypt the config 0_1 1c3b88f1e4720dc6a0 90c4617a919447 SHA256(GUID)[31:63] AES-256-CBC key IV decrypt the config 1 1.0.5 Hardcoded Malware version 3 5958ce GUID[2:8] Value to tell the malware to self delete. Also used as MQTT username 4 3-4953-8c18-3f9625 GUID[12:30] Also used as MQTT password 14Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved A PARTIAL LIST OF THE CONFIGURATIONS USED BY THE MALWARE. Resolving IOCONTROL Command-and-Control via DoH With the configurations in hand, we moved on to analyze the malware behavior. One thing that piqued our interest immediately was the DNS name stored in the first configuration: uuokhhfsdlk[.]tylarion867mino[.]com. At the time of writing this report, the domain C2 address is resolving to IP address 159[.]100[.]6[.]69. Following the malware execution flow, we discovered that indeed this is the hostname used by the malware to communicate with its C2. First, the malware uses Cloudflare’s servers to translate the hostname into an IP address. In order to evade detection, the malware does not use DNS to translate this hostname directly, instead it uses DNS over HTTPS (DoH) to translate it via CloudFlare’s API. This is a stealth technique used by malware to avoid being detected by sending a clear-text DNS request, showcasing which DNS names they communicate with. Instead, they used an encrypted protocol (HTTPS), meaning that even if a network tap exists, the traffic is encrypted so they won’t be discovered. DRAFT | Claroty Research - Team82 A partial list of the configurations used by the malware. Resolving IOCONTROL Command-and-Control via DoH With the configurations in hand, we moved on to analyze the malware behavior. One thing that piqued our interest immediately was the DNS name stored in the first configuration: uuokhhfsdlk[.]tylarion867mino[.]com. At the time of writing this report, the domain C2 address is resolving to IP address 159[.]100[.]6[.]69. Following the malware execution flow, we discovered that indeed this is the hostname used by the malware to communicate with its C2. First, the malware uses Cloudflare’s servers to translate the hostname into an IP address. In order to evade detection, the malware does not use DNS to translate this hostname directly, instead it uses DNS over HTTPS to translate it via CloudFlare’s API. This is a stealth technique used by malware to avoid being detected by sending a clear-text DNS request, showcasing https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/ 15Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved A REQUEST TO CLOUDFLARE’S SERVERS, QUERYING THE ATTACKER’S C2 HOSTNAME. THE ROUTINE HANDLING DNS OVER HTTPS TRANSLATION OF THE MALWARE’S C2 HOSTNAME. Persistence Before connecting to the C2 infrastructure, the malware first installs a backdoor on the device in order to ensure its persistence. To do so, the malware adds a new rc3.d boot script, which will be executed whenever the device restarts. The backdoor is located in /etc/rc3.d/S93InitSystemd.sh, contains the following bash script: In addition to this backdoor, the malware is stored under the name iocontrol in the /usr/bin directory. DRAFT | Claroty Research - Team82 which DNS names they communicate with. Instead, they used an encrypted protocol (HTTPS), meaning that even if a network tap exists, the traffic is encrypted so they won’t be discovered. ~ curl --http2 --header "accept: application/dns-json" "https://1.1.1.1/dns-query?name=uuokhhfsdlk[.]tylarion867mino[.]com" { "Status": 0, "TC": false, "RD": true, "RA": true, "AD": false, "CD": false, "Question": [ { "name": "uuokhhfsdlk[.]tylarion867mino[.]com", "type": 1 } ], "Answer": [ { "name": "uuokhhfsdlk[.]tylarion867mino[.]com", "type": 1, "TTL": 300, "data": "159[.]100[.]6[.]69" } ] } A request to Cloudflare’s servers, querying the attacker’s C2 hostname. The routine handling DNS over HTTPS translation of the malware’s C2 hostname. DRAFT | Claroty Research - Team82 Persistence Before connecting to the C2 infrastructure, the malware first installs a backdoor on the device in order to ensure its persistence. To do so, the malware adds a new rc3.d boot script, which will be executed whenever the device restarts. The backdoor is located in /etc/rc3.d/S93InitSystemd.sh, contains the following bash script: trap "rm -f $iocpid" EXIT while true; do if ! pidof "iocontrol" > /dev/null; then iocontrol >/dev/null 2>&1 & fi sleep 5 done In addition to this backdoor, the malware is stored under the name iocontrol in the /usr/bin directory. Communication with C2 via MQTT After translating this hostname into IP address, the malware takes the second configuration parameter: 8883, and uses it as the port to connect to the C2. Port 8883 is usually used by the MQTTs communication protocol, and when examining the code further we indeed saw that the malware indeed communicates over this port.. The malware constructs an MQTT CONNECT packet, initiating its MQTTs connection to the C2. DRAFT | Claroty Research - Team82 which DNS names they communicate with. Instead, they used an encrypted protocol (HTTPS), meaning that even if a network tap exists, the traffic is encrypted so they won’t be discovered. ~ curl --http2 --header "accept: application/dns-json" "https://1.1.1.1/dns-query?name=uuokhhfsdlk[.]tylarion867mino[.]com" { "Status": 0, "TC": false, "RD": true, "RA": true, "AD": false, "CD": false, "Question": [ { "name": "uuokhhfsdlk[.]tylarion867mino[.]com", "type": 1 } ], "Answer": [ { "name": "uuokhhfsdlk[.]tylarion867mino[.]com", "type": 1, "TTL": 300, "data": "159[.]100[.]6[.]69" } ] } A request to Cloudflare’s servers, querying the attacker’s C2 hostname. The routine handling DNS over HTTPS translation of the malware’s C2 hostname. 16Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Communication with C2 via MQTT After translating this hostname into IP address, the malware takes the second configuration parameter: 8883, and uses it as the port to connect to the C2. Port 8883 is usually used by the MQTTs communication protocol, and when examining the code further we indeed saw that the malware communicates over this port. THE MALWARE CONSTRUCTS AN MQTT CONNECT PACKET, INITIATING ITS MQTTS CONNECTION TO THE C2. MQTT Protocol The MQTT protocol is a publish-subscribe network protocol that transports messages between devices. It’s designed for use in environments where network bandwidth is limited or unreliable, making it particularly well-suited for internet of things (IoT) applications. For these reasons and being a bit more stealthy we believe the attackers decided to use the MQTT protocol for their C2 communications. In order to connect, the malware uses MQTT 4.0, sending the C2 three different identifiers: Client ID, Username, Password. For the Client ID, the malware uses the GUID stored in its memory, the username is the environment variable 3 (derived from the GUID), and the password is the environment variable 4 (also derived from the GUID). Using these identifiers, the malware authenticates to the MQTT broker. A RECONSTRUCTION OF THE MALWARE’S MQTT CONNECT MESSAGE. After connecting to the MQTT broker, the malware immediately publishes an “hello” message to the following topic: {GUID}/hello. This message informs the C2 of a new connection, and sends a lot of identification information about the infected device. In its hello message, the malware sends a JSON with this information: DRAFT | Claroty Research - Team82 Persistence Before connecting to the C2 infrastructure, the malware first installs a backdoor on the device in order to ensure its persistence. To do so, the malware adds a new rc3.d boot script, which will be executed whenever the device restarts. The backdoor is located in /etc/rc3.d/S93InitSystemd.sh, contains the following bash script: trap "rm -f $iocpid" EXIT while true; do if ! pidof "iocontrol" > /dev/null; then iocontrol >/dev/null 2>&1 & fi sleep 5 done In addition to this backdoor, the malware is stored under the name iocontrol in the /usr/bin directory. Communication with C2 via MQTT After translating this hostname into IP address, the malware takes the second configuration parameter: 8883, and uses it as the port to connect to the C2. Port 8883 is usually used by the MQTTs communication protocol, and when examining the code further we indeed saw that the malware indeed communicates over this port.. The malware constructs an MQTT CONNECT packet, initiating its MQTTs connection to the C2. DRAFT | Claroty Research - Team82 MQTT Protocol The MQTT protocol is a publish-subscribe network protocol that transports messages between devices. It's designed for use in environments where network bandwidth is limited or unreliable, making it particularly well-suited for internet of things (IoT) applications. For these reasons and being a bit more stealthy we believe the attackers decided to use the MQTT protocol for their C2 communications. In order to connect, the malware uses MQTT 4.0, sending the C2 three different identifiers: Client ID, Username, Password. For the Client ID, the malware uses the GUID stored in its memory, the username is the environment variable 3 (derived from the GUID), and the password is the environment variable 4 (also derived from the GUID). Using these identifiers, the malware authenticates to the MQTT broker. A reconstruction of the malware’s MQTT connect message. After connecting to the MQTT broker, the malware immediately publishes an “hello” message to the following topic: {GUID}/hello. This message informs the C2 of a new connection, and sends a lot of identification information about the infected device. In its hello message, the malware sends a JSON with this information: { "hostname": "HOSTNAME", "current_user": "CURRENT_USER", 17Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved In order to get this information (for example, the current user, hostname etc), the malware uses OS commands. In this process, the malware gets a handle to the libc library by calling dlopen with the parameter libc.so.6. Then, using this handle, the malware gets the pointer to the system function using dlsym, giving it the function name system, and lastly uses this pointer to execute the OS commands it needs. THE MALWARE’S METHOD OF PERFORMING SYSTEM COMMANDS. For each OS command the malware executes, it constructs the following command: As part of the hello message, the malware executes the following OS commands in this order: After sending the hello message, the malware subscribes to the MQTT topic {GUID}/push. Using this topic, the C2 sends the malware commands for execution, which the malware executes inside the callback routine that is called whenever a MQTT message is received. DRAFT | Claroty Research - Team82 MQTT Protocol The MQTT protocol is a publish-subscribe network protocol that transports messages between devices. It's designed for use in environments where network bandwidth is limited or unreliable, making it particularly well-suited for internet of things (IoT) applications. For these reasons and being a bit more stealthy we believe the attackers decided to use the MQTT protocol for their C2 communications. In order to connect, the malware uses MQTT 4.0, sending the C2 three different identifiers: Client ID, Username, Password. For the Client ID, the malware uses the GUID stored in its memory, the username is the environment variable 3 (derived from the GUID), and the password is the environment variable 4 (also derived from the GUID). Using these identifiers, the malware authenticates to the MQTT broker. A reconstruction of the malware’s MQTT connect message. After connecting to the MQTT broker, the malware immediately publishes an “hello” message to the following topic: {GUID}/hello. This message informs the C2 of a new connection, and sends a lot of identification information about the infected device. In its hello message, the malware sends a JSON with this information: { "hostname": "HOSTNAME", "current_user": "CURRENT_USER", DRAFT | Claroty Research - Team82 "device_name": "DEVICE_NAME", "device_model": "DEVICE_MODEL", "timezone": "TIMEZONE", "firmware_version": "FIRMWARE_VERSION", "geo_location": "GEO_LOCATION", "version": "MALWARE_VERSION" } In order to get this information (for example, the current user, hostname etc), the malware uses OS commands. In this process, the malware gets a handle to the libc library by calling dlopen with the parameter libc.so.6. Then, using this handle, the malware gets the pointer to the system function using dlsym, giving it the function name system, and lastly uses this pointer to execute the OS commands it needs. The malware’s method of performing system commands. For each OS command the malware executes, it constructs the following command: OS_COMMAND > /tmp/{RANDOM_16_chars}.txt 2>&1 As part of the hello message, the malware executes the following OS commands in this order: DRAFT | Claroty Research - Team82 "device_name": "DEVICE_NAME", "device_model": "DEVICE_MODEL", "timezone": "TIMEZONE", "firmware_version": "FIRMWARE_VERSION", "geo_location": "GEO_LOCATION", "version": "MALWARE_VERSION" } In order to get this information (for example, the current user, hostname etc), the malware uses OS commands. In this process, the malware gets a handle to the libc library by calling dlopen with the parameter libc.so.6. Then, using this handle, the malware gets the pointer to the system function using dlsym, giving it the function name system, and lastly uses this pointer to execute the OS commands it needs. The malware’s method of performing system commands. For each OS command the malware executes, it constructs the following command: OS_COMMAND > /tmp/{RANDOM_16_chars}.txt 2>&1 As part of the hello message, the malware executes the following OS commands in this order: DRAFT | Claroty Research - Team82 "device_name": "DEVICE_NAME", "device_model": "DEVICE_MODEL", "timezone": "TIMEZONE", "firmware_version": "FIRMWARE_VERSION", "geo_location": "GEO_LOCATION", "version": "MALWARE_VERSION" } In order to get this information (for example, the current user, hostname etc), the malware uses OS commands. In this process, the malware gets a handle to the libc library by calling dlopen with the parameter libc.so.6. Then, using this handle, the malware gets the pointer to the system function using dlsym, giving it the function name system, and lastly uses this pointer to execute the OS commands it needs. The malware’s method of performing system commands. For each OS command the malware executes, it constructs the following command: OS_COMMAND > /tmp/{RANDOM_16_chars}.txt 2>&1 As part of the hello message, the malware executes the following OS commands in this order: DRAFT | Claroty Research - Team82 uname -v > /tmp/{RANDOM_16_chars}.txt 2>&1 hostname > /tmp/{RANDOM_16_chars}.txt 2>&1 whoami > /tmp/{RANDOM_16_chars}.txt 2>&1 date +%Z > /tmp/{RANDOM_16_chars}.txt 2>&1 uname -r > /tmp/{RANDOM_16_chars}.txt 2>&1 After sending the hello message, the malware subscribes to the MQTT topic {GUID}/push. Using this topic, the C2 sends the malware commands for execution, which the malware executes inside the callback routine that is called whenever a MQTT message is received. Supported Commands In this routine, the malware parses the received message and extracts the command the malware has sent. Each command from the C2 is one of five different types, each identified by a different opcode: Opcode Command Description 0 Send “hello” Resend the MQTT hello message with basic device information 1 Check exec Check that the malware is installed in /usr/bin/iocontrol and that it is executable, and publishes the string 1:1 2 Execute command Execute arbitrary OS command via system call and publishes the output 3 Self-delete Stop the malware execution, as well as remove malware main binary, its persistence service, and related logs files. It then publishes the string 3:1 8 Port scan Scan an IP range in a specific port. The malware receives IP start, IP end and a port to scan. It then publishes the result. After finishing the command execution, the malware publishes the response using the {GUID}/output topic. IOCONTROL Flow: Simplified 18Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Supported Commands In this routine, the malware parses the received message and extracts the command the malware has sent. Each command from the C2 is one of five different types, each identified by a different opcode: After finishing the command execution, the malware publishes the response using the {GUID}/output topic. Opcode Command Description 0 Send “hello” Resend the MQTT hello message with basic device information 1 Check exec Check that the malware is installed in /usr/bin/ iocontrol and that it is executable, and publishes the string 1:1 2 Execute command Execute arbitrary OS command via system call and publishes the output 3 Self-delete Stop the malware execution, as well as remove malware main binary, its persistence service, and related logs files. It then publishes the string 3:1 8 Port scan Scan an IP range in a specific port. The malware receives IP start, IP end and a port to scan. It then publishes the result. 19Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved IOCONTROL Flow: Simplified Main Function Decrypt & init params Install service? (persistency) MQTT connect Send MQTT “hello” Subscribe to MQTT topic/push MQTT loop - process commands Cleanup & quit Yes No Cleanup & quit Should suicide? Command 0: send “hello” Command 1: verify exec Command 2: system command Command 3: suicide Command 8: port scan 20Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved IOCONTROL Infrastructure The malware’s C2 domain is uuokhhfsdlk[.]tylarion867mino[.]com, which resolved to 159[.]100[.]6[.]69 IOC Country Verdict Description Type 159[.]100[.]6[.]69 GER Malicious C2 from IOCONTROL. Services: MQTT 1883/TCP MQTT 8883/TCP HTTP 15672/TCP IP Address uuokhhfsdlk[.] tylarion867mino[.]com GER Malicious Domain found in IOCONTROL. Communication over MQTT on port 8883. Domain ocferda[.]com — Malicious Older DNS records, from around 2023, show that the domain ocferda[.]com was in use and pointed to the same IP address of the C2 159[.]100[.]6[.]69 Domain 21Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Domain The C2 domain tylarion867mino[.]com was registered on Nov. 23rd, 2023. This domain was used by the attackers to set up a C2 infrastructure, allowing them to command and control all devices they infect. THE WHOIS RECORD FOR THE ATTACKER’S C2 DOMAIN NAME. The C2 domain address was resolved to 159[.]100[.]6[.]69 at the time of writing this report. This address was hosted in Germany and had MQTT services running on ports 1883 and 8883 and RabbitMQ Management Server running on port 15672. Communications to the C2 server on port 8883 can be either victims reporting to C2 or an operator accessing the server. Older DNS records, from around 2023, show that the domain ocferda[.]com was in use and pointed to the same IP address of the C2 159[.]100[.]6[.]69. Summary Our analysis shows that the IOCONTROL malware is based on a generic OT/IoT malware framework for embedded Linux-based devices that is utilized and compiled against specific targets as needed. The malware communicates with a C2 over a secure MQTT channel and supports basic commands including arbitrary code execution, self-delete, port scan and more. This functionality is enough to control remote IoT devices and perform lateral movement if needed. In addition, IOCONTROL has a basic persistence mechanism over a daemon installation and stealth mechanism, for example the initial payload uses modified UPX packing and the malware uses DNS over HTTPS to hide its C2 infrastructure as much as possible. This specific sample was extracted from a Gasboy/ORPAK device which is a fuel system platform. However, IOCONTROL was used to attack IoT and SCADA devices of various types, including IP cameras, routers, PLCs, HMIs, firewalls, and more from different vendors such as Baicells, D-Link, Hikivision, Red Lion, Orpak, Phoenix Contact, Teltonika, Unitronics, and others. DRAFT | Claroty Research - Team82 The Whois record for the attacker’s C2 domain name. The C2 domain address was resolved to 159[.]100[.]6[.]69 at the time of writing this report. This address was hosted in Germany 🇩🇩🇩🇩 and had MQTT services running on ports 1883 and 8883 and RabbitMQ Management Server running on port 15672. Communications to the C2 server on port 8883 can be either victims reporting to C2 or an operator accessing the server. Summary Our analysis shows that the IOCONTROL malware is based on a generic IoT malware framework for embedded Linux devices that is utilized and compiled against specific targets as needed. The malware communicates with a C2 over a secure MQTT channel and supports basic commands including arbitrary code execution, self-delete, port scan and more. This functionality is enough to control remote IoT devices and perform lateral movement if needed. In addition, IOCONTROL has a basic persistence mechanism over a daemon installation and stealth mechanism, for example the initial payload uses modified UPX packing and the malware uses DNS over HTTPS to hide its C2 infrastructure as much as possible. This specific sample was extracted from a Gasboy/ORPAK device which is a fuel system platform. However, based on the above and the fact that we are seeing Orpak strings in its 22Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved IOC Description Type 159[.]100[.]6[.]69 C2 from IOCONTROL. IP Address uuokhhfsdlk[.] tylarion867mino[.]com Domain found in IOCONTROL. Communication over MQTTs on port 8883. Domain 1b39f9b2b96a6586c4a11ab2fd bff8fdf16ba5a0ac7603149023 d73f33b84498 IOCONTROL Initial sample Link to VT Hash /usr/bin/iocontrol IOCONTROL Initial sample Link to VT Bin /etc/rc3.d/S93InitSystemd. sh Malware service path Path ORPAK IoT device vendor String 855958ce-6483-4953-8c18- 3f9625d88c27 Seed GUID used for decryption and MQTT connection in the sample we researched GUID 1.0.5 Malware version String IOCONTROL Indicators of Compromise (IoC) https://www.virustotal.com/gui/file/1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498/details 23Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Appendix #1 - Environment Variables (post processing) Environment Variable Value Derived by Used for GUID (not environment variable) 855958ce-6483-4953- 8c18-3f9625d88c27 Hardcoded Generating identifiers for the malware 0_0 22e70a3056aa209e90 dc5a354edda2c1c3b8 8f1e4720dc6a090c46 17a919447e SHA256(GUID) AES-256-CBC key to decrypt the config 0_1 1c3b88f1e4720dc6a0 90c4617a919447 SHA256(GUID)[31:63] AES-256-CBC key IV decrypt the config 1 1.0.5 Hardcoded Malware version 3 5958ce GUID[2:8] Value to tell the malware to self delete. Also used as MQTT username 4 3-4953-8c18-3f9625 GUID[12:30] Also used as MQTT password 24Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved Appendix #2 - Decrypted Config ID Data Description 0 uuokhhfsdlk[.]tylarion867mino[.]com C2 host (as of Sept 8th resolves to 159[.]100[.]6.69 Frankfurt, Germany) 1 8883 MQTT Secure port 2 XXFrxHMDI1CqmIN5 Currently unknown - maybe previously used username 3 sCgcVpkXixEUTgEJqY708N5w2c42Ds sIEutp7ZIeNgt17G78iy Currently unknown - maybe previously used password 4 /hello MQTT topic to send device info 5 accept: application/dns-json HTTP Header required by CloudFlare to make DNS over HTTPS (DoH) requests https://developers.cloudflare.com/ 1.1.1.1/encryption/dns-over-https/ make-api-requests/ 6 /output MQTT topic to send command output 7 /push MQTT Topic to receive commands 8 GET HTTP method GET 9 POST HTTP method POST 10 1:01 Reports that the binary is executable via MQTT 11 3:01 Report self-delete via MQTT 25Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved 12 whoami Command whoami 13 hostname Command hostname 14 current_user JSON key current_user 15 device_name JSON key device_name 16 device_model JSON key device_model 17 timezone JSON key 18 firmware_version JSON key firmware_version 19 geo_location JSON key geo_location 20 output JSON key output 21 params 22 code 23 ORPAK Vendor name - ORPAK 24 data Cloudflare DoH JSON response key data - where the IP is resolved {“Status”:0,”TC”:false,”RD”:true, “RA”:true,”AD”:false,”CD”:false, “Question”:[{“name”:”uuokhhfsdlk. tylarion867mino.com”,”type”:1}], “Answer”:[{“name”:”uuokhhfsdlk. tylarion867mino.com”,”type”:1, “TTL”:300,”data”:”159.100.6.69”}]} 26Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved 25 Answer Cloudflare DoH JSON response Answer data - the DNS response {“Status”:0,”TC”:false,”RD”:true, “RA”:true,”AD”:false,”CD”:false, “Question”:[{“name”:”uuokhhfsdlk. tylarion867mino.com”,”type”:1}], “Answer”:[{“name”:”uuokhhfsdlk. tylarion867mino.com”,”type”:1, “TTL”:300,”data”:”159.100.6.69”}]} 26 1.1.1.1:443/dns-query?name= URL to resolve DNS over HTTPS (DoH) https://developers.cloudflare.com/1.1.1.1/ encryption/dns-over-https/make-api- requests/ curl --http2 --header “accept: application/ dns-json” “https://1.1.1.1/dns-query?name=google.com 27 /dev/urandom Linux path to get random data 28 /tmp/ Linux path for /tmp 29 .txt Suffix .txt 30 2>&1 Linux bash syntax to redirect stderr to stdout 31 > /dev/null 2>&1 & Linux bash syntax to redirect both stderr and stdout to /dev/null and run the entire process in the background 32 version JSON key sent in MQTT hello 33 date +%Z Command date 27Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved 34 %Y/%m/%d %H:%M:%S Date format 35 ptrace ptrace function to debug 36 system System function to execute code given a remote command 37 libc.so.6 libc library 38 /tmp/iocontrol/ Malware path for temporary files 39 /tmp/iocontrol.log Malware log path 40 iocontrol Malware name - iocontrol 41 /etc/rc3.d/S93InitSystemd.sh Malware path for its daemon/service (persistency) - this will run the malware upon boot 42 uname -v Command uname -v uname -v > /tmp/{RANDOM_16_chars}.txt 2>&1 43 uname -r Command uname -r 44 #!/bin/sh iocpid=/var/run/iocontrol.pid if [ -f “$iocpid” ] && kill -0 $(cat “$iocpid”) 2>/dev/null; then exit 1 fi echo $$ > “$iocpid” Bash script deployed by the malware to stop the running instance 45 /usr/bin/iocontrol Malware full path location 28Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved 46 /etc/rc3.d/ Linux path for system daemons/services - this is where the init script for running the malware is located 47 trap “rm -f $iocpid” EXIT while true; do if ! pidof “iocontrol” > /dev/null; then iocontrol >/dev/null 2>&1 & fi sleep 5 done Bash script deployed by the malware to make sure it’s running - watchdog 29Inside a New Cyber Weapon: IOCONTROL ©Copyright Claroty Ltd. All rights reserved29