Dissecting a RAT. Analysis of DroidJack v4.4 RAT network traffic.
— Stratosphere Laboratory
Published: 2021-02-03 · Archived: 2026-04-05 12:56:23 UTC
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).
https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
Page 1 of 6

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.
Figure 3. Data sent by the phone with initialization parameters.
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.
https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
Page 2 of 6

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. 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:
https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
Page 3 of 6

Figure 9. The phone’s reply on the command ‘File Voyager’ sent by the C&C.
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.
Figure 11. Packet sent from the phone to the controller over 1334/TCP.
Figure 12. UDP packets from the phone to the C&C server sent every 20 seconds over port
1337/UDP.
Figure 13. Example data inside the UDP packets on port 1337/UDP sent from the phone to the
controller. 
https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
Page 4 of 6

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.
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.
https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
Page 5 of 6

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
Source: https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
https://www.stratosphereips.org/blog/2021/1/22/analysis-of-droidjack-v44-rat-network-traffic
Page 6 of 6