{
	"id": "75a6915e-e521-42b2-b708-a7b4d9094d11",
	"created_at": "2026-04-06T00:12:57.744935Z",
	"updated_at": "2026-04-10T03:19:57.229756Z",
	"deleted_at": null,
	"sha1_hash": "149d9a35be65416ee2c9aa23d09b336802f4ed4f",
	"title": "Dissecting a RAT. Analysis of the AndroRAT. — Stratosphere Laboratory",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 99803,
	"plain_text": "Dissecting a RAT. Analysis of the AndroRAT. — Stratosphere\r\nLaboratory\r\nPublished: 2021-03-31 · Archived: 2026-04-02 11:53:51 UTC\r\nThis blog post was authored by Kamila Babayeva (@_kamifai_) and Sebastian Garcia (@eldracote).\r\nThe RAT analysis research is part of the Civilsphere Project (https://www.civilsphereproject.org/), which aims to\r\nprotect the civil society at risk by understanding how the attacks work and how we can stop them. Check the\r\nwebpage for more information.\r\nThis is the fourth blog of a series analyzing the network traffic of Android RATs from our Android Mischief\r\nDataset [more information here], a dataset of network traffic from Android phones infected with Remote Access\r\nTrojans (RAT). In this blog post we provide the analysis of the network traffic of the RAT05-AndroRAT\r\n[download here]. The previous blogs analyzed Android Tester RAT, DroidJack RAT, and SpyMax RAT. \r\nRAT Details and Execution Setup\r\nThe goal of each of our RAT experiments is to configure and execute the RAT software and to do every possible\r\naction while capturing all traffic and storing all logs. These RAT captures are functional and used as in real\r\nattacks.\r\nThe AndroRAT RAT is a software package that contains the controller software and builder software to create an\r\nAPK. We executed the builder on a Windows 7 Virtualbox virtual machine with Ubuntu 20.04 as a host. The\r\nAndroid Application Package (APK) built by the RAT builder was installed in an Android virtual emulator called\r\nGenymotion with Android version 8. \r\nWhile performing different actions on the RAT controller (e.g. upload a file, get GPS location, monitor files, etc.),\r\nwe captured the network traffic on the Android virtual emulator. The network traffic from the phone was captured\r\nusing Emergency VPN.\r\nThe details about the network traffic capture are:\r\nThe controller IP address: 147.32.83.234\r\nThe phone IP address: 10.8.0.137\r\nUTC time of the infection in the capture: 2020-09-10 15:18:00 UTС\r\nInitial Communication and Infection\r\nOnce the APK was installed on the phone, it directly tries to establish a TCP connection with the command and\r\ncontrol (C\u0026C) server. To connect, the phone uses the IP address and the port of the controller specified in the\r\nAPK. In our case, the IP address of the controller is 147.32.83.234 and the port is 1337/TCP. The controller IP\r\nhttps://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nPage 1 of 6\n\n147.32.83.234 is the IP address of a Windows 7 virtual machine in our lab computer, meaning that the IP address\r\nis not connected to any known indicator of compromise (IoC). Figure 1 shows the initial communication from the\r\nphone to the C\u0026C.\r\nFigure 1. A 3-way handshake to establish the first connection between the phone and the C\u0026C.\r\nAfter establishing the first connection, the phone sends its first packet with some parameters, such as SIM card\r\noperator, phone number, SIM card serial number, IMEI, etc. Figure 2 displays the packet data in a structured way.\r\nIt can be seen that the data is sent in plaintext and the character ‘t’ is used as the delimiters to separate parameters\r\nname and values. From the packet structure in Figure 2,it can also be defined that APK uses the Java Hashtable\r\nclass to store and send parameters. \r\nÿÿ¬ísrjava.util.Hashtable»%!Jä¸F\r\nloadFactorI thresholdxp?@\r\nw\r\nt Operator t Android\r\nt SimOperator t Android\r\nt SimSerial t 8931027000000000007\r\nt SimCountry t us\r\nt PhoneNumber t 15555218135\r\nt Country t us\r\nt IMEI t 000000000000000\r\nx\r\nFigure 2. The first data packet sent by the phone and an analysis of its structure. The data is sent in the plain text\r\nand the character ‘t’ is used as a field delimiter. \r\nAfter the initial connection by the phone, the command and control server shows the phone in its interface. Figure\r\n3 displays the C\u0026C interface with the initialization parameters that were sent by the phone in the first packet.\r\nFigure 3. The C\u0026C interface panel displays the parameters of the phone after the infection.\r\nFigure 4. Panel in the C\u0026C interface used to send commands to the phone.\r\n0000   00 00 00 06 00 00 00 06 01 00 00 00 00 00 00 00   ................\r\n0010   79 00 00 01 67                                    y...g\r\nFigure 5. Data of the first packet sent by the C\u0026C when the attacker enters into the panel to control the phone. \r\n0000   00 00 00 06 00 00 00 06 01 00 00 00 00 00 00 00   ................\r\n0010   15 00 00 02 6e                                    ....n\r\nFigure 6. Data of the second packet sent by the C\u0026C when the attacker enters into the panel to control the phone.\r\nSince the structure of these packets is not clear, we tried to understand what these commands mean by reverse\r\nengineering the APK that was used to infect the victim’s phone. The analysis shows that each C\u0026C command is\r\nhttps://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nPage 2 of 6\n\nmapped to a single character that represents this command. The mapping is shown in Figure 7.  \r\nFigure 7. The mapping of each C\u0026C commands (in capital letters) into a single character defined\r\nby a number. Found by reverse engineering the APK used to infect the victim. \r\nFigure 8.  Java code from the APK for the function dataHeaderGenerator. This function generates\r\nthe header for the C\u0026C and phone packets.\r\nFigure 9.  Java code from the malicious APK for the function parse. This function unwraps the\r\nC\u0026C command.\r\nFigure 10. Analysis of the packet structure of the C\u0026C command ‘Advanced Information’ sent to\r\nthe phone.\r\nFigure 10 shows an analysis diagram of the meaning of a packet sent to the phone with the command ‘Advanced\r\nInformation’. This packet has a data length of 6, therefore everything after the field byteChannel (00 79 00 00 01\r\n67) has a length of 6 bytes. The bytes 00 79, which are used to represent C\u0026C command, mean 121 in decimal\r\nrepresentation. According to the mapping in Figure 7, the value 121 responds to the command ‘Advanced\r\nInformation’. Figure 11 shows how. The variable P_INST is 100, and the command\r\nGET_ADV_INFORMATIONS is P_INST + 21 = 100 + 21 = 121\r\nFigure 11. Mapping value of the C\u0026C command ‘GET_ADV_INFORMATIONS’. The value of\r\nthis command is 121 in decimal which is 00 79 in hexadecimal. \r\nFigure 12. Analysis of the packet structure of the C\u0026C command ‘Preferences’ sent to the phone.\r\nFor this packet, the data length is 6, therefore everything after the field byteChannel (00 15 00 00 02 6e) has a\r\nlength of 6 bytes. The bytes 00 15, that are used for defining C\u0026C command, mean 21 in decimal representation.\r\nAccording to the mapping in Figure 7, it is the command ‘Preferences’. Figure 13 shows how this command is\r\ncomputed. \r\nFigure 13. Mapping of the C\u0026C command GET_PREFERENCE from Figure 7.\r\nGET_PREFERNCES is 21 in decimal, and 00 15 in hexadecimal. \r\nFigure 14. Summary of the packet structure of the C\u0026C commands.\r\nVictim Phone Packet Structure\r\nThe phone answers to the C\u0026C command ‘getPreferences’ and the command ‘Advanced informations’ with its\r\nown packets. The structure of the packets sent from the phone is different from the C\u0026C command packet\r\nstructure shown in Figure 14. Figure 15 shows the analysis of APK function ‘send’ that sends the packet from the\r\nphone with a specific structure. The packet structure the function uses is the following:\r\nName Length\r\nheader 15 bytes\r\ndata no more than 2033 bytes\r\nhttps://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nPage 3 of 6\n\nThe header in that structure uses a substructure:\r\nName Length\r\nbyteTotalLength 4 bytes\r\nbyteLocalLength 4 bytes\r\nbyteMoreF 1 byte\r\nbytePointeurData 2 bytes\r\nbyteChannel 4 bytes\r\nAs for the data in the packet, if its length exceeds the limit of 2033 bytes, the data will be fragmented into more\r\npackets. Each packet will have a separate 15 bytes long header and will be fragmented with a length of 2033 bytes\r\nor less.\r\nFigure 15. Java code from the APK for the command ‘send’. This function sends the packet from\r\nthe phone according to the specific structure.\r\nUsing this structure we can now interpret the packets sent by the phone. Figure 16 shows the phone answer to the\r\nC\u0026C command ‘get Preferences’ and the structure of the packet. The phone sends the 15 byte long header\r\nfollowed by the data. The data in Figure 16 includes the preferred parameters for phonNumberCall,\r\nphoneNumberSMS, keywordSMS. \r\nFigure 16. Packet sent from the phone as an answer to the C\u0026C command ‘get Preferences’. The\r\npacket data and its structure is shown.\r\nThe phone sends data about the battery status, phone info, and wifi information to answer the C\u0026C command\r\n‘Advanced Information’. The phone uses the same structure of 15 byte long header and the data. Figure 17 shows\r\na raw answer of the phone to the C\u0026C command ‘Advanced Information’. \r\nJJg¬ísr Packet.AdvancedInformationPacketqB®IandroidSdkIbatteryHealthIbatteryLevelIbatteryPluggedZbatteryPresent\r\nFigure 17. Raw answer as ASCII text sent from the phone to the C\u0026C command ‘Advanced Information’. The\r\npacket data and its structure is shown. It is not easy to find the field separators.\r\nThe summary of the structure of the packets sent from the phone is:\r\nFigure 18. The structure of the packet sent from the phone.\r\nFigure 19.  Packet data and structure for the C\u0026C command ‘Toast’ with the argument ‘hello’.\r\nThe C\u0026C command sent has the value 00 6d in hexadecimal or 109 in decimal representation. We can confirm\r\nthat this mapping responds to the command ‘Toast’ (Figure 20). It is important to notice that the C\u0026C command is\r\nmapped to the single character, but its argument ‘hello’ (68 65 6c 6c 6f) is not mapped to anything.\r\nhttps://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nPage 4 of 6\n\nFigure 20.  The mapping of the C\u0026C command ‘Toast’. The value of this command is 109 which is\r\n00 6d in hexadecimal.\r\n‘Toast hello’ was successfully performed on the phone. The phone in return did not send any confirmation of the\r\nsuccessful operation. Only for the C\u0026C commands that require the phone to send information (e.g. file, call, sms),\r\nthe phone sends the packet with the confirmation of receiving the command. Afterwards, it sends the required\r\ndata.\r\nAs an example, we took the C\u0026C command ‘Directory List’. The communication gos as follows:\r\n1. The C\u0026C sends the command ‘Directory List’ with the directory as an argument. (Figure 21)\r\n2. The phone sends the confirmation of the command being received. (Figure 22)\r\n3. The phone send the required data, i.e. file list in the directory. (Figure 23)\r\nFigure 21. The packet data and its structure of the C\u0026C command ‘Directory List’. The command\r\naims to get the list of files in the specified directory (in our case directory ‘/’).\r\nFigure 22. The phone sends the confirmation about the received command ‘Directory List’. The\r\npacket data and its structure is shown.\r\n3ñ¬ísrjava.util.ArrayListxÒÇaIsizexpwsrutils.MyFileëÀÞ¹÷ÓZhiddenZisDirZisFileJ lastModifJlengthZrZwLli\r\nFigure 23. The phones send the list of files in a specified directory from the C\u0026C command ‘Directory List’.\r\nLong Connections\r\nIf we use the Wireshark tool to analyze all the traffic, we can open the menu “Conversations”, then “Statistics”,\r\nthen “TCP”.  There were several connections between the C\u0026C (147.32.83.234) and the phone (10.8.0.37) as\r\nshown in Figure 24. The longest connection established between the C\u0026C and the phone is 2611.3454 seconds\r\nlong (approximately 44 minutes). This indicates that the connections between the phone and the controller are\r\nkept for a long period of time in order to answer fast. \r\nFigure 24.  All the connections in the traffic between the phone and the C\u0026C. \r\nFigure 25 displays all the TCP connections in the phone sorted by the highest connection duration. It is important\r\nto notice that there are even longer normal connections with durations of 3576.9112 seconds (approximately 57\r\nminutes). This is the connection from the phone during normal operation to the IP address 157.240.30.11 which\r\nbelongs to Facebook services.\r\nFigure 25. Top connections from the phone from Wireshark -\u003e Statistics -\u003e Conversations -\u003e TCP.\r\nConclusion \r\nhttps://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nPage 5 of 6\n\nIn this blog we have analyzed the network traffic from a phone infected with AndroRAT. We were able to decode\r\nits connection. The androRAT does not seem to be complex in its communication protocol and it is not\r\nsophisticated in its work.\r\nTo summarize, the details found in the network traffic of this RAT are:\r\nThe phone connects directly to the IP address and ports specified in APK (default port and custom port).\r\nThere is only one long connection, i.e. more than 40 minutes, between the phone and the controller over\r\nthe port 1337/TCP.\r\nThere is no heartbeat between the controller and the phone.\r\nThe data is sent in the plain text.\r\nThe C\u0026C uses mapping to present the C\u0026C command as a single character.\r\nPackets sent from the phone have a structure of {byteTotalLength}{byteLocalLength}{byteMoreF}\r\n{bytePointeurData}{byteChannel}{data}\r\nPackets sent from the C\u0026C have a structure of {byteTotalLength}{byteLocalLength}{byteMoreF}\r\n{bytePointeurData}{byteChannel}{C\u0026C command}{targetChannel}{arguments}.\r\nBiographies\r\nSource: https://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nhttps://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.stratosphereips.org/blog/2021/3/29/dissecting-a-rat-analysis-of-the-androrat"
	],
	"report_names": [
		"dissecting-a-rat-analysis-of-the-androrat"
	],
	"threat_actors": [],
	"ts_created_at": 1775434377,
	"ts_updated_at": 1775791197,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/149d9a35be65416ee2c9aa23d09b336802f4ed4f.pdf",
		"text": "https://archive.orkl.eu/149d9a35be65416ee2c9aa23d09b336802f4ed4f.txt",
		"img": "https://archive.orkl.eu/149d9a35be65416ee2c9aa23d09b336802f4ed4f.jpg"
	}
}