They Scammed Money from My Friend’s Uncle with a Fake Axis Bank App, So I Reverse-Engineered the Android RAT Behind It
One month ago, my friend’s uncle received a call from someone pretending to be from “Axis Bank.”
They claimed there was a security issue with his account and convinced him to install a “mandatory update” app.
That “update” was not an update.
It was a stealth Android Remote Access Trojan disguised as a flashlight app:
com.bitmavrick.lumolight
By the time we caught it, the attackers had already withdrawn money from his bank account.
When my friend noticed suspicious OTP spam and unusual activity, she called me.
I exported the APK, moved it to my PC, and started reverse-engineering it solo.
What looked like a normal utility app turned out to be a staged banking malware chain.
The first-stage app used native JNI code as a bootstrapper and hid the real logic behind encrypted assets.
It used AES/CBC asset decryption, where the key was derived from the asset filename plus "1".
Once decrypted, it loaded the next payload in memory using:
dalvik.system.InMemoryDexClassLoader
It also had anti-analysis checks using:
https://api[.]ipapi[.]is/
The app checked for VPN, TOR, proxy, datacenter IPs, and suspicious analysis conditions to avoid researchers and sandboxes.
Inside the hidden payload, I found another package:
com.rolv.saxonnaias
This showed a fake Axis Bank update screen to make the scam look legitimate.
But in the background, it installed real payloads:
Sam[.]AxisBank[.]Mobile
and a companion app:
com[.]kh[.]guamanianprediction
The capabilities were dangerous:
SMS interception
Notification capture
SIM information theft
Device information collection
OTP monitoring
Remote call forwarding using USSD commands
Remote control through cloud config
The attackers controlled infected devices using Firebase Realtime Database.
I found Firebase nodes for device info, call forwarding, SMS forwarding, dynamic Telegram config, bot token, chat ID, and command values.
For exfiltration, the malware used Telegram Bot API methods like:
sendMessage
sendDocument
sendPhoto
The full chain was clear:
Fake bank call → victim installs fake app → staged loader decrypts hidden payload → payload collects sensitive data → attacker controls device using Firebase → stolen data goes to Telegram → money gets withdrawn.
The scary part is how polished this was.
It used native code hiding, encrypted payloads, in-memory DEX loading, anti-analysis checks, fake banking UI, Firebase C2, Telegram exfiltration, SMS stealing, notification stealing, and USSD-based call forwarding.
Despite heavy obfuscation, malformed stage-2 DEX files, native hiding, encrypted blobs, and long-string decoders, I was able to map the full chain.
I recovered the loading logic, decrypted the assets, identified native entry points, exposed the Firebase command schema, and documented the Telegram exfiltration flow.
After completing the analysis, I prepared the findings and reported everything to the authorities.
This case was personal because it affected someone close to my friend.
But it also shows how fast Android banking threats are evolving in India.
Scammers are combining fake bank calls with real malware, cloud infrastructure, and stealthy Android techniques.
For researchers: always look beyond the surface APK. The real payload may be encrypted, loaded in memory, hidden behind JNI, or delivered through staged logic.
#CyberSecurity #AndroidMalware #ReverseEngineering #BankingFraud #ThreatHunting #InfoSec #MobileSecurity #MalwareAnalysis