So recently, I was studying in depth about C2 malware communication and how they manage and send traffic through various possible ways, when I got a text from one of my Sir.
He needed my help because, according to him, his friend had lost around 90k rupees due to an application. He briefly explained that this malware/RAT was persistent and remotely controlling the mobile device.
This excited me to analyze the application further, as I was, as usual, curious to learn about new types of malware obfuscation methods.
As usual, my first step before testing any Android malware is to run it through a scanner to gather some basic information, potential hints, CVEs, or the type of malware present inside the application.
Here is SHA-256 if you want to see the report on Virustotal:
d5c74fd52087a389d9e26a2a617c0e854d59adb36f15b46f3c451ef40ccadf19As can be clearly seen from the screenshot, the malware was detected by 12 out of 64 scanners, with most of them labeling the threat as a Trojan.
Moving forward, I tried to unpack the application using apktool.
This wasn't new to me I already had an idea that it might be bundled and using some type of obfuscation mechanism to bind the files and make static analysis more difficult.
Whenever you come across an application that is heavily obfuscated and bundled, the best approach is often to use unzip directly on the APK and manually search for libraries associated with the application.
Fortunately, the unzip method worked, and I was able to obtain four major and important files/folders associated with the application:
The next step that most analysts would take is to scan the classes.dex file and attempt to decompile it using jadx. However, here came the major problem: the obfuscation was so strong that it made the decompiled code almost impossible to analyze. The code was fully encrypted and could only be decrypted during runtime.
The only way to understand what was happening—and how the code could be decrypted—was to analyze the library associated with the application.
The application contained a single library named: libnp_protect_res.so
The name itself already provided some hints. Since it included the word protect, it likely served the purpose of protecting the source code from being exposed during analysis, making reverse engineering more difficult and time-consuming.
I inspected the library using Binary Ninja and found a few interesting functions.
As shown in the picture, the function is clearly a JNI-exported native function, which indicates that it hides the real code until runtime.
At this stage, there were two possible approaches:
I chose the first—and easier—option: to simply test run the application and observe its behavior.
Note: For the purpose of Dynamic Testing I have turned off all the play protection settings
The first major red flag appeared when the application requested permission to download another application. Normally, this should be the point where you immediately quit and uninstall it. However, I allowed the permission to see what would happen and what application would be installed.
Once the secondary application was installed, it requested three major permissions. At this point, it became clear that the upfront application—named Wedding Invitation—served only one purpose: to trick the user into downloading the hidden malware.
This technique is known as the Dropper Technique, where the initial application pretends to need an update (or additional component) but instead installs a hidden malware/Trojan in memory without the user's awareness.
After installation, the Wedding Invitation app even forced the user to delete itself, because by then the RAT had already been installed in the background with all the permissions it required.
This was the second application which was installed, it does not have any name and it is not displayed on the user screen.
[The above screenshot was taken in a rest state where the phone was not operation, in real time the application did not allowed to view application settings]
This behavior was already enough to confirm malicious intent during dynamic analysis. However, since I was working on macOS and faced some crashes due to architecture issues, I shifted my focus to one of the best tools for dynamic Trojan analysis
AnyRun.
By this point, I had already read more about libnp_protect_res obfuscation but hadn't found a proper decoder. So, I directly used AnyRun for further testing.
The initial scan on AnyRun identified the malware as Tanglebot.
(You can read more about Tanglebot here)
Thanks to the powerful AnyRun sandbox, I was able to obtain the .dex files at runtime. These files contained the fully decrypted source code.
I extracted the .dex files and used jadx to decompile them. There were about 12 .dex files, which, after decompilation, resulted in more than 3000 source files—essentially the entire codebase.
At this point, I began analyzing the code for patterns. With the help of AnyRun, I confirmed that the malware was actively communicating over a C2 network.
These were the two IPs associated with the C2 network:
A quick IP lookup revealed that both of them belonged to the same organization — IntechDC.
Returning to the source code, I spent considerable time analyzing and reorganizing the folders based on the functions used in the application. The code was still not fully clean, as some obfuscation remained, but it was almost negligible compared to the earlier state.
The Class5_malware_core_components folder was my top priority to examine initially.
Here are some of the most interesting functions I discovered, along with their workings:
The malware does not hardcode any destination phone number. SMS destinations are provided by the C2 at runtime via the command token ssms<*> in the "order" stream. The code splits that payload into <number>#<text> and calls Firebase.sendSMS(number, text)
154.61.80.131:1200: Socket.IO realtime C2. Used for live "order" commands, SIM/SMS ops, contacts push, pings, and quick ACKs. If this is up, operators can drive the device interactively.
154.61.76.8:1029: Raw TCP "bulk" channel (framed + GZIP). Used for delivering/loading extra dex modules, issuing larger/queued jobs, and exfil of logs/data/artifacts. It also acts as a fallback when the Socket.IO path is blocked. The
host/port are base64 and can be replaced at runtime via SharedPreferences.
/sdcard/Config/sys/apps/log/
Logs are saved at this location, if you check victims phone you can easily retrieve key information and also the phone numbers to which the sms where sent
All C2 event names and the full command set parsed in Api.ta
Some basics information on which ports are running on the 154.61.80.131
This image clearly shows that the IP is running an RDP server, and the RDP machine name is WIN2K19-TEMPLAT.
For second IP 154.61.76.8
The port used for the C2 connection is currently offline. If it had been online, I could have easily extracted the contact details of the individual operating the scam application.
Here you can access the Source-Code of the Application:
In the upcoming days, I plan to update this blog with more details and findings. So far, I've spent around 3–4 hours on this analysis, and I intend to continue investigating it further.
If you come across something valuable related to this malware, feel free to share it with me on Discord (0x1622) or reach out via X/Twitter.