Android › Module 1 › Lesson 3
Banking Trojans
How Android banking malware overlays fake logins and drains accounts
Opening
The bank app is open — the screen you typed into may be a fake sitting on top of it.
You installed something that looked like a utility, a “cleaner,” a MOD game, or even a clone from a store ad. Later you open the real bank app from the icon you have used for years. A login form appears. It looks like the bank. You type the password. A second prompt asks for the SMS code Topic 5 told you never to give a stranger. You type that too, because the prompt is “on” the bank. What you could not see is the difference between the bank’s own UI and a hostile screen drawn over it, or a prompt driven by an Accessibility service you granted a flashlight last week. The theft is not a Hollywood exploit against the bank’s servers. It is you authenticating into the wrong surface. This lesson is defender-level mechanism only: enough to recognize overlay, fake login, Accessibility abuse, and OTP theft via SMS or notifications — and to refuse. You will not learn how to draw overlays, how to write an Accessibility exploit, how to intercept SMS in code, how to pack droppers, or how to test against a bank. You will not install crimeware “in a VM.” You will write refusal rules and a Settings checklist on YOUR phone, then lock notes in $HOME/cyberlium-lab. Official banking happens in the official app from a listing you matched in lesson 2, or from the bank site you typed.
1. A banking trojan is malware that waits for finance — then steals the login you meant for the bank
Names vary; the defender’s model does not. Unwanted software on the phone watches for you to open a financial app (or a web login) and then collects what you type or what the bank sends you as a second factor. Arrival is usually the last two lessons: a sideloaded APK, a clone listing, a “cleaner,” a porn or gambling wrapper, a fake update. After install, the package may hide its launcher icon so it does not sit next to the bank on the home screen. That is a persistence trick you recognize as “I cannot find the app I just installed,” not a recipe to hide your own software. You will not be taught dropper chains or how to conceal packages. You will be taught that an unexpected install plus a later weird bank prompt is one incident, not two coincidences.
Damage is account takeover and fraud: password, one-time codes, sometimes notification contents, sometimes a lock that makes uninstall hard if Device admin was granted. Unique passwords from Topic 4 still matter — a harvested bank password must not open mail — but they do not undo a transfer you authorized on a fake screen. MFA still matters, which is why the malware wants the code too. Topic 5’s rule carries unchanged: a live OTP is the have-factor. Typing it into a surprise prompt that appeared over the app is finishing someone else’s login. Banks do not need you to volunteer that code to a layer you did not expect.
2. Overlay and fake login: you are typing into the wrong surface — refuse, do not study it
At defender level, an overlay is a fake window drawn on top of another app so the pixels you trust are not the app you opened. A fake login is that idea applied to credentials: the real bank may be underneath or in the recents list while the form you filled belongs to malware. You do not need the graphics API. You need the user-facing tell: the bank suddenly wants a full password re-entry at an odd time, the UI looks slightly off, a prompt appeared the moment you opened the bank, or a “security check” covers the whole screen after a new utility was installed. The safe action is stop typing. Leave the prompt. Force-stop or ignore it. Open the bank only from the verified icon after you have checked that no unknown apps and no unknown Accessibility services are sitting on the device — or use a second device you trust, or call the number printed on the card. You never complete the suspicious form “to see if it submits.” Completing it is the harvest.
This course will not explain how overlays are implemented, how to detect other packages from inside an app, or how to draw over the lock screen. Those are construction details. If a prompt feels wrong, it is wrong enough. If you already typed a password or a code, that is incident response: contact the bank on the card number, rotate from a clean device if you can, do not keep experimenting on the same phone. Later modules cover “if infected.” This lesson’s job is refusal before the paste.
3. Accessibility for a “cleaner” is a red flag — OTP via SMS or notifications is the second steal
Accessibility services exist so people who need assistive technology can use the phone: read screens, tap on their behalf, filter content. The same permission is powerful: it can observe what other apps show and act on them. A bank does not need a random battery saver to have that power. A game does not. A flashlight does not. When a utility, clone, or “optimizer” (fictional example: com.ultra.battery.example) asks to become an Accessibility service, that is a stop — not a performance feature. You refuse. You do not grant it “just this once to see the cleaner work.” You will not be taught how abused Accessibility is wired. You will treat the permission prompt as the tell.
One-time codes arrive as SMS or as notifications. Malware that was allowed to read SMS, or to listen to notifications, can learn the code that was meant for your eyes. Combined with a harvested password, that is enough for a short window of fraud. Topic 5 already forbade forwarding OTPs to a text thread. The Android sequel is: do not type an OTP into a prompt that appeared over the bank app, and do not grant SMS or notification access to apps that are not the messenger or the bank you chose. Real banks collect the code inside their own app after a login you started, or they use an in-app approval. A full-screen “paste the SMS here to continue” over a utility you just installed is not the bank. Settings → Apps → [app] → Permissions / Notifications / SMS is where you look on YOUR phone — not on a malware sample.
4. Wrong vs right: finishing the overlay vs refusing and using the official channel
Worked failure — same surprise login over the bank icon, opposite money movement. Right never includes building or testing overlays.
Wrong
Type the PIN, password, and SMS code into the covering prompt “because the bank icon is open.” Grant Accessibility to a cleaner or game. Grant SMS to a flashlight. Keep a clone bank app next to the real one. Call a number shown on the overlay. Install a “security tool” APK to remove the trojan. Practice overlays or Accessibility capture against a bank, even your own, as a lab. Detonate crimeware to screenshot the UI.
Right
Stop typing. Leave the prompt. Confirm the bank app came from the listing you matched (lesson 2) or the site you typed. Refuse Accessibility for utilities. Never give an OTP to a surprise overlay (Topic 5 MFA). If you already typed secrets, call the number on the card from a separate phone. Review YOUR Accessibility, notification, and SMS permissions in Settings. Notes in $HOME/cyberlium-lab with chmod 600 — no live bank passwords in the file.
5. Practical: permission refusal list on YOUR phone — never a malware sample
On YOUR device, open Settings → Accessibility and list every service that is on. Open notification access / notification listener (wording varies) and SMS permission for apps that are not your actual messenger. Write what you do not recognize. You are not hunting stalkerware yet (next lesson) and you are not installing a banking-trojan demo. You are checking whether a cleaner, game, or unknown package holds keys it should not. Save the checklist to $HOME/cyberlium-lab/bank-trojan-refusal.txt and chmod 600. If intimate-partner or coercive control is in the picture, skip aggressive uninstall theater that could escalate; next lesson covers safety-first. If you only need banking hygiene, unknown Accessibility off, unknown SMS off, official bank app only.
Command guide
Defender refusal checklist — YOUR Settings, fictional permissions only
DEFENSIVE. YOUR phone. No crimeware. No overlay labs. No bank attacks.
Command — copy this
mkdir -p "$HOME/cyberlium-lab" NOTES="$HOME/cyberlium-lab/bank-trojan-refusal.txt"
Command — copy this
{
echo "=== RECOGNIZE (not construct) ==="
echo "overlay_or_fake_login: surprise full-screen login over the bank → STOP typing"
echo "accessibility_red_flag: cleaner/game/flashlight asking for Accessibility → REFUSE"
echo "otp_rule: never type SMS/notification codes into a prompt that appeared over the app"
echo "topic5_mfa: live OTP is the have-factor — surprise overlay is not the bank"Command — copy this
echo "" echo "=== MY PHONE (Settings) ===" echo "Accessibility services ON (name each; unknown → off if safe to):" echo "Notification access / listeners:" echo "Apps with SMS besides my messenger:" echo "Bank app source: Play listing I matched / site I typed / OTHER (fix if OTHER)"
Command — copy this
echo "" echo "=== FICTIONAL package (do not install) ===" echo "com.ultra.battery.example — 'cleaner' + Accessibility + SMS = refuse, do not detonate"
Command — copy this
echo "" echo "if_I_already_typed_a_secret: card number on a separate channel; no more experiments on this prompt" } > "$NOTES"
Command — copy this
chmod 600 "$NOTES"
Windows: WSL/Git Bash, or restrict the file in your profile.
NEVER: build overlays, Accessibility stealers, SMS interceptors, or droppers NEVER: install banking malware "to see the fake login" NEVER: store real bank passwords, PINs, or OTPs in NOTES
Mission: refusal notes in bank-trojan-refusal.txt (mode 600)
Write, in defender language only: (1) overlay/fake login means you typed into the wrong surface — stop; (2) Accessibility for a cleaner/game is a red flag — refuse; (3) OTPs via SMS/notifications must not go into a surprise prompt (Topic 5). List YOUR Accessibility / notification / SMS findings. Save to $HOME/cyberlium-lab/bank-trojan-refusal.txt and chmod 600. Do not install malware. Do not attack a bank.
Stuck? Ask Cyberlium AI Mentor
If “the bank was open so the form must be the bank” still feels true, ask for a hint — not an overlay demo. Try: "Hint only: why can a fake login sit on top of the real app, why is Accessibility on a cleaner a red flag, and why must I not type an OTP into that prompt — without telling me how to build any of it?" You still fill the notes. No samples, no bank tests.
You now treat a surprise login over the bank as the wrong surface, Accessibility-for-a-cleaner as a refuse, and OTPs as codes you never give a covering prompt. Official banking stays on the official app from a listing you matched. Next — Spyware Indicators — battery, hidden icons, Device admin, always-on location, and what to do when the goal is watching a person rather than draining an account, including safety-first if someone close may be involved.
Knowledge Check
APPLY: You open the official bank app. A full-screen “re-login + SMS code” covers it right after you installed a “cleaner.” What happened at defender level, and what do you refuse?
Multiple choice
Knowledge Check
APPLY: com.ultra.battery.example (fiction) asks for Accessibility and SMS. A classmate wants to install it to “watch the overlay.” Correct lab?
Multiple choice
Knowledge Check
APPLY: True or False: If the real bank app is in recents, typing your password and the SMS OTP into a prompt that appeared on top is safe because MFA from Topic 4 will block the attacker.
True or False