Android Tester 6.46 Rat For Android Hacking Tool

Android Tester v6.4.5 This will be latest release from Hidden Content Give reaction to this post to see the hidden content.

Android Tester v6.4.6 Android RAT, Keylogger, File Manager & More File Manager SMS Manager Call Manager Contacts Manager Location … Changelog v6.4.5

Android Tester v6.4.6. Android RAT, Keylogger, File Manager & More




Android Tester v6.4.6 Android RAT, Keylogger, File Manager & More File Manager SMS Manager Call Manager Contacts Manager Location

This is the first blog post 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 an analysis of the network traffic of the RAT01-Android Tester v6.4.6

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 Android Tester v.6.4.6 RAT is a software package that contains the controller software, which receives the connections from the victims, and the builder software, which builds the APKs used for infection. The package was executed on a Windows 7 virtual machine pre-configured with all the needed libraries. The Android Application Package (APK) built by the RAT builder was installed in a Genymotion Android virtual emulator with Android version 8.




While performing different actions on the Android Tester RAT controller (e.g., upload file, get GPS location, monitor files), we have captured the network traffic on the Android virtual emulator. The details about the network traffic capture are:

  • The controller IP address: 147.32.83.234
  • The phone IP address: 10.8.0.61
  • UTC time of the infection in the capture: 2021-09-19 09:01:59 UTC

Initial Communication and Infection

Once the APK was installed in the phone, it directly tries to establish a TCP connection with the C&C server, which is the RAT controller running in our VirtualBox Windows 7. To connect, the phone uses the IP address and the port that were set by us in the controller when building the APK. In our case, the IP address is 147.32.83.234 and the port is 1337.

In this communication with the C&C server, the phone sends data that may appear without a clear structure, as shown in Figure 2. However, at the beginning of this connection there is a number 2969 (32 39 36 39 in hexadecimal) followed by a NULL (00) byte. Each packet sent and received between the controller and the phone contains a number in the beginning of their packets, in printable ASCII, followed by the byte 00. 

Data Decoding Android Tetser

After a careful analysis we discovered that this number indicates the length of the data sent, excluding the bytes taken to represent the number and the byte 00. Another example of this encoding in another packet sent by the controller is shown in Figure 3. Thus each packet sent from both the controller and the phone has the following format:

This discovery allowed us to verify the data part more carefully and to discover that after the number and the delimiter, the bytes 1F 8B were sent to indicate that the gzip file signature or magic number was being used. Figure 4 shows a detail of those bytes. This means that the data being transferred by the device is previously being compressed using the DEFLATE algorithm. Android Tester 6.4.6

Extracting Files from the Android Tester

The discovery of the compression header allows us to investigate the traffic and to try to decompress it. This can easily be done using CyberChef tool to decompress the data from the first packet sent after the connection was established. 

Figure 6. Decompression of the data sent from the infected phone to the C&C controller  (without the number for data length and delimiter). The packet was decompressed using CyberChef recipe ‘From Hex’ and ‘Gunzip’. 

This data seems to be the one used to initialize phone parameters (client name, phone model, Android version, etc.) when the phone first connects to the controller. Figure 7 shows the screenshot from the controller, when the phone connects, Android Tester 6.4.6 that confirms this suspicion.

Figure 7. The screenshot from the controller when the phone connects to it.
Figure 7. The screenshot from the controller when the phone connects to it.

Beside these parameters, the phone also sends its background image. In Figure 6 it can be seen that in the output after readable text, there is a Base64 encoded magic number /9j/4A that would indicate that the file type JPEG (JFIF) file format is being used. If we delete the readable text from the output in Figure 5 and decode the remaining Base64 encoded data to binary, like it is done in Figure 8, then we can get the image seen in Figure 9.




Heartbeat and Long Connections Androd Tester

After sending the first packets with the phone initialization parameters, the phone sent several more packets with the background image and parameters again. Afterwards, it waits for the controller commands. 

While waiting for the commands, the controller and the phone exchange packets to check if both of them are alive – a heartbeat – similar to the PING/PONG seen in IRC (Figure 10).

Knowing the format of the messages now we can see that the commands sent from the controller are all in plain text as no compression seems to be necessary (no big data sent from the C&C). An example of the controller command GetExternalStorage:

33.1026110249GetExternalStorage10249

So the packets sent from the controller will get the form:

{data length}{delimiter}{data in plain text}

Figure 11. The format of the packet sent from the C&C to the phone.

An expected property of the C&C channel connections was their length. If we open the Conversations statistics in Wireshark, as shown in Figure 12, several connections between the phone and the controller can be seen. This might happen because the phone was disconnecting from the C&C from time to time. Some of the connections are long, e.g. 2362.4706 seconds (approximately 40 minutes) or 1831.5294 seconds (approximately 31 minutes).

File Manager
SMS Manager
Call Manager
Contacts Manager
Location Manager
Account Manager
Camera Manager
Shell Terminal
Applications
Microphone
Keylogger
Settings
Chat
Fun

Changelog v6.4.6
– Remaining time fix @download manager
– Loading bar color change

Changelog v6.4.5

– Builder fix
– Unknown developer fix
– Unlocked extra camera resolutions
– Mic UI fix
– More.

Android tester 6.4.6 Rat Download

Zip Password : www.masterscyber.com







Conclusion

In this blog we have analyzed the network traffic from a phone infected with the Android Tester v.6.4.6 RAT. We executed the Android tester RAT in our own environment and we executed several actions. We were able to understand and decode its communication to extract files transferred from the RAT. It was also clear that the RAT has some distinctive features such as long duration of connection, heartbeat or uncommon ports.

To summarize, the details found in the network traffic of this RAT:

  • Phone connects directly to the IP address and port specified in APK.
  • Connection between the phone and the controller is long, i.e. more than 30 minutes.
  • Packets sent from the phone have the format {data length}{delimiter}{gzip compressed data}.
  • Packets sent from the controller have a format {data length}{delimiter}{data in plain text}.
  • There is a heartbeat between the controller and the phone.