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 eighth 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 RAT06-Saefko [download here]. The previous blogs analyzed Android Tester RAT, DroidJack RAT, SpyMax RAT, AndroRAT, HawkShaw, AhMyth and Command-line AndroRAT.
RAT Details and Execution Setup
The procedure followed for each of our RAT experiments is to configure and execute the RAT software and to do every possible action while capturing all traffic and storing all logs. These RAT captures are functional and used as in real attacks.
The Saefko RAT is a software package that contains the controller software and builder software to create an APK. We executed the builder on a Windows 7 Virtualbox virtual machine with Ubuntu 20.04 as a host. The Android Application Package (APK) built by the RAT builder was then installed in an 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 machine running the Android virtual emulator. The network traffic was captured on the Android virtual emulator network interface.
Configuration parameters of the C&C Controller and the phone victim:
Controller:
IPv4: 192.168.131.1
IPv6: 2001:718:2:903:f410:3340:d02b:b918
Link-Local IPv6: fe80::8052:f37c:25e9:69f0
Victim:
IPv4: 192.168.131.2
IPv6: 2001:718:2:903:b877:48ae:9531:fbfc
Link-local IPv6: fe80::2efc:36f:ce23:fac1
Details of the network capture pcap file:
First Packet of the Infection: 36728
UTC Time of the Infection: 2021-04-10 14:55:09
First connections from the infected phone
Compared to other analyzed RATs in the Android Mischief Dataset, where the first malicious connection from the victim phone is direct to the C&C server, in the case of Saefko RAT, the infected phone first connects to the webpage https://ipinfo.io/geo. The connection from the phone to the service ipinfo.io is displayed in Figure 1. The phone tries to retrieve the latitude and longitude of the victim’s device location according to its IP address. In the malicious APK, there is a function for this automatic action of ‘getting the location’, called GetLocationInfo(), which is responsible for this action as shown in Figure 2.
1618066509.311319 C1hlpv4rTNvRlsA1k1 192.168.131.2 55536 216.239.36.21 443 ipinfo.io Figure 1. Zeek flow from the ssl.log that shows the connection form the victim’s device 192.168. to the ipinfo.io.
Figure 2. The APK function GetLocationInfo() retrieves the longitude and latitude of the victim’s device location based on the IP address by connecting to the site https://ipinfo.io/geo.
After retrieving the location information from the ipinfo.io service, the second malicious connection performed from the phone is the connection to the C&C online database (The Zeek flow is shown in Figure 3). The C&C uses a web hosting service called 000webhost.com to create an online database. Before starting our experiment, we have created a website on this hosting 000webhost.com with the name “experimentsas”. In our hosting website we installed the files “server.php” and “Saefko_db.db” provided by Saefko RAT software. This C&C database URL link “experminetsas.000webhost.com” was specified in the APK (Figure 4), so the victim phone knows where to connect.
1618066509.738157 CM6DFg4vphEr3CEc6g 2001:718:2:903:b877:48ae:9531:fbfc 39812 2a02:4780:dead:494b::1 443 TLSv12 experimentsas.000webhostapp.com
Figure 3. Zeek flow from the ssl.log file that summarizes the first connection from the infected phone to the C&C online database created by us for this experiment experimentsas.000webhostapp.com.
Figure 4. APK code with specifications of the database URL ‘https://experimentsas.000webhostapp.com/server.php’ and other necessary parameters.
A few seconds later, after establishing the first connection to the database, the victim established a second connection to the same online database, so there are two simultaneous connections established. Figure 5 shows the Zeek flow for the second connection to the online DB.
1618066510.358715 C82MTR16Hzvg4953R7 2001:718:2:903:b877:48ae:9531:fbfc 39814 2a02:4780:dead:494b::1 443 TLSv12 experimentsas.000webhostapp.com
Figure 5. Zeek flow from ssl.log file that summarizes the second connection to the C&C online database ‘experimentsas.000webhost.com’.
C&C methods to control the victim
Saefko RAT is the first RAT in the Android Mischief dataset version 2 that uses 3 types of connections to control the victim: (i) IRC channels, (ii) HTTP requests and (iii) a TCP connection directly to the C&C server. We will discuss each connection in detail.
Connection to IRC servers
Once the APK is installed and the C&C enters the control panel on the interface (example is shown in Figure 6), the victim connects to 5 IRC servers according to the APK function StartIRCClient() in Figure 7. These connections have a refresh rate set to 99,000 milliseconds, which is approximately 28 minutes. It means that every 28 minutes, the victim closes the connections with the current IRC servers and connects to 5 other IRC servers. We know that there are always 5 IRC servers connected, because of the for-loop increasing from 0 to 4 inclusive. The IRC servers are chosen from the list of IRC servers set up in the APK. Figure 8 shows several IRC servers presented in this list of total 99 IRC servers. For each of the chosen IRC server, the victim calls the function IRCInfo.GenerateIRCInfo() that aims to connect to IRC server with specific parameters such as IRC_SERVER, IRC_PORT and IRC_NICKNAME. This function is shown in Figure 9. After the list of 5 IRC servers with their parameters has been created, it is sent to the C&C online database by using the function update_server_informations (shown in Figure 10). The update to the online database is done so that the C&C controller will connect to the same IRC servers and will control the victim by sending IRC private messages.
Figure 6. The interface that the controller uses to execute C&C commands. The interface contains 3 tabs to separate the commands sent over IRC, HTTP and TCP. The tab for the C&C commands over IRC is command-line alike. The phone connects to three IRC servers listed in the beginning of Figure 6: irc.immortal-anime.net, irc.caelestia.net, irc.charrersweb.nl.
Figure 7. APK code that aims to establish a connection with an IRC server with specific parameters. The function generates a list of 5 IRC servers and sends it to the C&C database.
Figure 8. IRC servers listed in the APK code. The infected device connects to IRC servers from this list of 99 servers.
Figure 9. APK function GenerateIRCInfo() that aims to connect to an IRC server with specified parameters IRC_SERVER, IRC_PORT and IRC_NICKNAME.
Figure 10. APK function update_server_informations that sends the information about the victim’s connected IRC servers to the C&C.
After both the victim and the controller connect to the same IRC servers, the C&C is able to send the commands to the victim. The list of commands the C&C can perform is shown in Figure 11.
Figure 11. The list of C&C commands that can be executed over IRC channels.
As an example of the communication between the C&C and the phone over IRC channels, we show the communication in the IRC server chat.freenode.net. First, the phone performed a DNS lookup of the domain chat.freenode.net. Second, the phone established a connection with this IRC server after resolving its IP address. In Figure 12 it can be seen how the phone established a connection with this IRC server and then immediately terminated it.
Figure 12. Connection from the phone to the IRC server chat.freenode.net. The connection was established and immediately terminated.
Third, the phone reestablished the connection with IRC server chat.freenode.net (Figure 13) and sent a packet with the USER parameter to the IRC server. The victim connects to this IRC server with the randomly generated username fcsryk, as displayed in Figure 14. The user string for the infected device is generated by the function GetNickname() shown in Figure 15. The username and nickname the phone uses inside an IRC server are the same.
Figure 13. Reestablished connection from the infected device to the IRC server chat.freenode.net.
Figure 14. The packet with the USER command sent from the phone to the IRC server. The phone’s username is 6 letters long randomly generated string.
Figure 15. Function GetNickname() inside the APK code that randomly generates a 6 letters long string to create the nick of the user in IRC.
After the phone has successfully connected to the IRC server, there is a heartbeat between this IRC server and the phone (shown in Figure 16), This heartbeat is a typical behaviour of an IRC server. The heartbeat stopped after the C&C sent a private message to the phone over the IRC server with the command ‘location’. The packet with this C&C command ‘location’ is presented in Figure 17.
Figure 16. Ping and pong between the IRC server and the victim’s phone. The heartbeat continues until the C&C command is received.
Figure 17. The private message from the C&C with the command ‘location’. The top lines in the figure are the headers of the packet, the lower lines are the content According to the Internet Relay Chat field, the controller’s nick is zelvmd, the IP is 2001:718:2:903:f410:3340:d02b:b918 and it sends the data ‘SASENCODEbG9jYXRpb25UX1QxNjE4MDY2OTgxNjMw’.
From Figure 17, it can be seen that the controller’s nick inside the IRC server was zelvmd and the IPv6 address was 2001:718:2:903:f410:3340:d02b:b918. The data sent by the C&C was ‘SASENCODEbG9jYXRpb25UX1QxNjE4MDY2OTgxNjMw’. The data contains a string identifying Saefko: ‘SASENCODE’. The data after this string is bG9jYXRpb25UX1QxNjE4MDY2OTgxNjMw and is Base64 encoded. Using the command-line command base64 to decode this string, we have got the following:
$ echo 'bG9jYXRpb25UX1QxNjE4MDY2OTgxNjMw' | base64 -d$ locationT_T1618066981630Figure 18. Base64 decoded data sent by the controller to the phone in the IRC server using a private message, as part of the C&C command ‘location’.
The decoded data from the Figure 18 can be organized in the following structure:
location C&C command
T_T delimiter
1618066981630 timestamp
Figure 19. Structure of the C&C command ‘location’ sent to the phone over IRC.
Overall, every C&C command sent by the controller over IRC server has the following structure:
‘SASENCODE’+base64_encode(C&C command + ‘T_T’ + timestamp)
Figure 20. Structure of the C&C commands sent to the infected device over IRC.
After the phone received the C&C command ‘location’, it replied with 6 packets separated by a one second interval. The phone is connected to three IRC servers and it receives the command in all three of them (probably as redundancy backup), and then it answers with 6 packets to all three of them too. Figure 21 shows the encoded and decoded data field of the 6 packets sent as a reply to the C&C command ‘location’. The packets sent from the phone have the same structure as the packets sent from the C&C.
Figure 21. The phone’s 6 packets sent as a reply to the C&C command ‘location’. The packets from the phone follow the same structure as the C&C packets.
It is important to note that the phone is connected to several IRC servers simultaneously (Figure 22). The C&C commands to execute are sent to the phone through each connected IRC server as well as the replies from the phone are also sent to each of the connected servers:
Figure 22. The C&C commands are sent to each connected IRC server and the infected device replies to the C&C command in each server.
HTTP requests from the C&C
Besides IRC connections, the C&C controls the victim by sending HTTP requests to the phone with the commands. However, there are no HTTP requests seen in the traffic from the controller or in the IRC chat, meaning that the commands are sent over the C&C online database. The phone has an HTTP server implemented in the APK, which is unusual. The controller acts as a client that sends HTTP requests with C&C commands to execute, but the HTTP response might be sent back over the online database as well. The C&C commands possible to execute using HTTP requests are very limited, namely Message Box, Shell commands, Visit Webpage and Open TCP Connection. According to the configuration, these commands are queued and will be executed every 21 minutes, which is the refresh rate parameter. An example of queued C&C commands over HTTP is shown in Figure 23.
Figure 23. The queue of HTTP requests with C&C commands to be executed on the phone. These commands will be executed according to the refresh rate parameter set in the configuration folder.
These HTTP commands are also sent to the online database that was set up in this experiment. The connections from the phone and the controller to this database are over HTTPs that provides encrypted communication. It means that HTTP requests with C&C commands sent from the controller are encrypted and cannot be analyzed.
TCP connection to the C&C
A direct TCP connection established from the phone to the C&C gives the attacker more power to control the victim’s device. It allows the controller to send and receive large data such as photos, videos, audios, calls, messages, files, etc. Figure 24 shows the C&C interface with a list of the commands to perform over TCP.
Figure 24. A list with C&C commands that are possible to perform over TCP connection between the controller and the phone.
Due to the RAT code being of medium quality, several TCP connections with really little data exchange were established between the C&C and the phone (Figure 25). However, the C&C interface was not displaying these established TCP connections and did not allow the attacker to perform any C&C command. It explains why only the first connection has data exchange. Importantly, the amount of bytes sent from the infected device is much bigger than the response bytes. The other four connections have exactly the same amount of sent and received bytes. Moreover, the C&C was not able to close any of the connections with a 4-way termination handshake. Connections from Zeek’s conn.log in Figure 25 have flags RSTR and S1. RSTR means there was a rejection from the response IP address (in our case the C&C IP address) and S1 means the connection was opened and not closed.
id.orig_h id.orig_p id.resp_h id.resp_p proto conn_state orig_bytes resp_bytes
192.168.131.2 35690 192.168.131.1 8000 tcp RSTR 343220 1797
192.168.131.2 35728 192.168.131.1 8000 tcp RSTR 96 56
192.168.131.2 35730 192.168.131.1 8000 tcp RSTR 96 56
192.168.131.2 35732 192.168.131.1 8000 tcp S1 96 56
192.168.131.2 35736 192.168.131.1 8000 tcp S1 96 56
Figure 25. All the connections from the phone established with the C&C over port 8000/TCP. Due to poor code quality, some of the connections were established but without a big exchange of data and a termination with the RSTR state.
As an example of the controller operating over TCP, we will look at the first TCP connection between the phone and the C&C. After a successful 3-way TCP handshake (Figure 26), the C&C sent the first packet with encoded data, as displayed in Figure 27:
Figure 26. A 3-way TCP handshake to establish the connection over TCP/8000 between the phone and the controller.
eyJUeXBlIjoiSWRlbnRpZml5IiwiRGF0YSI6Im9xb2V6cWpyd2YifQFigure 27. The data field of the first packet sent from the C&C to the phone.
The data in Figure 27 is base64 encoded, the decoded text is {"Type":"Identifiy","Data":"oqoezqjrwf"}. The value of the ‘Type’ key is the command to be executed, in our case is ‘Identify’. "Oqoezqjrwf” might be the identification ID that the controller uniquely generates for each connected infected device.
The phone answers the command ‘Identity’ with 2 packets, shown in Figure 28 and Figure 29. The first packet defines the length of the data sent in the second packet. Byte 0x5C in hexadecimal format is 92 in decimal. The second packet is the actual base64 encoded response to the C&C command. The decoded data of this response will result into JSON format {"Data":{"ID":"6","RequestID":"oqoezqjrwf"},"Type":"Identification"}. “ID” defines an ordinal number of the connected device and “RequestID” is the ID given by the C&C. The data length of it being 92 bytes as it was defined in the first packet.
0000 00 00 00 5c ...\Figure 28. The first packet sent by the phone after receiving the C&C command. The data defines the length of the data sent in the next packet.
Figure 29. The data field of the second packet sent by the phone after receiving the C&C command. The data is base64 encoded.
The APK code with the function SendMessage that aims to send replies to the C&C commands is shown in Figure 30. The function produces two packets: (i) a packet with the length of the data and (ii) a packet with base64 encoded data.
Figure 30. Function sendMessage() in the APK code that aims to send the information from the phone to the C&C. The function sends two packets: (i) a packet with the data length of the next packet and (ii) a packet with the actual data.
The complete communication between the phone and the controller goes the same way:
The C&C sends the base64 encoded command.
The phone answers with two packets: the first packet with the hexadecimal representation of the data length in the next packet, the second packet with base64 encoded reply to the C&C command.
As an example, we will analyze the C&C command ‘read SentSMS’ that retrieves all SMS sent from the infected device. The data field of the packet with C&C command ‘read SentSMS’ is displayed in Figure 31.
Figure 31. The data field of the packet with the C&C command ‘read SentSMS’ that aims to retrieve all SMS sent from the infected device. The data is base64 decoded.
The phone replies with two packets: the first packet in Figure 31 and the second packet in Figure 32. Bytes 0x01d8 from the first packet defines 472 bytes in decimal format as the length of the data in the second packet.
0000 00 00 01 d8 ....Figure 31. The data field of the first packet sent from the phone as a reply to the C&C command ‘read SentSMS’. Bytes 0x01D8 in hexadecimal form presents 472 bytes in decimal form.
Figure 32. The data field of the second packet sent from the phone as a reply to the C&C command ‘read sentSMS’. The data has a length of 472 and is base64 encoded.
During the complete communication between the phone and the controller, there was no heartbeat performed in the TCP connection.
PCAP Statistics
In order to create some statistics for this capture, we have been looking at all the malicious connections: connection to the database, TCP connections directly with the C&C and connections to the IRC server.
In total, there were 21 connections to the RAT’s 000webhost.com database (Figure 33). According to the APK code, a new connection to the database was established every time the IRC servers were refreshed.
Figure 33. All the connections performed to the 000webhost.com database from the phone. In total, there are 21 connections.
From the APK list of IRC servers, it is clear that the phone connects over ports 6667/TCP, 6668/TCP, 6669/TCP, 7000/TCP and 7020/TCP. After filtering the Zeek conn.log file with all these ports, there were 34 connections to IRC servers in total:
Figure 34. All connections from the phone to IRC servers over ports 6667/TCP, 6668/TCP, 6669/TCP, 7000/TCP, and 7020/TCP.
As for the connection to the C&C over port 8000/TCP, there were in total 5 connections: 3 connections were closed with a RESET packet from the C&C, and 2 connections were not closed.
Figure 32. Five connections over TCP established with the C&C. The connections were ended with the flags RSTR and S1.
Through all the malicious connections, the heartbeat was only performed with IRC servers, which is a normal behaviour of such type of protocol.
Conclusion
In this blog post we have analyzed the network traffic from a phone infected with the Saefko Attack Systems RAT that uses 3 different methods to operate and control devices. All the retrieved data from the devices was stored in a database stored in the 000webhost.com hosting provider. We were not able to decode the secure connection to the database, but we have successfully decoded the connection to the IRC servers, HTTP and TCP connections. The Saefko RAT seems to be complex in its communication protocol, but it is still not sophisticated in its work.
To summarize, the details found in the network traffic of this RAT are:
The RAT is capable of controlling the targeted phone over IRC servers, HTTP request, and TCP connection.
The RAT’s database is hosted on the 000webhost.com web hosting service. And is up to the user to install it.
The connection from the infected device to the database in the 000webhost.com hosting is encrypted.
The packets sent from the controller and the phone over IRC servers follow the structure: ‘SASENCODE’+base64_encode(data + ‘T_T’+timestamp)
The packets sent from the controller and the phone over TCP follow the structure: base64_encode(data in JSON format)
The phone connects to the website ipinfo.io to retrieve and send its location to the C&C.
There is no heartbeat in the TCP communication between the C&C and the phone.
There is a heartbeat between the IRC server and the victim, but it is a normal behaviour for this protocol.
The connections with the C&C over TCP were closed with RSTR and S1 states.
There are 34 connections established to different IRC servers.
There are 21 connections established to the database in the 000webhost.com hosting with the server_name ‘experimentsas.000webhostapp.com’.
Thanks to Vitaly Kim (@mercury0169) for drawing the blog cover picture.
Biographies
KAMILA BABAYEVA
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
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