Threat Through WhatsApp? An Investigation into a Suspicious Android APK

This investigation was not planned but happened to be . The APK file caught my attention when I saw it being shared on a WhatsApp group , the group included several elderly individuals who may not be necessarily aware about such suspicious files .

That immediately caught my attention . The contact had tag named BOI and the contact had shared an image of a notice that created urgency to install the application named BOIMobile.apk and complete the KYC process and I was like "Wait a minute …!!! Something isn't right ." I was excited to get my hands dirty . So I put on my detective glasses and begun with the analysis .

What initially started as a simple curiosity quickly turned into a much deeper rabbit hole involving security detections, sandbox analysis, obfuscated code, encrypted data, payload extraction, and Android package installation functionality.

Before going further, I want to make something clear:

This article documents my investigation and the evidence I discovered during my analysis. I am not making a definitive claim that the application is malicious.

The goal was not to jump to a conclusion.

The goal was to follow the evidence.

1. First Stop: Checking the File

The first thing I wanted to know was whether the file had already attracted attention from security vendors.

I submitted the APK for analysis and initially found that 2 out of 67 security vendors flagged the file as malicious.

At first, that wasn't enough for me to make any conclusions. Multi-engine detection results can sometimes contain false positives, and the majority of vendors had not flagged the application.

However, the detection names and threat labels were interesting. The file was associated with terms such as dropper and trojan, which gave me enough reason to continue investigating.

Later, after further analysis, the results changed.

The file was subsequently detected by 3 out of 68 security vendors, with additional threat classifications including trojan, banker, and dropper.

Again, this alone did not prove that the application was malicious.

But it definitely made me ask a more important question: "What exactly was this APK doing internally?"

2. Opening the APK

To get a better understanding of the application, I opened the APK and boom — my laptop started heating up, and suddenly the screen went black.

I panicked.

"Did I just get hacked?" .

I even started to think about wiping down the system . I was feeling like Elliot Alderson (Mr.Robot fans attendance pls), too many voices running through my head.

All this, only to realise that my laptop's battery was dead. 😭

So, I plugged in the charger.

Now, I am not that kind of dumb to simply run a potentially malicious file on my system. Before doing anything further, I researched safer ways to analyse an APK and decided to use JADX, an Android decompiler that allows us to inspect an application's resources, manifest, and decompiled code.

The first thing that caught my attention was the application's package structure and the amount of code available for inspection.

From here, I began looking at the AndroidManifest.xml file.

For me, this was where the investigation started becoming more interesting.

3. A Strange Package Name and an Interesting Permission

The application was using the package name:

com.ljkheg.zvjwu

A random-looking package name is not automatically malicious. A random-looking package name is not automatically malicious. Developers can use unusual package names for many reasons.

But this one made me stop for a second.

com.ljkheg.zvjwu

This wasn't exactly the kind of package name I expected to see. It looked completely random and mysterious.

Was it written in another language? Was there some meaning behind it? Or was it perhaps written by aliens?

Jokes aside, a random-looking package name alone is not evidence of malicious behaviour. However, considering the other indicators surrounding this application, it was another detail that caught my attention.

Another entry in the manifest caught my attention:

REQUEST_INSTALL_PACKAGES

This permission allows an application to request the installation of other application packages.

That immediately became significant because the application was already being presented as a KYC-related APK. I wanted to know whether the ability to install packages was actually being used somewhere within the application.

So, I started following the code.

4. Cleartext Traffic

Another configuration that caught my attention was:

android:usesCleartextTraffic="true"

This setting allows the application to communicate using unencrypted cleartext HTTP connections.

This is not proof of malicious behaviour, and legitimate applications can also have this configuration.

However, when investigating an application that was already showing multiple suspicious indicators, I considered it another detail worth documenting.

At this point, I had several separate observations.

But I still wanted to understand the application's actual behaviour.

5. Why does a KYC App needs VPN

While examining the manifest, I found services associated with the Android VPN framework, including the permission:

BIND_VPN_SERVICE

The presence of VPN functionality is not inherently suspicious. Many legitimate applications use Android's VPN APIs for privacy tools, filtering, or network security.

However, the application's advertised purpose and the functionality I was discovering did not immediately appear to align.

This encouraged me to look deeper into the application's behaviour rather than focusing only on its permissions.

6. The Code That Made Me Go "Wait a Minute…"

So far, I had found a few things that caught my attention.

A suspiciously random package name.

The ability to install packages.

VPN-related functionality.

Cleartext traffic.

But individually, none of these things were enough for me to stand up dramatically and say:

"Ladies and gentlemen, we got him."

I had to dig deeper.

And this is where things started getting really interesting.

While tracing through the application's code, I came across functionality that appeared to be processing encrypted data.

The application was using:

AES/GCM/NoPadding

For those unfamiliar with it, AES-GCM is an encryption mode. The application appeared to be decrypting or processing data and then performing additional operations on the resulting byte array.

And then I saw something else.

There was code involving Android's PackageInstaller.

I stared at it for a while.

Then stared at it again.

Then probably Googled the same thing five different ways because apparently that is how I learn now.

The code appeared to follow a flow something like this:

Encrypted/processed data → Byte array → Extracted data → Package installation

The application was creating a package installation session and writing data into it.

And suddenly, that REQUEST_INSTALL_PACKAGES permission I had seen earlier didn't seem so random anymore.

Again, I want to be careful here.

Finding this functionality does not automatically prove malicious intent. There could potentially be legitimate reasons for an application to process encrypted content and install another package.

But considering everything I had observed so far, this was probably the point where my eyebrows went uppppppp .

7. Connecting the Dots

At this point, I took a step back and looked at everything I had found so far.

The investigation had started with an APK being shared through WhatsApp in a group containing elderly individuals who might not necessarily be familiar with suspicious files. The message created urgency around completing a KYC process.

Then, one finding led to another:

• Multiple security vendors flagged the file.
• Some detection labels included terms such as Trojan, Dropper, and Banker.
• The application used a random-looking package name.
• It requested the REQUEST_INSTALL_PACKAGES permission.
• Cleartext traffic was allowed.
• VPN-related functionality was present.
• The code contained encrypted data processing.
• I found functionality involving Android's PackageInstaller.
• Behavioural analysis associated the APK with techniques related to obfuscation, discovery, and location tracking.

Now, before someone comments:

"Bro, one of these things alone doesn't prove it's malware 🤓☝️."

I know. 😭

And that was never the point.

I wasn't looking for one magical finding that would suddenly say:

MALWARE DETECTED. CONGRATULATIONS, YOU ARE NOW AN APPSEC RESEARCHER.

Instead, I was trying to understand the bigger picture.

Individually, many of these findings could have legitimate explanations. But when I looked at them together, they gave me enough reasons to be suspicious.

At this point, I had gone from: "Hmm… What's this APK?" to: "Yeah… maybe don't install that."

Final Thoughts

This investigation wasn't planned.

It started with a random APK shared on WhatsApp, and I simply followed the evidence one finding at a time.

Did I understand every line of the decompiled code?

Absolutely not.

But that was also the biggest lesson for me. You don't need to understand everything before you start investigating. Sometimes, you just follow your curiosity, research what you don't understand, and see where the evidence takes you.

I am still not making a definitive claim about the application's intent based solely on this analysis.

But personally?

If someone sends me this APK on WhatsApp and tells me to install it urgently for KYC…

Yeah, I'm deleting that message faster than my laptop's battery died.

P.S. I am not an AppSec expert. This was simply me getting my hands dirty with Android application analysis and following one interesting finding after another. I learned a lot during this investigation, and if you spot something I missed or could have done differently, I would genuinely love to hear your thoughts.