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 third 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 RAT04-SpyMAX [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 SpyMAX 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 7.
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.181
The phone IP address: 10.8.0.93
UTC time of the infection in the capture: 2020-08-27 17:34:42 UTС
Initial Communication and Infection
This research started with the execution of the RAT in our phone. Once the APK was installed in the phone, it directly tries to establish a TCP connection with the command and control (C&C) server. The phone uses the IP address and the port of the controller that we specified in the APK. In particular, the IP address of the controller was 147.32.83.181 and the port was 8000/TCP. The controller IP address 147.32.83.181 is the IP address of a Windows 7 virtual machine in our lab computer, meaning that the IP address is not connected to any indicator of compromise (IoC).
Figure 1 shows how the phone initializes a 3-way TCP handshake to establish the connection between the phone and the C&C. The connection was successfully established, but there were several retransmitted packets at first.
Figure 1. A 3-way handshake started by the phone to establish TCP connection with the C&C.
Decode packets from the phone
After the C&C connection was established, the phone sends a packet with the data shown in Figure 2:
Figure 2. Data sent by the phone after establishing the TCP connection with the C&C. It is shown a hex representation to the left and ASCII representation to the right.
In this packet sent from the phone it can be found the hex magic number for the gzip compression format: 1f 8b. This gzip magic number was seen twice in the packet (Figure 3). Before the first gzip magic number, there are two numbers sent, 22 and 91, which are 32 32 and 39 31 in the hex form respectively, with 00 byte as a delimiter. The sum of these numbers (22 and 91) and the number of bytes used for these numbers and delimiters represents the data length of the packet.
Figure 3. The structure of the first packet sent by the phone. Here it can be seen the data length, gzip magic numbers and delimiters.
The actual data length of the packet is 119, which is the sum of the numbers before the gzip magic number (22 and 91), and the bytes used for these numbers and delimiters (6 bytes): 22+91+6 = 119. If we delete the numbers before first gzip magic number and decompress the data using a tool like CyberChef (recipes “From Hexdump” and “Gunzip”), the decompressed data is:
Figure 4. Decompressed data from the first packet sent by the phone. Done using the CyberChef tool.
Based on this discovery we found that throughout the whole connection, the victim phone sends data to the C&C in the format shown in Figure 5:
{data length}{gzip magic number}{compressed data}
Figure 5. Format structure of all the packets sent from the victim phone to the C&C controller.
Decode packets from the C&C
The C&C sends to the phone a series of packets that contains system commands and small APKs for each of the system commands. These system commands together with APKs aim to control the phone, because the initially generated APK put in the phone is only a dropper. This means that the main APK executed the malware and the phone gets infected by the APKs sent by the C&C after establishing the connection. As far as we know, this is a new type of behavior that would show a large amount of APK files being sent to a phone.
“Each time the C&C wants to send a new command to the phone, it sends a new APK file.”
After establishing the connection between the phone and the C&C, the C&C sends 8 system commands and 8 APKs in total. Those commands and APKs aim to control the phone’s applications, file system, microphone, terminal, calls, sms, contacts and information.
Figure 6 shows how the C&C sent the system command ‘Calls’ and a new APK that is clearly seen given that there is a new AndroidManifest.xml file sent in the traffic. The system command and the AndroidManifest.xml were analyzed using CyberChef.
Figure 6. The C&C sent the command ‘calls’ and an APK to fulfil that request. The AndroidManifest.xml content can be seen in the traffic. The analysis was done in the CyberChef tool.
We analyzed the APK attached in the packet by saving it and reversing it. The analysis shows that the APK for the command ‘calls’ modifies the class CallLogs.Calls [https://developer.android.com/reference/android/provider/CallLog.Calls] in the Android phone. The class CallLogs.Calls contains recent calls in the phone. Figure 7 shows an example of the ‘delete’ function from this APK source code. The ‘Delete’ function uses the class CallLog.Calls to delete call logs in the phone.
Figure 7. The ‘Delete’ function from the source code of the small APK sent to the victim phone in order to execute the command ‘calls’. It is designed to manipulate call logs in the phone.
C&C COMMUNICATION
After all the commands were successfully sent to the victim phone, the C&C and the phone exchange the following packets, as shown in Figure 8. These packets might be the heartbeat between the C&C and the phone to check if both of them are active. The heartbeat stops when the new command is sent from the C&C.
Figure 8. The exchange of packets between the C&C and the phone after C&C sends all necessary plugins and APKs.
After the packets from Figure 8 were sent, the C&C sends its first command ‘Info’. This command aims to retrieve the information about the phone. The command is sent in the same format as in Figure 5, so it was possible to decompress it Figure 9 shows the compressed and decompressed packet. This Figure shows that the command ‘Info’ sent by the C&C has the probably following structure:
1 x0F0x plugens.angel.plugens.info
x0F0x method
x0F0x 1GRU802
x0F0x info
x0D0x xnJ5u
x0D0x mlyUg
null
Figure 9. The command ‘Info’ as sent from the C&C to the phone. After decompression a structure can be seen.
The phone replies to the command ‘Info’ with its own packet and a similar format. This packet after decompression shows that the phone sends the model of the phone, the Android version, the text ‘Hacked’ and ‘a2fb4aa7-befb-4072-a025-6a2379e5c705’ that is the UUID. Figure 10 shows the result of the UUID decoder on the given string ‘a2fb4aa7-befb-4072-a025-6a2379e5c705’ . The result is available [here] The given UUID is of a version 4, i.e randomly generated. The C&C might UUID to mark infected phones and distinguish between them. Figure 11 shows the decompressed data from the packet.
Figure 10. UUID decoder tool decodes the string ‘a2fb4aa7-befb-4072-a025-6a2379e5c705‘ sent from the phone. This string is UUID version 4, i.e. randomly generated.
1GRU802¬í..ur..[B¬ó.ø..Tà...xp..X<Object>
x0D0x Samsung Galaxy S8
x0D0x Linux
x0D0x Nougat7.0
x0D0x v2.0
x0D0x Hacked
x0D0x a2fb4aa7-befb-4072-a025-6a2379e5c705
x0D0x null
x0D0x
Figure 11. Decompressed data from the phone reply on the C&C command ‘Info’.
Together with these parameters, the phone also sends its background picture. This image can be rendered with the CyberChef tool:
Figure 12 The rendered background image from the phone after the C&C command ‘Info’. The image was rendered using the CyberChef tool.
After the phone sent the parameters and background, they are displayed in the C&C web interface (Figure 13).
Figure 13. Phone’s parameters and background image sent to the C&C to display in the C&C interface.
Another example of the C&C commands is ‘Files Manager’, which aims to search through the file system of the phone. The command sent from the C&C is shown in Figure 14:
Figure 14. Decompression of the C&C command ‘Files Manager’.
This message can be structured as
1 x0F0x plugens.angel.plugens.files
x0F0x method
x0F0x 5XBL990
x0F0x files
x0D0x get0null
The phone replies to the C&C command ‘File Manager’ with all the directories in its home folder. Figure 15 shows decompressed data.
Figure 15. Decompressed data of the packet sent from the phone as a reply to the C&C command ‘Files Manager’.
The response from the phone includes its folders, for example “/storage/emulated”, “/Music”, etc.
The C&C commands ‘Info’ and ‘Files Manager’ are performed in the same connection that was established initially between the C&C and the phone. This means that the RAT reuses connections for the commands, and that one connection can have multiple purposes. According to Figure 1, the connection used for all these commands was:
10.8.0.93 41512 147.32.83.181 8000 TCP
However, the phone opens a new connection for the commands that require sending large amounts of data, such as upload/download files, live microphone stream, taking photos or videos. The connection goes to the same C&C IP (in our case 147.32.83.181), same port (in our case 8000), but from a different source port from the phone. In the case of new connections, the data sent by the phone is compressed, as shown in Figure 5, and the data sent from the C&C is in plain text. After each command finishes, its connection closes. The communication between the phone and the controller continues in the initial connection.
As an example, the C&C sends the command ‘Files Manager - Upload’ that aims to upload the file from the C&C to the phone. In our experiment, an mp3 sound was sent. The communication for the command ’File Manager - Upload’ followed this structure:
The C&C sends the command ‘File Manager - Upload’ in the initial connection, as in Figure 16.
The phone opens a new connection, as in Figure 17.
The C&C sends the file in plain text, as in Figure 18.
The connection for the command ‘File Manager - Upload’ closes, and the communication between the C&C and the phone continues in the initial connection.
Figure 16. Decompressed C&C command ‘Files Manager - Upload’ in the main connection between the phone and the C&C.
39905 2020-08-27 18:31:32 10.8.0.93 41580 147.32.83.181 8000 TCP 60 41580 → 8000 [SYN] Seq=0 Win=65535 Len=0 MSS=1361 SACK_PERM=1 TSval=2963245 TSecr=0 WS=64
Figure 17. The new connection between the C&C and the phone to send the file in the command ‘File Manager - Upload’.
Figure 18. The data exchange between the phone and the C&C. The data from the phone is red, the data from the C&C is blue.
HEARTBEAT
While waiting for the commands from the C&C, the phone and the C&C have a heartbeat connection. They exchange packets to make sure both sides are alive. The example of the packet sent from the C&C and the example of the packet sent from the phone are shown in Figure 19.
Figure 19. The packets sent from the phone and the C&C when doing the heartbeat.
Besides the heartbeat between the phone and the C&C, the phone sendsICMP messages, specifically “echo ping” requests. These ICMP messages are sent every 45 seconds. Examples of these ICMP messages are shown in Figure 20.
Figure 20. The ICMP messages sent from the phone to the C&C every 45 seconds.
LONG CONNECTION
If we use the Wireshark tool to analyze all the traffic, we can open the menu “Conversations”, then “Statistics”, then “TCP”. As shown in Figure 21, there are several connections to the C&C 147.32.83.181 over port 8000/TCP. The longest connection established between the C&C and the phone is 5854.6363 seconds long (approximately 97 minutes). This indicates that the connections between the phone and the controller are kept for long periods of time in order to answer fast.
However, it is important to notice that there are even longer normal connections with durations of 8258.6875 seconds (approximately 137 minutes). This is the connection from the phone during normal operation to the IP address 157.240.30.34, which belongs to Facebook services.
Figure 21. Top connections from the phone from Wireshark -> Statistics -> Conversations -> TCP.
Conclusion
In this blog we have analyzed the network traffic from a phone infected with SpyMAX RAT. We were able to decode its connection and found the distinctive features. SpyMAX RAT has a complex structure compared to other RATs.
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).
The main APK is a dropper that installs small APKs that aim to control the phone’s applications, file system, microphone, terminal, calls, sms, contacts and information.
Some connections over port 8000/TCP between the phone and the controller are long, i.e. more than 90 minutes.
There is a heartbeat between the controller and the phone over 8000/TCP.
Packets sent from the phone and the C&C over port 8000/TCP have a form of {data length}{gzip magic number}{compressed data}.
A new connection over 8000/TCP but with a different phone source port is established when a new command from C&C that requires an exchange large amount of data is received.
The phone sends ICMP messages to the C&C every 45 seconds.
Thanks to Lisandro Ubiedo (@_lubiedo) for the help analyzing the APK files.
Thanks to Leyla and Laura Babayevas (@BabayevaLil) for drawing the blog cover picture.
Biographies
KAMILA BABAYEVA
SEBASTIAN GARCIA
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 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