New Hide 'N Seek IoT Botnet using custom-built Peer-to-Peer communication spotted in the wild

Bitdefender researchers have uncovered an emerging botnet that uses advanced communication techniques to exploit victims and build its infrastructure. The bot, dubbed HNS, was intercepted by our IoT honeypot system following a credentials dictionary attack on the Telnet service.

The bot was first spotted on Jan. 10 then faded away in the following days, only to re-emerge on Jan. 20 in a significantly improved form.

Update 26/01/2018 – 14.06 GMT+3

The botnet now controls 32,312 IoT devices. Also, the botnet seems to undergo massive development as new samples compiled for a variety of architectures have been added as payloads:

0c90ea12275cadd96a67f8ee07e2fa04af91e51e: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
19f54473a721105982281b7b87503e3d60585042: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
2b36305f7dcb63b4f55bffab0f0dbbaaabf83b28: ELF 32-bit MSB executable, Motorola 68020 – invalid byte order, version 1 (SYSV), statically linked, stripped
4dcca2094b55b6576c1b27597e4b10db9b6bfa53: ELF 32-bit MSB executable, SPARC version 1 (SYSV), statically linked, stripped
6e5a74d0e39f7e17effb54270c41910b99f7e873: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
788f52df7aeae720c90fe21eeb946409dcd2fed7: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
a82c3cd904315131845d56101b7af8cc2b1eee7b: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
b7ccfbbcb3a29de4ae507415ddca93029d90923d: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped
ed24e8f5eb277e8b58fb39c15ece3d60af418459: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, stripped
f7631f2bc30bb5a570bafa966c2f0d5fb7960e94: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

Update 01/25/2018 – 11.50 GMT+3

Hide ‘N Seek currently counts more than 24,000 bots.

Update 01/24/2018 – 20.00 GMT+3

The botnet now counts more than 20,000 IoT devices geographically distributed as per the graphic below.

Update 01/24/2018 – 17.30 GMT+3

18,000 compromised devices and counting.

Update 01/24/2018 – 14.00 GMT+3

The botnet now counts more than 14K devices geographically distributed as per the heatmap below. What initially started as a 12-device network has become a phenomenon that spreads from Asia to the United States.

Impact

The HNS botnet communicates in a complex and decentralized manner and uses multiple anti-tampering techniques to prevent a third party from hijacking/poisoning it. The bot can perform web exploitation against a series of devices via the same exploit as Reaper (CVE-2016-10401 and other vulnerabilities against networking equipment).

The bot embeds a plurality of commands such as data exfiltration, code execution and interference with a device’s operation.

Operation

The bot features a worm-like spreading mechanism that randomly generates a list of IP addresses to get potential targets. It then initiates a raw socket SYN connection to each host in the list and continues communication with those that answer the request on specific destination ports (23 2323, 80, 8080). Once the connection has been established, the bot looks for a specific banner (“buildroot login:”) presented by the victim. If it gets this login banner, it attempts to log in with a set of predefined credentials. If that fails, the botnet attempts a dictionary attack using a hardcoded list.

Once a session is established with a new victim, the sample will run through a “state machine” to properly identify the target device and select the most suitable compromise method. For example, if the victim has the same LAN as the bot, the bot sets up TFTP server to allow the victim to download the sample from the bot. If the victim is located on the internet, the bot will attempt a specific remote payload delivery method to get the victim to download and run the malware sample. These exploitation techniques are preconfigured and are located in a memory location that is digitally signed to prevent tampering. This list can be updated remotely and propagated among infected hosts.

The samples identified in our honeypots on Jan. 10 revolved around IP cameras manufactured by a Korean company. These devices seemed to play a major role in the botnet as, out of the 12 IP addresses hardcoded in the sample, 10 used to belong to Focus H&S devices. The new version, observed on Jan. 20, dropped the hardcoded IPs.

Like other IoT bots, the newly discovered HNS bot cannot achieve persistence, and a reboot would bring the compromised device back to its clean state. It is the second known IoT botnet to date, after the notorious Hajime botnet, that has a decentralized, peer-to-peer architecture. However, if in the case of Hajime, the p2p functionality was based on the BitTorrent protocol, here we have a custom-built p2p communication mechanism.

UDP communication mechanism

The bot opens a random port on the victim, and adds firewall rules to allow inbound traffic for the port. It then listens for connections on the open port and only accepts the specific commands described below. Our initial look at the sample revealed an elliptic curve key inside the file that is used to authenticate the command which updates the memory zone where configuration settings are stored, to prevent infiltration or poisoning attempts against the botnet.
The botnet binary can have the following arguments at runtime:

‘k’ + [some_port_number] – Kills all processes running on the specified port at startup.

‘l’ + [some_port_number] – Listens on the specified port number after startup

‘s’ + path – Reads files starting from the path and loads them into memory. Then, the content can be retrieved by other peers via the ‘m’, ‘y’ and ‘Y’ commands. There’s also a sha256-checksums for each file that gets created. As a side effect, this will keep the malicious binary on the system.

‘a’ + [IP:PORT] – Adds IP:PORT to the list of internally stored IP:PORT

‘e’ + IP:PORT – Adds a new target to the otherwise randomly generated target list.

Supported commands

To understand the capabilities of the bot, we looked into the messages received from other peers. Below is a list of the supported commands, along with a description of the expected results:

‘i’ + u32(config_size)  – If the config_size received is larger than the size of the current configuration, an acknowledgement message is sent back to the peer. The peer is eventually set as a communication endpoint to get the larger config. If the dht_size is smaller, an ‘I’ message is sent back to the peer advertising the larger config.

‘I’ + u32(config_size)  – The config_size received should be larger than the size of the current config (following an ‘i’ message query). An acknowledgement message is sent back and eventually the peer is set as a communication endpoint to get the larger config.

‘m’ + u8[32](hash) + u32(ip) + u16(port) + u16(seq) + u8(hops) + u8(unk) – This message attempts to find data based on the hash given. It first checks locally if the hash is known and data is available. If data is available, it starts sending it to ip:port via a ‘Y’ message. If data is not locally available, the bot broadcasts the current ‘m’ message (with hops decremented, but not more than 5 hops) to all its known peers.

‘^’ + u8(flags) + u16(port) + u32(ip) – Signals a new peer at ip:port. The new peer gets added to the list of known peers (it can also replace a peer if too many are present).

‘~’ – Requests a new peer. Upon receiving this, a random peer is selected from the list of known peers and sent via a ‘^’ message

‘Y’ + u16(chunk_index) + u16(seq) + u8[](data) – This is the data received message. The data is copied in chunks of at most 0x100 bytes (i.e. the current offset is chunk_index * 0x100). The chunk_index is the current offset being read from and it should correspond to the current size of a communicated buffer.

There are multiple possible outcomes once the file is downloaded:

• If the data is a new config, it gets verified (via ECDSA – the elliptic curve key mentioned above) and, if OK, it will replace the current config”
• The file can get dropped and executed (i.e. an update mechanism)

‘y’ + u8[32](hash) + u16(chunk_index) + u16(seq) – This command attempts to read from chunk_index the data corresponding to the cache via a ‘Y’ message. If, for whatever reason, the data is not available locally, an ‘m’ message gets broadcast.

‘O’ + u8(checksum) – This is an acknowledgement message. The checksum is done on the received message.

‘i’ , ‘I’ (first version)’h’, ‘H’ (second version) – Commands for configuration updates

‘m’,’Y’,’y’ Data exfiltration mechanism (“m”  communicates a hash, while “Y” and “y” move data around)

“z” scanning component (sends to a peer valid credentials that have been found via dictionary attack)

“O” ack on “z” credentials received OK (however, the same ack can be sent in several other occasions)

“^” add a new peer to the list of known peers

“~” send a peer IP as a response (when queried for a peer IP)

Conclusions

While IoT botnets have been around for years, mainly used for DDoS attacks, the discoveries made during the investigation of the Hide and Seek bot reveal greater levels of complexity and novel capabilities such as information theft – potentially suitable for espionage or extortion.

It is also worth noting that the botnet is undergoing constant redesign and rapid expansion.

Known hashes

efcd7a5fe59ca8223cd282bfe501a2f92b18312c
05674f779ebf9dc6b0176d40ff198e94f0b21ff9