{
	"id": "86ea9078-8fbd-47dc-9e46-cf86947f9398",
	"created_at": "2026-04-06T00:14:58.965734Z",
	"updated_at": "2026-04-10T03:35:19.884493Z",
	"deleted_at": null,
	"sha1_hash": "00910170047c8ea0d169602b2e5ada04394a3984",
	"title": "Inside a New OT/IoT Cyberweapon: IOCONTROL",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 7176734,
	"plain_text": "Inside a New OT/IoT Cyberweapon: IOCONTROL\r\nBy Team82\r\nPublished: 2024-12-10 · Archived: 2026-04-05 16:43:49 UTC\r\nExecutive Summary\r\nTeam82 obtained a sample of a custom-built IoT/OT malware called IOCONTROL used by Iran-affiliated attackers\r\nto attack Israel- and U.S.-based OT/IoT devices.\r\nIOCONTROL has been used to attack IoT and SCADA/OT devices of various types including IP cameras, routers,\r\nPLCs, HMIs, firewalls, and more. Some of the affected vendors include: Baicells, D-Link, Hikvision, Red Lion,\r\nOrpak, Phoenix Contact, Teltonika, Unitronics, and others.\r\nWe’ve assessed that IOCONTROL is a cyberweapon used by a nation-state to attack civilian critical infrastructure.\r\nOur analysis of IOCONTROL includes an in-depth look at the malware’s capabilities and unique communication\r\nchannels to the attackers’ command-and-control infrastructure.\r\nWhat is the IOCONTROL Malware?\r\nIOCONTROL is believed to be part of a global cyber operation against western IoT and operational technology (OT)\r\ndevices. Affected devices include routers, programmable logic controllers (PLCs), human-machine interfaces (HMIs),\r\nfirewalls, and other Linux-based IoT/OT platforms. While the malware is believed to be custom-built by the threat actor, it\r\nseems that the malware is generic enough that it is able to run on a variety of platforms from different vendors due to its\r\nmodular configuration.\r\nTeam82 has analyzed a malware sample extracted from a fuel management system that was allegedly compromised by a\r\nthreat actor group linked to Iran known as the CyberAv3ngers, which is also believed to be responsible for the Unitronics\r\nattack last fall. \r\nOne particular IOCONTROL attack wave involved the compromise of several hundred Israel-made Orpak Systems and\r\nU.S.-made Gasboy fuel management systems in Israel and the United States. The malware is essentially custom built for IoT\r\ndevices but also has a direct impact on OT such as the fuel pumps that are heavily used in gas stations. \r\nThe attacks are another extension of the geopolitical conflict between Israel and Iran. The so-called CyberAv3ngers are\r\nbelieved to be part of the Islamic Revolutionary Guard Corps Cyber Electronic Command (IRGC-CEC) and have been vocal\r\non Telegram sharing screenshots, and other information about the compromises of these fuel systems. \r\nIn February, the U.S. Department of the Treasury announced sanctions against six IRGC-CEC officials linked to the\r\nCyberAv3ngers and offered a $10 million USD bounty for information leading to the identification or location of anyone\r\ninvolved in the attacks. \r\nOur analysis of the sample we obtained from VirusTotal (21 detections as of Dec. 10 2024, after a period of time when there\r\nwere 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\r\nsystems. For secure communication between compromised devices and the attackers, IOCONTROL leverages the MQTT\r\nprotocol as a dedicated IoT communication channel. The attackers were able to disguise traffic over MQTT to and from the\r\nattackers’ command-and-control infrastructure.\r\nThe CyberAv3ngers, meanwhile, have implicitly stated they will continue to target Israel-made technology in critical\r\ninfrastructure. In October 2023, water treatment facilities in the U.S. and Israel were attacked by the group. Integrated\r\nUnitronics Vision series PLC/HMI devices were targeted inside these facilities; the attacks resulted in the defacement of\r\nthese OT devices. The attacks were likely projections of power from the CyberAv3ngers, demonstrating their access to the\r\ndevices and hoping to instill fear regarding the quality of water in affected areas. \r\nIOCONTROL Deployment on ORPAK Systems\r\nAround the same time of the attacks against water facilities, the CyberAv3ngers published on Telegram claims it had\r\nattacked 200 gas stations in Israel and the U.S., specifically targeting Orpak systems. The attackers released screenshots of\r\nthe main management portal of the attacked gas stations, as well as databases of information about their targets and leaked\r\ndata.\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 1 of 17\n\nA screenshot from the CyberAv3ngers Telegram channel where they discussed an attack against Orpak fuel\r\nmanagement devices.\r\nA screenshot shared on Telegram by CyberAv3ngers that shows they’d gained access to ORPAK SiteOmat\r\nfuel management systems.\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 2 of 17\n\nA dedicated CyberAv3ngers script running, and allegedly bricking, Orpak systems.\r\nFollowing up on the CyberAv3ngers’ claim of compromising Orpak systems, we found WHOIS records indicating\r\nregistration of a domain name tylarion867mino[.]com on Nov. 23, 2023.\r\nThis domain would be used by the attackers to set up a command-and-control infrastructure in order to manage all the\r\ncompromised devices. \r\nIn December 2023, an Israeli-associated hacking group called Gonjeshke Darande claimed to have attacked and\r\ncompromised 70% of Iran’s gas stations, claiming it was “in response to the aggression of the Islamic Republic and its\r\nproxies in the region.”\r\nWhile the reports about these attacks by CyberAv3ngers against Orpak devices span from mid-October 2023 to late January\r\n2024, our team obtained a publicly available sample of IOCONTROL from VirusTotal, indicating the group relaunched their\r\ntargeted campaign in July and August. \r\nOur research blog presents our analysis of the attack against multiple IoT/OT devices, including Orpak and Gasboy devices.\r\nIn addition we will analyze the IOCONTROL malware used in the attacks, and the attacker’s command and control\r\ninfrastructure, and communications over the MQTT protocol.\r\nORPAK Systems Devices\r\nThe sample we were able to obtain was extracted from a Gasboy fuel control system which has close ties with Orpak\r\nSystems. It is yet unclear the method used to deploy the malware on the affected victim systems.\r\nFuel control systems are complex platforms that consist of multiple subsystems including an outdoor payment terminal,\r\nprinter (for receipts), pump and nozzle control, and additional peripherals such as management and billing software.\r\nA GASBOY Fuel System device. Source: Spatco.com\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 3 of 17\n\nFuel control systems are complex and consist of many subsystems. Source: Gilbarco.com\r\nIOCONTROL was hiding inside Gasboy's Payment Terminal, called OrPT. An attacker with full control over the payment\r\nterminal means they had the ability to shut down fuel services and potentially steal credit card information from customers.\r\nIOCONTROL Binary Analysis\r\nThe IOCONTROL sample we analyzed targeted Orpak Fuel system devices. The hash of this sample is:\r\n1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498 . The sample included an internal GUID value\r\nused to identify a victim entity:  855958ce-6483-4953-8c18-3f9625d88c27 . The sample we analyzed was compiled\r\nspecifically for ARM-32 bit Big Endian architecture systems.\r\nUnpacking and Emulation of IOCONTROL\r\nObserving the malware sample in VirusTotal, there were zero detections in September in all of its sandbox engines; as of\r\nDec. 10, there are 21.\r\nVirusTotal detection dashboard for the malware sample.\r\nKnowing this made us extra cautious when handling the malware and analyzing its internals. We decided to start analyzing\r\nthe malware using a static analysis approach. This approach led us to the conclusion that an in-memory unpacking procedure\r\nran when the malware was executed.\r\nStatic analysis took far too long and too much effort, therefore we decided to pivot our efforts toward dynamic analysis of\r\nthe malware sample. This meant we were going to have to execute the malware sample safely and debug it.\r\nThe approach we took to execute and unpack the malware executable was emulation, specifically using the Python-based\r\nUnicorn CPU emulation engine. \r\nWe decided to go in this path because of two reasons:\r\n1. The malware sample was written for an archaic ARM 32-bit BE CPU architecture, which made emulation the best\r\ncandidate for a solution to execute and unpack the malware sample.\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 4 of 17\n\n2. We needed to find a way to execute the malware in a safe and controlled environment that would not potentially\r\ninfect our setup or perform malicious activity on our systems.\r\nUnicorn gave us more granular control over the emulation than other engines such as QEMU; it not only allowed us to\r\ncarefully inspect the malware execution flow, but also allowed us to have full control over the capabilities of the malware\r\nwith regards to syscall invocations and OS interactions.\r\nEmulating the sample was a gradual process in which we closely inspected the execution flow of the malware. This included\r\ntracing the executed code and saving memory mappings along each emulation round. In the beginning, each round of\r\nemulation was terminated abruptly, shortly after initiating the execution of the sample. This was caused most often upon an\r\nattempt to invoke a syscall for OS interaction by the malware. Unicorn provides the capability to execute emulated CPU\r\ninstructions in various architectures and variations. Yet it doesn’t facilitate specific OS infrastructure such as syscall\r\nimplementations of specific operating systems such as Linux or Windows.\r\nEach time we encountered a specific syscall invocation attempt, we tried to understand its purpose and implemented our\r\nown version of the syscall that enabled the execution to continue together with ensuring the interaction is safe and will not\r\nharm our testing environment.\r\nFor 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\r\nfd value to identify the requested file. When triggered on a read syscall, we supply our own defined content we control.\r\nDoing so allows us to have fine grained access to the malware code flow.\r\nA code snippet from the Python emulation module showing open, read, and syscall implementations.\r\nThe in-memory unpacking procedure was done in two stages during the malware execution. The first stage consisted of\r\nunpacking utility code routines into a newly mapped memory segment. The second stage consisted of unpacking the artifacts\r\nof the malware, which were the main executable module and the configuration of the malware into an appropriate memory\r\nlocation.\r\nDuring one of our emulation iterations, our execution flow started to execute on a newly mapped memory segment. This\r\nmeant that this memory segment had an unpacked artifact. Inspecting a memory snapshot of that segment led to our\r\nspeculation that the malware was using an open-source packer solution called UPX that may have been modified\r\nspecifically for this malware sample. The triggering element leading to this suspicion was a byte sequence left by the\r\nmalware developers untouched in an unpacked artifact of the malware: “ !XPU ” which is the little endian version of\r\n“ UPX! ”. This misstep by the attackers helped us to quickly identify UPX as the packer.\r\nA snapshot from the unpacked artifact containing a suspicious little endian representation of the UPX magic\r\nheader value.\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 5 of 17\n\nJust for the sake of research after we had the unpacked version of the malware, we used the benign UPX tool to pack it and\r\ncompared it to the original sample. We noticed some differences in locations where UPX-related features were supposed to\r\nbe placed, such as the magic UPX! string of bytes which was changed to ABC!.\r\nBinary diffing the original malware sample (left Segment) to the UPX packed artifact (right).\r\nTo further support this conclusion we compiled a version of UPX that ignores CRC checksum verification and patched the\r\nsample ABC byte sequences with UPX byte sequences, allowing us to successfully unpack the malware sample.\r\nOur assumption is that the attackers deployed the malware in that fashion because they were trying to evade detection and\r\nhide their malicious implant and configuration in a stable and quick way. This was apparently somewhat effective with\r\nregard to staying undetected by automated detection engines, but wasn’t very sophisticated.\r\nDecrypting IOCONTROL’s Configuration\r\nAfter unpacking the malware successfully, we were left with two artifacts: an encrypted data section and an executable.\r\nWhen examining the executable in IDA, we noticed that in many different locations in the code, it uses data from the\r\nencrypted section, using it for different operations such as a path for a file, IP address to connect to, etc.\r\nThe malware reads an hostname/port pair from its configuration, and uses it to connect to an MQTT broker.\r\nWe managed to discover that this encrypted section was in fact the encrypted configuration of the malware. Each encrypted\r\nconfiguration entry is composed of 150 bytes: 1 byte of length (the length of the encrypted data, up to 149), and up to 149\r\nbytes of encrypted data. \r\nIn order to decrypt the configuration of the malware, it uses a decryption function, which receives an index specifying which\r\nconfiguration it wants decrypted from a list. This technique allows minimizing the possibility of extracting decrypted\r\nconfiguration entries from the process memory during the malware runtime.\r\nIn this decryption function, the malware fetches the first byte from the encrypted configuration entry. This value is used to\r\ntell how long that specific encrypted configuration entry is, after reading the encrypted entry raw bytes, the malware uses\r\nAES-256-CBC decryption scheme to extract the actual configuration entry.\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 6 of 17\n\nThe configuration decryption routine, taking the key/IV pair from environment variables.\r\nPrior to decryption, the malware extracts the key and IV pair from a GUID stored in one of its strings, which the malware\r\nuses for many purposes. The extracted key and IV are used for decryption and get stored in environment variables 0_0 and\r\n0_1 respectively.\r\nThe key generation routine, performing hash and string operations on a hardcoded GUID.\r\nAs we can see, the malware takes the GUID stored in its memory ( 855958ce-6483-4953-8c18-3f9625d88c27 ), and uses\r\nSHA256 to hash it. The key for the AES-256-CBC encryption is simply the hash of the GUID\r\n( 22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e ) as a hex string. This is probably a mistake by\r\nthe attackers, who got confused, since AES-256 uses a 32-byte size for its keys, however they used a 64-hex-string instead.\r\nBecause the given key is bigger than the key size, only the first 32 bytes will actually be used by the AES-256-CBC process.\r\nThe 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\r\nthe first 16 bytes are used.\r\nOur assumption is that the attackers are using unique GUIDs which get inserted by binary patching malware samples to\r\ndistinguish between different victims and/or campaigns. This is further supported by the fact that the malware derives most\r\nof its parameters from the seed GUID which can be easily changed without recompiling the malware by binary patching the\r\nstring. Furthermore, the malware uses IoT vendor identifiers. For example, in our sample we noticed the name Orpak in the\r\ndecrypted configuration which identifies the vendor manufacturing the embedded device that was attacked.\r\nTo summarize, here are the environment variables used by the malware, as well as how they are used and how they are\r\ngenerated:\r\nEnvironment\r\nVariable\r\nValue Derived by Used for\r\nGUID (not\r\nenvironment\r\nvariable)\r\n855958ce-6483-4953-8c18-3f9625d88c27 Hardcoded\r\nGenerating\r\nidentifiers\r\nfor the\r\nmalware\r\n0_0 22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e SHA256(GUID)\r\nAES-256-\r\nCBC key\r\nto decrypt\r\nthe config\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 7 of 17\n\n0_1 1c3b88f1e4720dc6a090c4617a919447\r\nSHA256(GUID)\r\n[31:63]\r\nAES-256-\r\nCBC key\r\nIV decrypt\r\nthe config\r\n1 1.0.5 Hardcoded\r\nMalware\r\nversion\r\n3 5958ce GUID[2:8]\r\nValue to\r\ntell the\r\nmalware\r\nto self\r\ndelete.\r\nAlso used\r\nas MQTT\r\nusername\r\n4 3-4953-8c18-3f9625 GUID[12:30]\r\nAlso used\r\nas MQTT\r\npassword\r\nAfter extracting the AES-256-CBC key and IV pair, we decrypted the entire encrypted section holding the various\r\nconfiguration entries, and examined each configuration entry the malware uses.\r\nA partial list of the configurations used by the malware.\r\nResolving IOCONTROL Command-and-Control via DoH\r\nWith the configurations in hand, we moved on to analyze the malware behavior. One thing that piqued our interest\r\nimmediately was the DNS name stored in the first configuration:\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 8 of 17\n\nuuokhhfsdlk[.]tylarion867mino[.]com.\r\nAt the time of writing this report, the domain C2 address is resolving to IP address 159[.]100[.]6[.]69 .\r\nFollowing the malware execution flow, we discovered that indeed this is the hostname used by the malware to communicate\r\nwith its C2.\r\nFirst, the malware uses Cloudflare’s servers to translate the hostname into an IP address. In order to evade detection, the\r\nmalware does not use DNS to translate this hostname directly, instead it uses DNS over HTTPS (DoH) to translate it via\r\nCloudFlare’s API. This is a stealth technique used by malware to avoid being detected by sending a clear-text DNS request,\r\nshowcasing which DNS names they communicate with. Instead, they used an encrypted protocol (HTTPS), meaning that\r\neven if a network tap exists, the traffic is encrypted so they won’t be discovered.\r\nBelow is a request to Cloudflare's servers, querying the attacker's C2 hostname:\r\n~ curl --http2 --header \"accept: application/dns-json\"\r\n\"https://1.1.1.1/dns-query?name=uuokhhfsdlk[.]tylarion867mino[.]com\"\r\n{\r\n\"Status\": 0,\r\n\"TC\": false,\r\n\"RD\": true,\r\n\"RA\": true,\r\n\"AD\": false,\r\n\"CD\": false,\r\n\"Question\": [\r\n{\r\n\"name\": \"uuokhhfsdlk[.]tylarion867mino[.]com\",\r\n\"type\": 1\r\n}\r\n],\r\n\"Answer\": [\r\n{\r\n\"name\": \"uuokhhfsdlk[.]tylarion867mino[.]com\",\r\n\"type\": 1,\r\n\"TTL\": 300,\r\n\"data\": \"159[.]100[.]6[.]69\"\r\n}\r\n]\r\n}\r\nThe routine handling DNS over HTTPS translation of the malware’s C2 hostname.\r\nPersistence\r\nBefore connecting to the C2 infrastructure, the malware first installs a backdoor on the device in order to ensure its\r\npersistence. To do so, the malware adds a new rc3.d boot script, which will be executed whenever the device restarts. The\r\nbackdoor is located in /etc/rc3.d/S93InitSystemd.sh , contains the following bash script:\r\ntrap \"rm -f $iocpid\" EXIT\r\nwhile true; do\r\nif ! pidof \"iocontrol\" \u003e /dev/null; then\r\niocontrol \u003e/dev/null 2\u003e\u00261 \u0026\r\nfi\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 9 of 17\n\nsleep 5\r\ndone\r\nIn addition to this backdoor, the malware is stored under the name iocontrol in the /usr/bin directory.\r\nCommunication with C2 via MQTT\r\nAfter translating this hostname into IP address, the malware takes the second configuration parameter: 8883, and uses it as\r\nthe port to connect to the C2. Port 8883 is usually used by the  MQTTs communication protocol, and when examining the\r\ncode further we indeed saw that the malware indeed communicates over this port.\r\nThe malware constructs an MQTT CONNECT packet, initiating its MQTTs connection to the C2.\r\nMQTT Protocol\r\nThe MQTT protocol is a publish-subscribe network protocol that transports messages between devices. It's designed for use\r\nin environments where network bandwidth is limited or unreliable, making it particularly well-suited for internet of things\r\n(IoT) applications. For these reasons, and for being a bit more stealthy, we believe the attackers decided to use the MQTT\r\nprotocol for their C2 communications.\r\nIn order to connect, the malware uses MQTT 4.0, sending the C2 three different identifiers:  Client ID, Username, Password.\r\nFor the Client ID, the malware uses the GUID stored in its memory, the username is the environment variable 3 (derived\r\nfrom the GUID), and the password is the environment variable 4 (also derived from the GUID). Using these identifiers,\r\nthe malware authenticates to the MQTT broker.\r\nA reconstruction of the malware’s MQTT connect message.\r\nAfter connecting to the MQTT broker, the malware immediately publishes an “ hello ” message to the following topic:\r\n{GUID}/hello . This message informs the C2 of a new connection, and sends a lot of identification information about the\r\ninfected device. In its hello message, the malware sends a JSON with this information:\r\n{\r\n\"hostname\": \"HOSTNAME\",\r\n\"current_user\": \"CURRENT_USER\",\r\n\"device_name\": \"DEVICE_NAME\",\r\n\"device_model\": \"DEVICE_MODEL\",\r\n\"timezone\": \"TIMEZONE\",\r\n\"firmware_version\": \"FIRMWARE_VERSION\",\r\n\"geo_location\": \"GEO_LOCATION\",\r\n\"version\": \"MALWARE_VERSION\"\r\n}\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 10 of 17\n\nIn order to get this information (for example, the current user, hostname etc), the malware uses OS commands. In this\r\nprocess, the malware gets a handle to the libc library by calling dlopen with the parameter libc.so.6 . Then, using\r\nthis handle, the malware gets the pointer to the system function using dlsym , giving it the function name system , and\r\nlastly uses this pointer to execute the OS commands it needs.\r\nThe malware’s method of performing system commands.\r\nFor each OS command the malware executes, it constructs the following command:\r\nOS_COMMAND \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\nAs part of the hello message, the malware executes the following OS commands in this order:\r\nuname -v \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\nhostname \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\nwhoami  \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\ndate +%Z \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\nuname -r \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\nAfter sending the hello message, the malware subscribes to the MQTT topic {GUID}/push. Using this topic, the C2 sends\r\nthe malware commands for execution, which the malware executes inside the callback routine that is called whenever a\r\nMQTT message is received.\r\nSupported Commands\r\nIn this routine, the malware parses the received message and extracts the command the malware has sent. Each command\r\nfrom the C2 is one of five different types, each identified by a different opcode:\r\nOpcode Command Description\r\n0 Send “hello” Resend the MQTT hello message with basic device information\r\n1 Check exec\r\nCheck that the malware is installed in /usr/bin/iocontrol and that it is executable, and\r\npublishes the string 1:1\r\n2\r\nExecute\r\ncommand\r\nExecute arbitrary OS command via system call and publishes the output\r\n3 Self-delete\r\nStop the malware execution, as well as remove malware main binary, its persistence\r\nservice, and related logs files. It then publishes the string 3:1\r\n8 Port scan\r\nScan an IP range in a specific port. The malware receives IP start, IP end and a port to\r\nscan. It then publishes the result.\r\nAfter finishing the command execution, the malware publishes the response using the {GUID}/output topic.\r\nIOCONTROL Flow: Simplified\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 11 of 17\n\nIOCONTROL Infrastructure\r\nThe malware’s C2 domain is uuokhhfsdlk[.]tylarion867mino[.]com, which resolved to 159[.]100[.]6[.]69\r\nIOC Country Verdict Description Type\r\n159[.]100[.]6[.]69 Malicious\r\nC2 from IOCONTROL.\r\nServices:\r\nMQTT 1883/TCP\r\nMQTT 8883/TCP\r\nHTTP 15672/TCP\r\nIP\r\nAddress\r\nuuokhhfsdlk[.]tylarion867mino[.]com Malicious\r\nDomain found in IOCONTROL.\r\nCommunication over MQTT on port\r\n8883.\r\nDomain\r\nocferda[.]com Malicious Older DNS records, from around 2023,\r\nshow that the domain ocferda[.]com\r\nDomain\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 12 of 17\n\nwas in use and pointed to the same IP\r\naddress of the C2  159[.]100[.]6[.]69\r\nDomain\r\nThe C2 domain tylarion867mino[.]com was registered on Nov. 23rd, 2023. This domain was used by the attackers to set\r\nup a C2 infrastructure, allowing them to command and control all devices they infect.\r\nThe Whois record for the attacker’s C2 domain name.\r\nThe C2 domain address was resolved to 159[.]100[.]6[.]69 at the time of writing this report. This address was hosted in\r\nGermany and had MQTT services running on ports 1883 and 8883 and RabbitMQ Management Server running on port\r\n15672. Communications to the C2 server on port 8883 can be either victims reporting to C2 or an operator accessing the\r\nserver.\r\nOlder DNS records, from around 2023, show that the domain ocferda[.]com was in use and pointed to the same IP address\r\nof the C2 159[.]100[.]6[.]69 .\r\nSummary\r\nOur 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\r\nsecure MQTT channel and supports basic commands including arbitrary code execution, self-delete, port scan, and more.\r\nThis functionality is enough to control remote IoT devices and perform lateral movement if needed. \r\nIn addition, IOCONTROL has a basic persistence mechanism over a daemon installation and stealth mechanism, for\r\nexample the initial payload uses modified UPX packing and the malware uses DNS over HTTPS to hide its C2\r\ninfrastructure as much as possible.\r\nThis specific sample was extracted from a Gasboy/ORPAK device, which is a fuel system platform. However,\r\nIOCONTROL was used to attack IoT and SCADA devices of various types including  IP cameras, routers, PLCs, HMIs,\r\nfirewalls, and more from different vendors such as Baicells, D-Link, Hikvision, Red Lion, Orpak, Phoenix Contact,\r\nTeltonika, Unitronics, and others.\r\nIOCONTROL Indicators of Compromise (IoC)\r\nIOC Description Type\r\n159[.]100[.]6[.]69 C2 from IOCONTROL.\r\nIP\r\nAddress\r\nuuokhhfsdlk[.]tylarion867mino[.]com\r\nDomain found in\r\nIOCONTROL.\r\nCommunication over\r\nMQTTs on port 8883.\r\nDomain\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 13 of 17\n\nocferda[.]com\r\nOlder DNS records, from\r\naround 2023, show that the\r\ndomain ocferda[.]com was in\r\nuse and pointed to the same\r\nIP address of the C2 \r\n159[.]100[.]6[.]69\r\nDomain\r\n1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498\r\nIOCONTROL Initial sample\r\nLink to VT\r\nHash\r\n/usr/bin/iocontrol Malware executable path Path\r\n/etc/rc3.d/S93InitSystemd.sh Malware service path Path\r\n/tmp/iocontrol Malware directory for\r\ntemporary files\r\nPath\r\n/var/run/iocontrol.pid Malware current process\r\nPID file\r\nPath\r\nAppendix 1: Environment Variables (post processing)\r\nEnvironment\r\nVariable\r\nValue Derived by Used for\r\nGUID (not\r\nenvironment\r\nvariable)\r\n855958ce-6483-4953-8c18-3f9625d88c27 Hardcoded\r\nGenerating\r\nidentifiers\r\nfor the\r\nmalware\r\n0_0 22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e SHA256(GUID)\r\nAES-256-\r\nCBC key\r\nto decrypt\r\nthe config\r\n0_1 1c3b88f1e4720dc6a090c4617a919447\r\nSHA256(GUID)\r\n[31:63]\r\nAES-256-\r\nCBC key\r\nIV decrypt\r\nthe config\r\n1 1.0.5 Hardcoded\r\nMalware\r\nversion\r\n3 5958ce GUID[2:8]\r\nValue to\r\ntell the\r\nmalware\r\nto self\r\ndelete.\r\nAlso used\r\nas MQTT\r\nusername\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 14 of 17\n\n4 3-4953-8c18-3f9625 GUID[12:30]\r\nAlso used\r\nas MQTT\r\npassword\r\nAppendix 2: Decrypted Config from sample 1b39f9b2\r\nID Data Description\r\n0 uuokhhfsdlk[.]tylarion867mino[.]com C2 host (as of Sept 8th resolves to 159[.]100[.]6.69 Frankfurt, Germany)\r\n1 8883 MQTT Secure port\r\n2 XXFrxHMDI1CqmIN5 Currently unknown - maybe previously used username\r\n3 sCgcVpkXixEUTgEJqY708N5w2c42DssIEutp7ZIeNgt17G78iy Currently unknown - maybe previously used password\r\n4 /hello MQTT topic to send device info\r\n5 accept: application/dns-json\r\nHTTP Header required by CloudFlare to make DNS over HTTPS (DoH) requ\r\nhttps://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api\r\n6 /output MQTT topic to send command output\r\n7 /push MQTT Topic to receive commands\r\n8 GET HTTP method GET\r\n9 POST HTTP method POST\r\n10 1:01 Reports that the binary is executable via MQTT\r\n11 3:01 Report self-delete via MQTT\r\n12 whoami Command whoami\r\n13 hostname Command hostname\r\n14 current_user JSON key current_user\r\n15 device_name JSON key device_name\r\n16 device_model JSON key device_model\r\n17 timezone JSON key\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 15 of 17\n\n18 firmware_version JSON key firmware_version\r\n19 geo_location JSON key geo_location\r\n20 output JSON key output\r\n21 params JSON key params\r\n22 code JSON key code\r\n23 ORPAK Vendor name\r\n24 data\r\nCloudflare DoH JSON response key data - where the IP is resolved\r\n{\"Status\":0,\"TC\":false,\"RD\":true,\"RA\":true,\"AD\":false,\"CD\":false,\"Question\r\n[{\"name\":\"uuokhhfsdlk.tylarion867mino.com\",\"type\":1}],\"Answer\":\r\n[{\"name\":\"uuokhhfsdlk[.]tylarion867mino[.]com\",\"type\":1,\"TTL\":300,\"data\"\r\n25 Answer\r\nCloudflare DoH JSON response Answer data - the DNS response \r\n{\"Status\":0,\"TC\":false,\"RD\":true,\"RA\":true,\"AD\":false,\"CD\":false,\"Question\r\n[{\"name\":\"uuokhhfsdlk[.]tylarion867mino[.]com\",\"type\":1}],\"Answer\":\r\n[{\"name\":\"uuokhhfsdlk[.]tylarion867mino[.]com\",\"type\":1,\"TTL\":300,\"data\"\r\n26 1.1.1.1:443/dns-query?name=\r\nURL to resolve DNS over HTTPS (DoH) \r\nhttps://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api\r\ncurl --http2 --header \"accept: application/dns-json\" \"https://1.1.1.1/dns-query\r\n27 /dev/urandom Linux path to get random data\r\n28 /tmp/ Linux path for /tmp\r\n29 .txt Suffix .txt\r\n30 2\u003e\u00261 Linux bash syntax to redirect stderr to stdout\r\n31   \u003e /dev/null 2\u003e\u00261 \u0026\r\nLinux bash syntax to redirect both stderr and stdout to /dev/null and run the e\r\nbackground\r\n32 version JSON key sent in MQTT hello\r\n33 date +%Z Command date\r\n34 %Y/%m/%d %H:%M:%S Date format\r\n35 ptrace ptrace function to debug\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 16 of 17\n\n36 system System function to execute code given a remote command\r\n37 libc.so.6 libc library\r\n38 /tmp/iocontrol/ Malware path for temporary files\r\n39 /tmp/iocontrol.log Malware log path\r\n40 iocontrol Malware name - iocontrol\r\n41 /etc/rc3.d/S93InitSystemd.sh Malware path for its daemon/service (persistency) - this will run the malware\r\n42 uname -v\r\nCommand uname -v\r\nuname -v \u003e /tmp/{RANDOM_16_chars}.txt 2\u003e\u00261\r\n43 uname -r Command uname -r\r\n44\r\n#!/bin/sh\r\niocpid=/var/run/iocontrol.pid\r\nif [ -f \"$iocpid\" ] \u0026\u0026 kill -0 $(cat \"$iocpid\") 2\u003e/dev/null; then\r\n    exit 1\r\nfi\r\necho $$ \u003e \"$iocpid\"\r\nBash script deployed by the malware to stop the running instance\r\n45 /usr/bin/iocontrol Malware full path location\r\n46 /etc/rc3.d/\r\nLinux path for system daemons/services - this is where the init script for runn\r\nlocated\r\n47\r\ntrap \"rm -f $iocpid\" EXIT\r\nwhile true; do\r\nif ! pidof \"iocontrol\" \u003e /dev/null; then\r\n    iocontrol \u003e/dev/null 2\u003e\u00261 \u0026\r\nfi\r\nsleep 5\r\ndone\r\nBash script deployed by the malware to make sure it’s running - watchdog\r\nSource: https://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nhttps://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://claroty.com/team82/research/inside-a-new-ot-iot-cyber-weapon-iocontrol"
	],
	"report_names": [
		"inside-a-new-ot-iot-cyber-weapon-iocontrol"
	],
	"threat_actors": [
		{
			"id": "5484a633-c850-4380-921b-72fce1a32e72",
			"created_at": "2024-01-18T02:02:34.026014Z",
			"updated_at": "2026-04-10T02:00:04.636248Z",
			"deleted_at": null,
			"main_name": "CyberAv3ngers",
			"aliases": [],
			"source_name": "ETDA:CyberAv3ngers",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "b125b5c1-1431-4880-9ab8-582a583811ea",
			"created_at": "2024-04-24T02:00:49.643067Z",
			"updated_at": "2026-04-10T02:00:05.421434Z",
			"deleted_at": null,
			"main_name": "CyberAv3ngers",
			"aliases": [
				"CyberAv3ngers",
				"Soldiers of Soloman"
			],
			"source_name": "MITRE:CyberAv3ngers",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "8d28f58b-5ea2-4450-a74a-4a1e39caba6e",
			"created_at": "2026-03-16T02:02:50.582318Z",
			"updated_at": "2026-04-10T02:00:03.777263Z",
			"deleted_at": null,
			"main_name": "COASTLIGHT",
			"aliases": [
				"Gonjeshke Darande",
				"Indra",
				"Predatory Sparrow"
			],
			"source_name": "Secureworks:COASTLIGHT",
			"tools": [],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "219ddb41-2ea8-4121-8b63-8c762f7e15df",
			"created_at": "2023-01-06T13:46:39.384442Z",
			"updated_at": "2026-04-10T02:00:03.309654Z",
			"deleted_at": null,
			"main_name": "Predatory Sparrow",
			"aliases": [
				"Indra",
				"Gonjeshke Darande"
			],
			"source_name": "MISPGALAXY:Predatory Sparrow",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434498,
	"ts_updated_at": 1775792119,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/00910170047c8ea0d169602b2e5ada04394a3984.pdf",
		"text": "https://archive.orkl.eu/00910170047c8ea0d169602b2e5ada04394a3984.txt",
		"img": "https://archive.orkl.eu/00910170047c8ea0d169602b2e5ada04394a3984.jpg"
	}
}