Unmasking the SBI Scam APK: A Deep Dive into the Fraudulent World

Abhijith A
6 min readSep 1, 2024

--

It all started when I noticed a surge of Reddit posts discussing suspicious APKs people received over WhatsApp, pretending to be that of legitimate banking services. I decided to delve deeper into one such case after a friend of mine received an APK that seemed to mimic a legitimate banking application. What began as a casual inquiry quickly evolved into a comprehensive analysis, revealing a complex and widespread scam.

The application and domains I tested are not related to SBI or any other legitimate banking services.

Screenshots from Reddit posts discussing scammer apks
Reddit posts on scammer apks

I started my investigation by installing the Fake-SBI apk on Genymotion emulator. After installation, the app didn’t show up in the main menu, which was strange (not for these scam applications ! ). However, it was still visible in the app settings as ‘yono sbi’.

Genymotion app manager and app menu after installation

The app is set to start automatically when the device boots up. However, when I checked the running processes using Frida, it didn’t show up, even though it was clearly active.

Frida process list

I tried to intercept the traffic with Burpsuite, but SSL pinning was preventing me from capturing any request. Without the package name or any useful leads, I figured my best bet was to reverse-engineer the app to see if I could find anything.

Static Analysis

I attempted to decompile the APK using apktool, but ended up with a large error message. The same issues occurred with other tools like jadx and Mobsf during static analysis. I was suspecting some kind of anti-reverse mechanism being used there. After these methods failed, I converted the APK into a JAR file using dex2jar and then examined the JAR file to dig for useful information.

And I instantly realized that it was a bad decision when I saw the output.

jd-gui output of the jar file

The code was highly obfuscated and I could only see a long gibberish string of special characters.

Every apk is basically an archive file. So I tried to extract the apk and I saw an interesting properties file there.

Contents extracted from the apk
Contents of properties file

So there is some anti-reverse mechanism that being used by the scammers. At this point I realized that I underestimated the scammers. They are using everything possible to secure their application. I did some OSINT based on this information and found a telegram channel selling these obfuscation methods.

I remember doing some Android CTF challenges in the past where I used Linux strings command to find some hidden flags along with the package and activity names. I applied the same here and I got the package name, “com.facebook.smsrecevies” !!!!

Packages and activities used in the apk

Dynamic Analysis

Now that I got the package name I tried bypassing the SSL pinning using Frida. And it worked !!!

Requests captured on Burpsuite

I observed that when the application starts, it sends a GET request to a specific domain with a key parameter. The server then responds with a different domain, redirecting the user to this new location.

Redirection to another malicious domain

Uncovering the fraud network

The initial subdomain pattern appeared too predictable, so I decided to brute-force it using the same key parameter. As it turned out, my instincts were correct. I uncovered about 90 different subdomains, many of which behaved similarly, redirecting to various domains hosting different scam applications.

Subdomain bruteforce with key parameter
Different scam applications hosted on different endpoints in the same domain

I realized the network was way bigger than I first thought. It looked like the same group might be behind a lot of the scam APKs I’d seen on Reddit. Curious to learn more, I wanted to dig up as much info as I could about the target. Since I hadn’t really checked out what the app does yet, I decided to fire it up and see what kind of data it was collecting.

Data requested by the application

Firebase Database

I entered some random data into the app and monitored the HTTP requests it generated. One particular Firebase request stood out. I discovered a Firebase Realtime Database URL in the requests, and it was poorly configured. This allowed me to access and view all the data stored there.

Firebase database with all the data collected from victims

At this point, I had access to all the data the scammers had collected from their victims, including account numbers, card details, usernames, passwords, and other personal information.

I wasn’t ready to stop there. I continued to dig deeper, hoping to find additional information that could lead me to the scammers behind the operation.

Finding the scammers !!

After starting the app, I examined the local data storage and found two new class files. Using the strings command to inspect these files, I discovered some intriguing endpoints.

New class files in local data storage

I examined the data.json endpoint and found a phone number listed there. This raised questions about its purpose and usage. In my previous analysis of other scam applications, I had seen scammers hardcoding phone numbers into the code for SMS forwarding. I was curious if this phone number served a similar role in this case.

To verify this, I simulated an SMS in my Genymotion emulator and checked the ADB logs. I found that all incoming SMS messages were indeed being forwarded to the phone number listed in the data.json file.

Phone number in data.json endpoint
SMS Forwarding to scammer owned number

Earlier, I had identified around 100 subdomains, so I decided to check if the data.json file was present on these as well. From this, I uncovered around 90 unique phone numbers, all used by scammers for various APK scams similar to this one.

Bruteforced subdomains from user0 to user100

I initially thought this investigation was wrapping up, but that wasn’t the case. As I prepared to write up my findings, I checked the application again after three days and noticed something surprising — the phone numbers had been changed. New numbers had replaced the old ones. I continued to monitor these subdomains over the next two weeks and discovered that the numbers were frequently updated every 4–5 days.

I created a Python script to collect phone numbers from these subdomains. Over the course of three weeks, I identified approximately 300 phone numbers linked to scammers.

Phone numbers collected from the subdomains

Conclusion

  1. Identified the modus operandi and detailed operation technique of the scammers
  2. Gained access to the scammers firebase database with information collected from the victims.
  3. Found more than 300 unique phone numbers pointing to the scammers.
  4. New subdomains with different bank application clones were identified which confirms a broader fraudulent network

Scammers are becoming increasingly sophisticated in their techniques, so it’s crucial to be extra cautious. Always verify links before clicking and avoid installing applications from untrusted sources.

Thank you for taking the time to read this. I’d love to hear your thoughts on it.

--

--

Abhijith A
Abhijith A

Written by Abhijith A

Penetration Tester | Cybersecurity Enthusiastic

Responses (4)