This blog post was authored by Kamila Babayeva (@_kamifai_) and Sebastian Garcia (@eldracote).
The RAT analysis research is part of the Civilsphere Project (https://www.civilsphereproject.org/), which aims to protect the civil society at risk by understanding how the attacks work and how we can stop them. Check the webpage for more information.
This is the second blog of a series analyzing the network traffic of Android RATs from our Android Mischief Dataset [more information here], a dataset of network traffic from Android phones infected with Remote Access Trojans (RAT). In this blog post we provide the analysis of the network traffic of the RAT02-DroidJack v4.4 [download here].
RAT Details and Execution Setup
The goal of each of our RAT experiments is to use the software ourselves and to execute every possible action while capturing all the traffic and storing all the logs. So these RAT captures are functional and were used in real attacks.
The DroidJack v.4.4 RAT is a software package that contains the controller software and builder software to build an APK. It was executed on a Windows 7 virtual machine with Ubuntu 20.04 as a host. The Android Application Package (APK) built by the RAT builder was installed in the Android virtual emulator called Genymotion with Android version 8.
While performing different actions on the RAT controller (e.g. upload a file, get GPS location, monitor files, etc.), we captured the network traffic on the Android virtual emulator.
The details about the network traffic capture are:
The controller IP address: 147.32.83.253
The phone IP address: 10.8.0.57
UTC time of the infection in the capture: 2020-08-01 14:10:43 UTС
Initial Communication and Infection
Once the APK was installed in the phone, it directly tries to establish a TCP connection with the command and control (C&C) server. To connect, the phone uses the IP address and the port of the controller specified in the APK. In our case, the IP address of the controller is 147.32.83.253 and the port is 1337/TCP. Also, DroidJack uses the port 1334/TCP as a default port and the phone connects to it later too. The controller IP 147.32.83.253 is the IP address of Windows 7 virtual machine in our lab computer, meaning that the IP address is not connected to any indicator of compromise (IoC).
Figure 1. A 3-way handshake started by the phone to establish TCP connection with the C&C controller.
In Figure 1 we can see that the connection was established, but the C&C server was resetting it several times. After a while a successful 3-way handshake was performed and the connection was established, the C&C sends the next packet with following data:
Figure 2. Data sent by the C&C after establishing the first TCP connection with the phone.
The phone replies with some initialization parameters such as its phone model, Android version, and other parameters in plain text.
Figure 3. Data sent by the phone with initialization parameters.
Communication over 1337/TCP
After establishing the communication over port 1337/TCP, there is a sequence of three NULL (00) bytes in the data of both packets, as shown in Figure 2 and Figure 3. This sequence is followed by the hexadecimal number 0x3C, which represents the packet length in its decimal form, and after that the phone sends the delimiter byte 0x03. The amount for the packet length does not include bytes for the NULL sequence and the byte for the packet length. The following is an example of the bytes in hexadecimal as seen from the packet sent by the phone in the Figure 3:
Figure 4. Bytes sent from the phone to the C&C controller in one packet, including how we found the format.
In Figure 4, the actual length of the packet is 64. The byte 0x3C is 60 in a decimal format, which is exactly the length of the packet without the byte for packet length 0x3C (1 byte) and the sequence of NULL characters (3 bytes).
In the small packets of length 1 or 2, like in Figure 2 or in the heartbeat in Figure 6, there are no delimiters. Thus only packets with data of more than 2 bytes sent from the C&C and the phone over 1337/TCP has the following format:
{00 00 00}{data length}{delimiter}{data in plain text}Figure 5. The format of packets sent from the C&C and the phone as part of the custom protocol used by the RAT.
After sending phone parameters, the phone is waiting for the command from the controller. While waiting for the command, the phone and the C&C maintain a heartbeat, which in this case is a couple of packets in both directions inside the same connection. They exchange packets every 8 seconds.
Figure 6. The heartbeat between the C&C and the phone.
After some time, when it is requested by the botmaster, the C&C server sends a packet with the command to the phone. The command is ‘File Voyager’, which aims to search through the file system of the phone. In the C&C software, the command ‘File Voyager ’ looks like this:
Figure 7. The command ‘File Voyager’ in DroidJack v4.4 C&C software.
Figure 8 shows an example of this order “File Voyager”, that is sent unencrypted.
Figure 8. Command ‘File Voyager’ sent from the C&C after the heartbeat.
The commands from the C&C server to the phone seem to be predefined with a specific number. From Figure 8, number 20 might define the command ‘File Voyager’ and it is followed by some extra parameters (false#/~#0194074 5667#.). The character ‘#’ might be a separator between parameters. As a reply to the C&C command, the phone sends back:
Figure 9. The phone’s reply on the command ‘File Voyager’ sent by the C&C.
Communication over 1334/TCP
The reply of the phone to the C&C in Figure 9 is an acknowledgement for the received command. The actual phone reply with data is sent in a different connection. For each new command received from the C&C, the phone establishes a new TCP connection over port 1334/TCP, sends the data and closes the connection. Figure 10 shows a new connection over 1334/TCP to reply on the command in Figure 8.
Figure 10. The phone replies to the command sent by the C&C in port 1337/TCP (shown in Figure 8) with data over another connection on port 1334/TCP.
The packets in the connection 1334/TCP do not have any format as in Figure 5, the data is sent in the plain text:
Figure 11. Packet sent from the phone to the controller over 1334/TCP.
Communication over 1337/UDP
Even though there is a heartbeat over port 1337/TCP, the phone sends UDP packets to the С&C over port 1337 every 20 seconds.
Figure 12. UDP packets from the phone to the C&C server sent every 20 seconds over port 1337/UDP.
The data inside UDP packets is in the plain text:
Figure 13. Example data inside the UDP packets on port 1337/UDP sent from the phone to the controller.
Long Connections
If we open the Conversations -> statistics -> TCP menu in Wireshark, as shown in Figure 14, a lot of connections between the phone and the controller are over port 1334/TCP (new C&C - new connection) and only a few are over 1337/TCP. The connections over 1337/TCP are usually long, e.g. 1548.2056 seconds (approximately 40 minutes) or 1413.3981 seconds (approximately 31 minutes). This indicates that the connections between the phone and the controller are kept for long periods of time in order to answer fast.
Figure 14. Top connections between the phone and the controller from Wireshark -> Statistics -> Conversations -> TCP. It can be noted the long duration of the main connections.
Detecting C&C using Slips
Slips is a Python Intrusion Detection and Prevention system that uses machine learning to detect malicious behaviours in the network traffic of the devices. Slips is an open-source tool and can be installed from here.
After Slips is run on the DroidJack v4.4 packet capture, Slips creates a profile per each IP that appeared in the traffic. Each profile contains flows sent from this IP. Each flow is described with a specific letter which description can be found here. Considering that, Slips detects the C&C channel over 1334/TCP. The behavioral model of the connection between the phone and C&C is in Figure 15, and Slips’ machine learning module called LSTM detecting C&C channel is shown in Figure 16.
Figure 15. Behavioral model of the connection between the phone and C&C over 1334/TCP.
Figure 16. Alert from slips that it detects a C&C channel over port 1334/TCP using a machine learning LSTM neural network. The LSTM uses the letters shown in Figure 15.
Slips did not detect periodic connection over 1337/UDP because the LSTM module focuses on TCP. But from the behavioral model of the connections over 1337/UDP shown in Figure 17, we can conclude that the model is periodic and most of connections are of a small size.
Figure 17. Behavioral model created by Slips for the connection between phone and C&C over 1337/UDP.
Conclusion
In this blog, we have analyzed the network traffic from a phone infected with DroidJack v4.4 RAT. We were able to decode its connection and found the distinctive features as long duration or heartbeat. The DroidJack v4.4 RAT does not seem to be complex in its communication protocol and it is not sophisticated in its work.
To summarize, the details found in the network traffic of this RAT are:
The phone connects directly to the IP address and ports specified in APK (default port and custom port).
Some connections over port 1337/TCP between the phone and the controller are long, i.e. more than 30 minutes.
There is a heartbeat between the controller and the phone over 1337/TCP.
Packets sent from the phone and the C&C over port 1337/TCP have a form of {00 00 00}{data length}{delimiter}{data in plain text}.
A new connection over 1334/TCP is established when a new command is received from the C&C.
The phone sends UDP packets to the C&C every 20 seconds.
Packets sent from the phone to the C&C over 1334/TCP and 1337/UDP are in plain text.
Biographies
Kamila Babayeva
Kamila Babayeva is a 20 years old and third-year bachelor student in the Computer Science and Electrical Engineering program at the Czech Technical University in Prague. She is a researcher in the Civilsphere project, a project dedicated to protecting civil organizations and individuals from targeted attacks. Her research focuses on helping people and protecting their digital rights by developing free software based on machine learning. Initially, she worked as a junior Malware Reverser. Currently, Kamila leads the development of the Stratosphere Linux Intrusion Prevent System (Slips), which is used to protect the civil society in the Civilsphere lab.
Sebastian Garcia
Sebastian Garcia is a malware researcher and security teacher with experience in applied machine learning on network traffic. He founded the Stratosphere Lab, aiming to do impactful security research to help others using machine learning. He believes that free software and machine learning tools can help better protect users from abuse of our digital rights. He researches on machine learning for security, honeypots, malware traffic detection, social networks security detection, distributed scanning (dnmap), keystroke dynamics, fake news, Bluetooth analysis, privacy protection, intruder detection, and microphone detection with SDR (Salamandra). He co-founded the MatesLab hackspace in Argentina and co-founded the Independent Fund for Women in Tech. @eldracote. https://www.researchgate.net/profile/Sebastian_Garcia6