Analyzing Banking Trojan - Reversing Apk (Part 1)

Hi Everyone, In this blog we are going to look at the malicious android application that my friend got on text.

We are going to look at the behaviour and the capabilities of the malicious application. If you look at the message, the malicious actor has tried to create a sense of urgency to lure normal user. So let’s get started with analyzing how the application is working.

Basic Analysis

First I uploaded the apk to virustotal for analysis.

After uploading the APK to VirusTotal, I examined its SHA-256 hash and other key details from the analysis report. The report provided insights into detections by various antivirus engines, file metadata, and potential malicious behaviors. Here are some interesting findings:

MD5 : 89169d7f297915abda2a0d8a0933f981
 
SHA-1 : fe329b52e6b9f9638e67b334ee49f7dfb5cb52a7

SHA-256 : 9de2b7bdfec291cf6d091f01494be5203a90d2672f4bf37948e7d638471ae801

File Name: Indusind Bank i09.apk

File Size: 4.61 MB (4837764 bytes)

File type: Android | executable | mobile | android | apk

Detection Rate: As of now 20/66 security vendors flagged it as malicious

Embedded Certificates: Found potential code signing certificates used for validation

Certificates Attr:

By analyzing these details, I could get an initial understanding of the application’s potential threats before diving deeper into static and dynamic analysis. Now let’s get into the static analysis.

Static Analysis

To statically analyze the application, I opened the application in jadx-gui. JADX GUI is a user-friendly tool for reverse-engineering Android APKs by decompiling DEX (Dalvik Executable) files into readable Java source code. It provides a graphical interface to explore an APK’s structure, making it easier to analyze its components.

So let’s take a look at the AndroidManifest.xml.

Things to note:

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES"/>

<package android:name="indieba.indi.indi"/>

android:name="indi.c.c.indichedgvyhedg"

Looking at the permission we can conclude that the application is trying to install packages. It’s likely used to drop secondary payloads, dynamically extending the trojan’s capabilities post-installation. This technique is commonly used to evade detection by dynamic analysis sandboxes and static scanners, as the full malicious behavior is deferred until after the initial app is installed. And the indi.c.c.indichedgvyhedg is the entry point of the android application.

Now, let’s take a look at the class indi.c.c.indichedgvyhedg:

The app is basically trying to install 👀 base.apk and it was just a stager application. It is first creating a PackageInstaller.Session, which enables the application to install the base.apk that is most probably bundled within the assets or dropped somewhere in internal storage.

Getting the Main Payload (Second Stage)

In the Resources > assets folder we can find the base.apk that is being installed. We can simply export the base.apk and start the analysis.

There is one more way to extract the apk i.e by using the dynamic analysis(adb pull). So let’s take a look into it :)

After this part, it’s totally optional so you can skip to next part as we have extracted the main payload apk.

Dynamic Analysis

For dynamic analysis, I quickly booted up the android device using genymotion running Andriod 11 … because the genymotion only support the root access upto Android 11 version for the free users.

Install the apk into the android device just by dropping the file(apk) on the device. If you look into the application the drawer the application is installed.

Let’s take a look at the application and the already installed packages simultaneously using the adb shell. To look at the installed packages you can simply go to /data/data inside the android device. Note the indi.c.c package.

Pulling the APK from device

If we click on the Proceed to install, it will ask for the permission to install unknown packages. We also saw this permission while doing the static analysis in AndroidManifest.xml.

After approving, in the app it will ask for downloading the another application, which is very suspicious and these is where the malicious application presents.

As this a virtual environment, so I proceed to install the application. After the installation, I took a look at the installed packages using adb shell in /data/data directory.

Now there are 2 packages 👀 …. indi.c.c and the new one indieba.indi.indi. The new package was installed with the similar package name and app icon to avoid the suspision of the normal user.

Let’s pull the application from the running device. To do that you can use the following commands:

adb shell pm list packages      // To determine the package name of the app

adb shell pm path indieba.indi.indi        // To get the full path name of the APK

adb pull /data/app/~~Su_VVjKhEupprJkdzWoDSQ==/indieba.indi.indi-dCswx4yWRVLkD5AYeD-IIA==/base.apk payload.apk        // To copy the apk to our pc.

Now we can start analysing the main application :) See you in the next part where I am going to analyze the main payload ….. trying to track the threat actor, identifying IoCs and Attack Path.

^w^  with <3