This blog post was authored by Lisandro Ubiedo (@_lubiedo) on 2020-03-09.
This post is a continuation of the IoT-23 In Depth series based on the IoT-23 Dataset, the first dataset of malicious and benign IoT network traffic, that consists of 23 scenarios [1]. In this blog post we provide an analysis of Scenario 9 [2], CTU-IoT-Malware-Capture-60-1. This malware sample is called Gafgyt. This variant is an IoT malware family capable of different types of DDoS attacks and exploits vulnerabilities in other devices, such as routers, to expand its botnet which has been seen attacking gaming servers [3].
The SHA256 hash of the malware sample executed is a3e04666349c92cf468657325c1a53ceb7eb7b2906b8cb27baba14f49083a3c1 [4]. VirusTotal identified the malware as Linux.Gafgyt, and gave it a score of 37/55 (meaning that 37 out of 55 engines detected this file) [5]. The sample was executed on a RaspberryPi 3+ (ARMv7) with Raspbian OS. The timeline of the traffic capture for this malware is:
Fri Sep 20 01:40:41 CEST 2019: Traffic capture started.
Fri Sep 20 01:43:47 CEST 2019: Malware executed.
Fri Sep 21 01:40:20 CEST 2019: Traffic capture ended.
Quick Sample Analysis
The malware sample is an 32-bit ELF ARM executable, statically linked,neither packed nor obfuscated. All binary symbols like functions and variable names are still intact and no anti-reversing technique was used. This malware sample has 372 procedures in total and some of those (ie. initConnection or processCmd) were already analyzed in our previous post covering Hakai [6], which is another Gafgyt variant. According to the strings found inside the binary, this Gafgyt variant is called Arbiter 1.0.
Upon execution the malware tries to open /etc/rc.d/rc.local or /etc/rc.conf, depending on the existence, and writes an entry for the system to execute itself at boot time to maintain persistence in the device. Then, it calls getOurIP() described in our previous post [6] and fork to create a child which will continue with the rest of the actions taken by the bot.
After that, it will change directories to root and ignore the SIGPIPE signal in order to avoid being terminated if a connection socket was suddenly closed. Then it will call one of the first and most important functions: initConnection() (also covered before [6]). This function is the responsible for establishing the connection between the C&C server (command and control) and the bot, that will allow the C&C server to send commands to the bot. In this sample, the malware is using this C&C server information:
Server: 102.165.48.81
Port: 17769
Whois
inetnum: 102.165.48.0 - 102.165.55.255 netname: HEFICED-CLOUD-SERVERS descr: Digital Energy Technologies Limited country: ZA admin-c: ZV1-AFRINIC tech-c: ZV1-AFRINIC status: ASSIGNED PA remarks: Abuse email: abuse@heficed.com mnt-by: DAL1-MNT source: AFRINIC # Filtered parent: 102.165.0.0 - 102.165.63.255 person: Zilvinas Vaickus address: Le Mans Building address: 57 Sloane Street address: Johannesburg address: South Africa address: Johannesburg address: Other phone: tel:+27-10-595-1279 nic-hdl: ZV1-AFRINIC mnt-by: GENERATED-YXS5HMAE56ZTVO08UH7F93C6SAW8SPHZ-MNT source: AFRINIC
This C&C server is still active at the time of writing this blog post and, as we will see later, the malware was able to connect to the server successfully.
Immediately after the connection is established, the malware sends a detailed banner (Figure 1) containing information about the infected device:
Build
IP
Bot Version
Endian Type
Online CPU's
Total MB of RAM
Specific OS
Type of OS
Figure 1. Information about the device is collected and sent to the C&C. This information is collected, mostly, using shell commands.
After sending the necessary data to the C&C, the malware will start receiving data from the server. Three commands that will accept are: PING, DUP and !* <cmd>. PING will work as the PING message works on IRC (Internet Relay Chat) where when the bot receives a PING message then it will respond with a PONG in order to confirm that it is still alive. DUP will create another fork of the bot.The other is a combination of the character !* followed by one of these commands:
PING
Same as previously described.
TABLE
Returns the maximum amount of file descriptors that can be opened.
UPDATE
Will update itself. More on this later (Figure 2).
TELNET
Accepts: ON/OFF parameter.
Executes TelnetScanner() and starts telnet scanning across the internet. More on this later.
GETPUBLICIP
Get current bots public IP address.
UDP
UDP flooding attack.
Accepts a max of 65500 bytes of data.
TCP
TCP flooding attack.
TCP flags can be set if specified in a comma separated manner: SYN, ACK, PSH, RST, FIN, XMAS (which means all TCP flags set).
HTTP
HTTP flooding attack.
CNC
Connects to specified server C&C server.
This command could be used as a way to count bots.
STD
STD flooding attack, similar to UDP flooding.
Packet length is 65 bytes.
STOP
Stop current attacks from the bot.
SELFDESTRUCT
Kill current instance.
Figure 2. The UPDATE command downloads a new shell script to update the malware binary.
The UPDATE command tries to check if there is any shell available and then it will change directories to /tmp and download a shell script that will retrieve an updated version of the malware itself. The malware is then executed and the shell script removed to complete this update process.
The TELNET command will start or stop the process of scanning the whole internet for devices using weak or default credentials (username/password). To get a new host it will call GetRandomPublicIP() to generate a random IP address. If a successful telnet connection is made then the malware will execute a shell commands to replicate itself in the new host and expand its botnet (Figure 3). It will try to use different protocols like HTTP, TFTP and FTP to retrieve those shell scripts used during replication.
Figure 3. Once connected to a telnet service it will execute a shell script to drop new malware. IP 51.254.145.97 is now defunct and not working.
On each command executed the bot will run two functions: UpdateNameSrv() and CleanD(). First function will make sure that Google’s DNS servers are used during host name resolution by the device. And the second function will ensure that no traces of the bot can be seen, that firewalls rules are deleted and the firewall is down, and that no Perl or Python scripts are running (Figure 4).
Figure 4. Maintenance functions are run by the malware to ensure its existence in the device. First it will set DNSs to ensure proper hostname resolution and then clean its presence and environment.
Malware Traffic Analysis
During this capture [2] there were approximately 271 millions of packets transmitted in a rate of 3,139 packets per second, for a timespan of 24 hours. As mentioned before, the communication with the C&C server is done via port 17769/TCP to the IP 102.165.48.81, which still seems to be operational. There were 19661 packets transferred between the bot and the C&C, and 34 commands executed by the C&C to launch attacks using both TCP and UDP protocols:
| Amount of attacks | Attack type |
|---|---|
| 1 | TCP |
| 8 | STD (UDP) |
| 25 | UDP |
After the communication with the C&C begins and for a brief period of time, the bot starts receiving commands that can’t be recognized or are present in other variants of this malware [7] (Figure 5). Around Sep 20 2019 at 02:04 CEST, the malware received a PHONE ON and SCANNER commands (both not present in this variant either), it responded with the banner, and then the C&C server sent the !* UDP command to start a UDP flooding attack against the IP address 1.3.3.7 and port 80. This attack is was immediately stopped which can indicate that it was a test to confirm if the bot is functional and start with the PING / PONG exchange to ensure the bot is alive (Figure 6).
Figure 5. Unknown commands are sent to the malware by the C&C.
Figure 6. Active communication between the C&C and the malware. It starts executing attacks against different IPs using different network protocols.
The C&C executed a vast amount of attacks against different ports/IPs in this 24 hours period:
| Attacks Executed | Destination Port | Flooding Type |
|---|---|---|
| 1 | 53569 | UDP |
| 1 | 55964 | UDP |
| 1 | 62336 | STD |
| 1 | 62336 | TCP |
| 1 | 62654 | STD |
| 1 | 65528 | STD |
| 2 | 111 | STD |
| 2 | 9306 | UDP |
| 3 | 80 | STD |
| 6 | 9307 | UDP |
| 15 | 80 | UDP |
And attacked different sets of IP addresses:
105.227.195.***:9306 14319118 bytes / 14319118 total packets 167.114.29.***:62654 25052300 bytes / 385420 total packets 172.58.99.***:65528 65458250 bytes / 1007050 total packets 173.171.99.***:80 1124406 bytes / 1124406 total packets 184.103.250.***:111 186169230 bytes / 2864142 total packets 24.50.227.***:9307 369452 bytes / 369452 total packets 47.41.252.***:55964 977074 bytes / 977074 total packets 58.162.205.***:9307 3602251 bytes / 3602251 total packets 67.4.165.***:111 421758090 bytes / 6488586 total packets 68.235.134.***:9307 16986360 bytes / 16986360 total packets 75.152.33.***:53569 91360 bytes / 91360 total packets 75.183.55.***:9307 4840844 bytes / 4840844 total packets 75.64.183.***:9307 4806136 bytes / 4806136 total packets 76.26.2.***:9306 346673 bytes / 346673 total packets 78.90.44.***:80 212301700 bytes / 3266180 total packets 83.213.83.***:80 78588380 bytes / 1209052 total packets 90.103.255.***:80 962347230 bytes / 14805342 total packets 98.196.62.***:9307 2150076 bytes / 2150076 total packets 162.248.88.***:62336 13097760 bytes / 201504 total packets 47.37.202.***:80 24673774 bytes / 24673774 total packets 99.39.252.***:80 12513413 bytes / 12513413 total packets 68.206.48.***:80 150507428 bytes / 150507428 total packets
These attacks sled to 2.15 gigabytes of data sent and 267,535,641 total packets transmitted. There was no relationship between the times when the attacks were executed and stopped, using the STOP commands previously described, and that might be a sign that there was no automated process executing those flooding commands.
Something that comes up after analyzing STD floods is that random strings were used as data sent within the UDP package (Figure 7). Also, these packages are of a fixed length of 65 bytes.
Figure 7. UDP packets send in one of the STD flooding attacks. Length is always the same but data changes randomly.
In the course of this traffic capture there was no telnet scanning process and no other interaction from the C&C besides the network flooding attacks. There were some commands coming from the C&C that were not recognized by the malware which could indicate that other types of bots communicate with the server.
Conclusion
This scenario is part of the IoT23 Dataset [1]. This analysis is about a Gafgyt malware sample, executed in a RaspberryPi in the Aposemat IoT Laboratory.
The binary analysis showed that the malware accepts different sets of commands and grows the botnet by attacking weak or default passwords in Telnet services across the Internet. Also revealed that it performs actions to hide its presence in the system and to avoid losing functionality.
The network traffic analysis showed that, in the beginning, unknown commands were sent to the bot and at one point became functional, attacking different sets of public IP addresses using both TCP and UDP protocols.
To summarize, some of patterns found in this malware execution are:
Connection to C&C upon execution:
Server: 102.165.48.81
Port: 17769
An script called njs.sh is present on the /tmp folder, if updating process is executed.
wget executed to download the script from http://102.165.48.81/njs.sh
Malware executes a cleaning process to erase traces:
/bin/netstat binary is removed.
Several files from /var/* and /tmp/* and ${HOME}/.bash_history go missing.
IPTables rules were flushed and service is stopped.
Python and Perl processes are killed.
Telnet traffic increases
Connections done across the Internet to random IP addresses.
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
Stratosphere Labs (2020, January 22). Aposemat IoT-23: A Labeled Dataset With Malicious And Benign IoT Network Traffic. Retrieved February 25, 2020, from https://www.stratosphereips.org/blog/2020/1/22/aposemat-iot-23-a-labeled-dataset-with-malicious-and-benign-iot-network-traffic
Stratosphere Labs (2020, January). CTU-IoT-Malware-Capture-60-1. Retrieved February 25, 2020, from https://mcfp.felk.cvut.cz/publicDatasets/IoT-23-Dataset/IndividualScenarios/CTU-IoT-Malware-Capture-60-1/
Danny Palmer, ZDNet (2019, October 31). This aggressive IoT malware is forcing Wi-Fi routers to join its botnet army. Retrieved February 26, 2020, from https://www.zdnet.com/article/this-aggressive-iot-malware-is-forcing-wi-fi-routers-to-join-its-botnet-army/
Stratosphere Labs (2020, January). CTU-IoT-Malware-Capture-60-1. Retrieved February 26, 2020, from https://mcfp.felk.cvut.cz/publicDatasets/IoT-23-Dataset/IndividualScenarios/CTU-IoT-Malware-Capture-60-1/a3e04666349c92cf468657325c1a53ceb7eb7b2906b8cb27baba14f49083a3c1.zip
VirusTotal (2019, November 12). Retrieved February 26, 2020, from https://www.virustotal.com/gui/file/a3e04666349c92cf468657325c1a53ceb7eb7b2906b8cb27baba14f49083a3c1/detection
Lisandro Ubiedo, Stratosphere Labs (24 February, 2020). IoT-23 In Depth: CTU-IoT-Malware-Capture-8-1. Retrieved February 26, 2020, from https://www.stratosphereips.org/blog/2020/2/24/iot-23-in-depth-ctu-iot-malware-capture-8-1
Amir Zali, Fortinet Threat Research (20 January, 2017). Linux Gafgyt.B!tr Exploits Netcore Vulnerability. Retrieved March 2, 2020, from https://www.fortinet.com/blog/threat-research/linux-gafgyt-b-tr-exploits-netcore-vulnerability.html