A variant of the Mirai botnet is leveraging four different device vulnerabilities to add popular Linux-based servers and Internet of things (IoT) gear to botnets that can conduct network-based attacks, including distributed denial of service (DDoS) attacks.
A team at Palo Alto Networks’ Unit 42 observed the variant, dubbed IZ1H9, being used in an April 10 attack that leveraged the bugs: two command injection vulnerabilities — CVE-2023-27076, which affects Tenda G103 devices, and CVE-2023-26801, which affects LB-Link devices; two remote code execution (RCE) flaws, CVE-2023-26802, which affects DCN DCBI-Netlog-LAB, and another without a CVE that affects Zyxel devices.
While the IZ1H9 variant seems mainly bent on DDoS attacks, the impact of the infection could be potentially more serious, since the exploits can ultimately lead to RCE, the researchers said.
Indeed, “RCE is pretty high on the list of things enterprises don’t want to experience,” notes Stephen Gates, principal security subject matter expert at security firm Horizon3.ai, in an email interview with Dark Reading. “What this means is that vulnerable devices are being completely taken over by attackers with ease, often for long periods of time, and eventually becoming persistent threats.”
He adds, “No enterprise wants to have infected IoT devices in their networks being used to attack others — or even themselves with no knowledge of that activity whatsoever.”
Unit 42 researchers have observed IZ1H9 being wielded by one threat actor or the same group of actors in more than one attack since November 2021, they said, though the malware has been around in some form since 2018.
Their attribution to the same actor for multiple recent attacks is supported by several factors, including the nearly identical malware shell script downloaders used in the incidents. Moreover, the botnet samples discovered from the attacks — which used almost identical functions — that they shared both a XOR decryption key and the same infrastructure.
IZ1H9 Cyberattacks & Malware Analysis
In the April 10 attack, the researchers observed abnormal traffic from their threat-hunting system as attackers tried to download and execute a shell script downloader lb.sh from IP 163.123.143[.]126. If executed, the shell script downloader would first delete logs to hide its tracks, then deploy and execute a number of bot clients to accommodate different Linux architectures, the researchers said.
In the attack’s final step, the shell script downloader would block network connection from several ports —including SSH, telnet, and HTTP — by modifying the device’s iptable rules, so that the victim wouldn’t be able to connect and recover the compromised device remotely, they said.
IZ1H9 first checks the network portion of the infected device’s IP address to avoid execution for a list of IP blocks, including government networks, Internet providers, and large tech companies, the researchers said.
Gates finds this behavior indicative of a threat group that’s interested in longevity. “This suggests that the botmasters want to avoid these networks so that they can continue to operate long term and stay under the radar of those who might focus on stopping their activities,” he says.
The botnet client prints the word “Darknet” to the console to make its presence visible and includes a function that ensures the device is running only one instance of the malware, the researchers said. If a botnet process already exists, the botnet client will terminate the current process and start a new one.
The botnet client also contains a list of process names belonging to other Mirai variants and other botnet malware families, checking the running process names on the infected host to terminate them, the researchers said.
Mitigating the Mirai-Variant Botnet Threat
Infamously, Mirai has already spawned a number of variants since its source code was leaked in 2016, including one that can leverage nine vulnerabilities in various devices to conduct attacks and another, BotenaGo, that can exploit up to 30. To defend against Mirai variants, researchers recommended that anyone with vulnerable devices in their infrastructure update them with the latest version of the software to apply any available patches when possible.
Organizations can also protect their networks with advanced firewall and threat protection that leverage machine learning to detect vulnerability exploits in real time, as well as advanced URL filtering and DNS security to block command-and-control domains and malware-hosting URLs, the researchers said.
Moreover, blocking ports 80 (HTTP), 22 (SSH), and 23 (TELNET) on devices that are public facing should be a no-brainer to mitigate this type of attack, Gates notes.
“I would never leave one of those ports open on any device — even if they were completely not accessible from the Internet,” he says. “When organizations leave them accessible, they are directly contributing to the botnet problem.”
A major issue with remediating this scenario is that IoT device manufacturers often leave these ports open in devices right off the assembly line, which is “utter negligence,” Gates says. In fact, he believes there should be an international governing body “to hold these IoT manufacturers responsible for their devices becoming botnet infected, then used to attack others.”
He notes, “It appears that some sort of penalty is the only way to get manufacturers to shore up security on the devices they make and sell to others.”