Sudarshan: Autonomous Banking Fraud Intelligence

Batch mode scans many APKs at once and summarizes clean, suspicious and malicious counts for large-scale triage.
A structured dossier per case: executive summary, evidence references and deterministic score, built for legal review.
From APK upload to court-ready verdict: decompile, detonate, reconstruct the attack, score, report.
Built-in sandbox containment, authentication and RBAC. Clearly separates what works today from what is planned.
FastAPI orchestration, static and dynamic engines, risk engine and AI layer, with a React SOC dashboard. Auth and RBAC throughout.
Four pillars: static analysis, dynamic sandbox, deterministic risk scoring, and evidence-constrained intelligence.
Every verdict traces to evidence records across static, runtime, visual and network sources. Rules engine labels it; no AI involved.
A searchable case ledger with risk score, classification and timestamp, so SOC teams can revisit any investigation.
A structured dossier per case: executive summary, evidence references and deterministic score, built for legal review.
Drop in an APK and ask: is this app safe to trust? Analysis, sandbox, threat intel and scoring run automatically.
Risk is a transparent 0-100 rules-based score. Same evidence, same score; the AI layer cannot alter it.
Sudarshan hunts fake banking apps: decompile, sandbox, correlate, then a deterministic fraud verdict backed by evidence.
Fraud apps move faster than analysts. Sudarshan turns raw malware signals into evidence-backed fraud intelligence.
Suspect apps run in an isolated Android sandbox with Frida, capturing permission abuse, overlays, network calls and credential theft.
Findings are correlated with known malware families, showing confidence, reasoning and the recommended response.

Inspiration

It's 9:47 PM. Your phone buzzes.

SBI: Your YONO KYC has expired. Update within 24 hours to avoid account suspension: sbi-kyc-update.apk

The app you install looks right: the same blue, the same logo, the same fonts. It politely asks you to "enable Accessibility protection to keep your account safe." You tap Allow.

Ninety seconds later it's over. That one permission lets the app read your screen and tap buttons for you. It draws a fake login over your real banking app and catches your PIN. It swallows the OTP text before you see it. Trojan families like Drinik, Xenomorph, SOVA, Anubis, Cerberus, Hydra, Octo and Teabot have made this routine across India's UPI-first economy.

Meanwhile, a bank's fraud analyst has a queue of suspicious APKs and tools that don't help much:

VirusTotal says "0 detections" on a fresh build nobody has seen yet.
Static analyzers hand back thousands of lines of bytecode.
Manual reverse engineering gives the right answer after hours per sample.
"Just ask an LLM" gives a confident verdict that changes each time you ask.

We wanted a tool that gives the answer in minutes, and a verdict that holds up in an audit. We named it Sudarshan, after the Sudarshana Chakra, the discus that never misses its mark. The name means "auspicious vision", or the one that sees clearly.

Sudarshan home: drop an APK or paste a suspicious link

What it does

Sudarshan is a fraud-intelligence platform for Android banking trojans. Give it an APK, or just the suspicious link from the SMS, and it answers the three questions a fraud team actually asks:

Who is targeted? It detects visual clones of 10 major Indian banks (SBI, HDFC, ICICI, Axis, PNB, Bank of Baroda, Bank of India, Kotak, IndusInd, Union Bank) by comparing layout, colour, text and the signing certificate.
What can it do? OTP interception, fake login overlays, automated transfers, remote control. Every capability is backed by recorded evidence, not a guess.
What do we do now? A 0–100 Fraud Risk Score and a playbook: revoke sessions, block the C2 server, warn customers, export IOCs.

Around that core, analysts get:

Batch scan: 2–50 APKs queued at once, each becoming its own case.
URL discovery: paste the SMS link and Sudarshan crawls it in isolation and pulls out any APKs it serves.
Ask Sudarshan: question a case in plain English, with answers grounded in that case's evidence.
Reports: an executive PDF, a technical SOC report, interactive HTML and a STIX 2.1 bundle.

Case history with verdicts and risk scores

Threat intelligence view for a Hydra sample: what was found, why, and what to do next

Three promises

It says "I couldn't see this", never a false "Safe". If a trojan plays dead in the sandbox, the run is marked INCOMPLETE_EXERCISE, the dynamic axis is left out of the score instead of counted as zero, and a safety floor refuses the "Safe" label.
The AI never touches the score. Deterministic code produces the number. The assistant only explains it and cites the records it used.
When it doesn't know, it tells you what to try. Triggers the run never reached are listed, along with a time-warp, a synthetic victim persona and an anti-evasion sequence to coax them out.

How we built it

Each sample goes through four stages:

Decompile. Androguard, JADX and APKTool open the APK. We also repair APKs that were deliberately corrupted to crash analysis tools. Then our Visual Impersonation Detection Engine (VIDE) asks whether the app is pretending to be a bank, on four independent axes: layout tree-edit distance, CIEDE2000 colour distance, fuzzy text matching, and a signer-certificate registry that fails closed.
Detonate. The app runs inside a sealed Android sandbox with Frida 17 hooks on the sensitive APIs. An autonomous agent taps through login screens and dialogs to trigger hidden behaviour. It perceives the screen through five layers, from UI Automator XML down to an OCR fallback for Flutter and canvas UIs.
Correlate. Hashes and contacted domains are checked against VirusTotal, AlienVault OTX and AbuseIPDB, and behaviour is matched to known trojan families.
Score. A deterministic engine combines everything:

$$\text{FRS} = 0.25\,\text{STEI} + 0.35\,\text{BFCI} + 0.20\,\text{Correlation} + 0.20\,\text{BankingImpact}$$

STEI is the static threat index. BFCI is a behavioural fingerprint over seven weighted runtime categories, led by Accessibility abuse (0.315) and SMS interception (0.225). Scores map to four bands: Safe (up to 30), Suspicious (up to 60), High Risk (up to 89) and Critical.

Four safety floors refuse a "Safe" verdict when a sample hid a payload, evaded the sandbox, was never fully exercised, or already showed strong fraud capability statically. A high-confidence bank clone, signed by someone other than the bank, that also abuses Accessibility triggers the CH27 on-device fraud triad and forces Critical (FRS 95 or more).

The AI sits outside the verdict. "Ask Sudarshan" runs on Google Gemini over an in-memory graph of the case's evidence, with no web access. Every APK-derived string is sanitised against prompt injection, and a circuit breaker means scoring never depends on the AI being up.

Stack: a FastAPI gateway and a separate analysis-engine microservice, a React 18 + Vite analyst console, JWT auth with three RBAC roles, SQLite or PostgreSQL, mitmproxy for traffic capture, Genymotion or AVD as the guest, and Docker Compose for deployment.

Challenges we ran into

Keeping the AI out of the verdict. An LLM-written risk score sounds convincing and isn't reproducible. We made scoring a fixed formula and limited the AI to explanation.
Malware attacking the analyst. Strings inside a malicious APK can carry prompt injection aimed at an assistant. We sanitise everything that comes from the APK.
Trojans that do nothing until you log in. Many wait for a banking app, an OTP SMS or an Accessibility grant. We built an agentic explorer with a screen graph so it never loops, and we record "not observed" as not observed, never as not present.
Telling evasion from our own tooling. Some anti-analysis checks fire because of our instrumentation, not because of the sample, so we separate the two before applying the evasion floor.
Frida 17. It removed the Java global, so every hook ships as a compiled frida-java-bridge bundle.
Hostile and broken APKs. Some are corrupted on purpose, so we had to repair them before analysis.
Containing live malware. The dynamic engine runs real trojans, so an ADB gateway blocks risky commands, and production mode fails closed if the host network is exposed.
Real-world limits. VirusTotal allows about 4 requests a minute, so we added a 24-hour cache. A single emulator forces dynamic runs to queue.

Accomplishments that we're proud of

A fully deterministic, auditable score. The same APK gets the same score every time, and every point traces back to evidence.
Validation on real malware, not fixtures: a labelled corpus of 8 real banking trojans (Anubis, Cerberus, Drinik, FluBot, Hook, Octo, SharkBot, Teabot) and 9 clean apps. On static analysis alone, all 8 trojans land above Safe and all 9 clean apps land Safe. Results are stored with a digest, so any change that moves a score fails a check.
A grounded assistant that cites its evidence and cannot change the score.
An end-to-end workflow from sign-in to a signed-off report, including STIX 2.1 export.
2,860 automated tests collected (2,833 passed, 27 skipped because they need hardware or a live sandbox, 0 failed).
A clear list of limits, written down next to the features.

What we learned

In fraud, trust matters more than cleverness. An analyst only acts on a verdict they can see the reasons for.
LLMs are best used as translators, not judges.
Attackers hide behaviour, so you have to coax it out, and be honest about what you didn't see.
Safety floors that refuse a bad answer are often worth more than a better score.
Docs and tests are part of the security story, not extras.

What's next for Sudarshan

Sleeper malware: longer soak windows on a pool of dedicated devices, and per-family trigger playbooks.
A less detectable guest: physical hardware or a hypervisor-level path, so fewer samples notice the sandbox.
Second-stage payloads: automated re-analysis of dropped payloads, which is manual today.
More banks and more evidence: real signer certificates provisioned in the registry, a wider impersonation corpus, and more validated trojan families.
Plugging into bank operations: feeding IOCs and C2 blocklists into a bank's SOC workflow, and sharing STIX 2.1 bundles between institutions. These are directions, not partnerships.

Built for defenders, and meant to be used only in isolated, authorised environments.