This blog post was authored by Lisandro Ubiedo (@_lubiedo) on 2020-02-04.
A couple of weeks ago, we released the IoT-23 Dataset, the first dataset of malicious and benign IoT network traffic, that consists of 23 scenarios. In this blog post we provide an analysis of Scenario 18, CTU-IoT-Malware-Capture-9-1. This malware sample is Hajime.
We analysed the binary sample and the network traffic of this scenario.
The SHA256 hash of the malware sample executed is af629ae5a79f715cdbcf9e1faf389a39bd96b887b019984e50798d013f38a466. VirusTotal identified the malware as Linux.Hajime and gave it a score of 30/58 (meaning that 30 of 58 30 engines detected this file). The sample was executed on a RaspberryPi 3+ (ARMv7) with Raspbian OS. The timeline of the traffic capture for this malware is:
Wed Jul 25 10:53:16 CEST 2018: Traffic capture started.
Wed Jul 25 11:52 CEST 2018: Malware executed.
Thu Jul 26 14:59:27 CEST 2018: Device disconnected.
Quick Sample Overview
The malware sample executed is an ELF32 ARM binary that was packed as it shows no cleartext strings, no imports and only one function was the entrypoint. According to a previous report [1], the malware binary was UPX packed but its UPX magic number (“UPX!”) [2] was modified to the random bytes F5 96 A4 B5 to avoid detection and/or unpacking as the upx tool will fail to parse the header. This magic number, or signature, is used by UPX to identify its header inside the binary during the decompression process. After fixing the UPX header by re-establishing the correct magic number it can be unpacked.
The sample was stripped and statically linked, leaving no extra information other than internal strings. Those strings show that parts of BitTorrent’s DHT protocol code are used (Figure 1) as these strings are present in the source code [3].
Figure 1. Strings coming from DHT’s source code and torrent port.
Another protocol being used is NTP which indicates the malware is going to retrieve a timestamp from a remote NTP service as can be seen in Figure 2 below.
Figure 2. NTP host and port to be used by the malware.
A peculiar thing is that the malware will try to protect the device from possible known attacks. For example:
Issuing an ioctl() action to the watchdog to protect the device from several buffer overflow attacks as seen in Hikvision DVR devices [4], this is shown in Figure 3.
Modifying the device’s iptables rules to avoid connection from port 23/TCP (Telnet), 7547/TCP, 5555/TCP and 5358/TCP respectively (Figure 4), and delete firewall rules placed by ISPs to protect the device from future attacks or control. This is shown in Figure 5.
Deleting /tmp/ftpupload.sh and /tmp/ftpupdate.sh,and turning the files into symbolic links to /dev/null to protect the device from remote code execution exploits known in several camera models [5]. This is shown in Figure 5.
Figure 3. Request code 0x80045704 is issued via ioctl() to disable the kernel watchdog.
Figure 4. Ports hardcoded in the binary and used in firewall rules to block incoming connections.
Figure 5. Ports being blocked via iptables and actions taken by the malware to protect the device from further or previous exploitation.
One thing to note is that the malware will delete itself from the filesystem to then persist in memory changing its name to telnetd using prctl(), as seen in Figure 6 below. So when the process list is retrieved it will look like a normal process and no abnormal file is seen in the filesystem. This will hide the malware’s presence to avoid further detection and removal.
Figure 6. Malware will figure as telnetd when reading the process list.
Malware Traffic Analysis
Once the malware is executed, it resolves the domain pool.ntp.org and contacts on port 123/TCP, this is shown in Figure 2. Then it contacts the domains router.bittorrent.com and router.utorrent.com on port 6881/UDP using DHT protocol [6], and sets itself up as a node part of the BitTorrent’s network. After sending DHT pings to both torrent endpoints, it finally receives a reply from router.bittorrent.com associated with IP 67.215.246.10 (Figure 7).
52 3523.265457 192.168.100.111 → 82.221.103.244 UDP 109 29930 → 6881 Len=67 56 3528.273606 192.168.100.111 → 67.215.246.10 UDP 109 29930 → 6881 Len=67 61 3568.282569 192.168.100.111 → 82.221.103.244 UDP 109 29930 → 6881 Len=67 64 3568.286067 192.168.100.111 → 67.215.246.10 UDP 109 29930 → 6881 Len=67 99 4173.295167 192.168.100.111 → 82.221.103.244 UDP 109 29930 → 6881 Len=67 ... 345 13779.297361 192.168.100.111 → 82.221.103.244 UDP 109 29930 → 6881 Len=67 348 13779.300108 192.168.100.111 → 67.215.246.10 UDP 109 29930 → 6881 Len=67 359 14381.870634 192.168.100.111 → 82.221.103.244 UDP 109 29930 → 6881 Len=67 365 14386.878271 192.168.100.111 → 67.215.246.10 UDP 109 29930 → 6881 Len=67 366 14387.057671 67.215.246.10 → 192.168.100.111 UDP 103 6881 → 29930 Len=61
Figure 7. Node response to malware DHT ping query.
After the response to the DHT ping query from the node, the malware starts requesting peers by sending a get_peers DHT request, which can provide the torrent with the infohash: cf5dde6a83785dce130ffed139e3210be2b1e90f.
Infohashes are SHA1 checksum hashes that identify a torrent and are a way for the malware to search for the correct file in the P2P network. Then the node 67.215.246.10 responds with a list of peers (IP address and port) routing table closest to the infohash:
Figure 8. Node list result of the infohash search by malware.
The list of hashes searched by the malware during this traffic capture is the following:
183b986aad5610538ae488d6c787c67d84c89f372ff16263d39570b98afcf0b1af41a5f570e193073ac9507beb70e26bcf224c24e145b8951a6d55223be0a63db7829239af6e078e5e1b710251e8becc46beb2d6f41ff3520d17ab0de6dd2685f8b6830a59e81952ede1acc66bcdc4c578e1b8025c058f2d626d32b082910ce8edf64789441a55f1d308908b63df36951c54a07d8a4b90a094be3118345f04dc6bdf0295571068f0fae8edcad0518c744d31f8716fdfd7ba768212983581d6fc06089efaeb613c687453dcab93d79ed09d1a8a8b8dda79b7b95d1d3986bd1ddd2b2b09026f9f25837353b549c8d0bec88df4b96a9e027ab2a83eeb5c40c3c5b2c066a7b8a068538b26a9e2676ed473c3b83202c3c822358fa7139f61880979c072f922128165f0ca821ceeb0abee951793ef0a7bf86b180db9853705962e8bf6b2299f3aedf927e00235cccf43f357d1a1dda1f5b3a2d9f050c8ce36ac0f8b2009f870fde9806e95cf5dde6a83785dce130ffed139e3210be2b1e90fd7b6f370b98d494aca5d2b67f21719070e6a602dde2a4783626f29434e08008f2b5a8d3f137823cf
According to previous reports of this malware, it uses a modular structure and the installation and configuration of those modules is downloaded via the BitTorrent protocol. In total, the malware exchanged DHT messages with over 5,805 hosts and sent 92 queries of the type announce_peers. As described in the DHT documentation, this query announces the downloading of a torrent on a specific port, in this case the port 29930/UDP (Figure 9).
Figure 9. announce_peer query specifying the torrent’s info_hash and port to be used during the download.
After the torrent downloading process finishes the scanning and exploitation process across the Internet started, attacking two ports: 23/TCP and 81/TCP. This is the total amount of connection data exchanged during that process:
Telnet: 3.78 MB
HTTP: 2.57 MB
Figure 10. Overall network statistics of the complete traffic capture of Scenario 18.
Correlating the time when the attacks started (Jul 25, 2018 07:28:50 CST) and the uTP data transfer packets we can see that the module delivery was performed by the IP 107.202.106.56 using the port announced previously (29930/TCP) at Jul 25, 2018 07:28:50 CST. Immediately after that the HTTP brute forcing started (Figure 11).
Figure 11. The attack to port 81/TCP starts right after the last uTP packet is delivered.
The malware was able to establish a considerable amount of connections to those services, even to compromise some devices as shown in Figure 12 where a bruteforce was carried out by the malware against a possible MikroTik router open to the Internet on port 23/TCP. We recorded the login attempts and logged the usernames/passwords used [7] during this scanning and brute forcing process over telnet using default credentials for routers or cameras.
Figure 12. MikroTik device compromised by the executed malware over Telnet.
Over HTTP on port 81/TCP, the malware used realistic User-Agents to perform HTTP GET requests to the IPs where it connected successfully. For example:
GET / HTTP/1.1 Host: 50.122.99.53:81 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7 Content-Length: 0
In these requests to HTTP we could see that the malware was using different sets of User-Agent strings:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7 Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Neither successful exploitation nor actual attack were seen over HTTP as no conversation was carried out from the servers where it was able to connect. This might indicate that the malware is looking for a specific type of device (or set of devices) to carry out the exploitation process.
One of the devices that this malware was able to breach was previously attacked and, during the course of its connection, was attacked by different sets of IPs as seen in Figure 13. This device in particular seems to have already been affected by the use of default credentials as it contains a “DEVICE HACKED - ACCOUNT admin HAD UNSAFE PASSWORD” note (a kind of attack which other users suffered as well [8]) and several login attempts from different sets of IP addresses, all while the malware was actively connected to the Telnet service.
Figure 13. The image shows the device being attacked mid-infection. Multiple IPs bruteforcing credentials via Telnet while the malware was logged into the device.
Conclusion
This scenario is part of the IoT23 Dataset. This analysis is about a Hajime malware sample, executed in a RaspberryPi in the Aposemat IoT Laboratory.
The file analysis revealed that the malware was designed to use BitTorrent’s DHT and NTP protocols. This is later confirmed during the network traffic analysis. This malware performs specific actions on the device to protect it from other malware. It also deletes itself, but persist in memory changing its name to telnetd.
From the network analysis it is possible to observe that the malware uses the DHT protocol and connects to a BitTorrent network, it scans port 23/TCP and port 81/TCP, and actively brute forces newly discovered devices.
This is an innovative malware as it presents a really fresh sets of ideas (ie. using BitTorrent’s DHT and uTP protocol) but keeping in use old ones (ie. self replication via Telnet or HTTP).
To summarize, some of patterns found in this malware execution are:
Massive amount of outgoing connections from both Telnet and HTTP (port 81/TCP)
Connections to torrent sites from the device:
router.utorrent.com
router.bittorrent.com
Sudden increase in BitTorrent related traffic:
TCP traffic in ports 6881-6889
DHT
uTP
Download data using uTP.
Follow the DHT packets to have a notion of which port was used.
Be on the lookout for incorrect busybox commands.
Files /tmp/ftpupload.sh and /tmp/ftpupdate.sh are symlinks to /dev/null.
Acknowledgement
This research was done as part of our ongoing collaboration with Avast Software in the Aposemat project. The Aposemat project is funded by Avast Software.
References
Sam Edwards, Ioannis Profetis. Hajime: Analysis of a decentralized internet worm for IoT devices. October 16th, 2016. Retrieved January 30 2020 from https://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdf.
Markus Oberhumer. 2020. GitHub, UPX (upx/src/conf.h). Retrieved January 30 2020 from https://github.com/upx/upx/blob/d7ba31cab8ce8d95d2c10e88d2ec787ac52005ef/src/conf.h#L342.
Juliusz Chroboczek. 2018. GitHub, BitTorrent DHT library (dht/dht.c). Retrieved January 30 2020 from https://github.com/jech/dht/blob/master/dht.c.
Rapid7 Labs. November 19th, 2014. R7-2014-18: Hikvision DVR Devices - Multiple Vulnerabilities. Retrieved January 30 2020 from https://blog.rapid7.com/2014/11/19/r7-2014-18-hikvision-dvr-devices-multiple-vulnerabilities/
Pierre Kim. March 8th, 2017. Multiple vulnerabilities found in Wireless IP Camera (P2P) WIFICAM cameras and vulnerabilities in custom http server. Retrieved January 30 2020 from https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html.
Andrew Loewenstern, Arvid Norberg. January 31st, 2008. DHT Protocol. Retrieved January 30 2020 from http://www.bittorrent.org/beps/bep_0005.html.
Stratosphere Labs. Retrieved February 4th 2020 from https://mcfp.felk.cvut.cz/publicDatasets/IoT-23-Dataset/IndividualScenarios/CTU-IoT-Malware-Capture-9-1/Linux.Hajime.username-password-list.txt.
kojikabuto. Feb 08, 2018. DEVICE HACKED. Retrieved January 30 2020 from https://forum.mikrotik.com/viewtopic.php?t=130572#p641164.