My journey through the HackHazards 2026.
The Problem Nobody Was Solving Fast Enough
Every day, thousands of Indians receive a WhatsApp message with a link. "Update your SBI KYC." "Claim your bank reward points." "Your account will be suspended."
Some click. An APK downloads. And somewhere in a server farm, a criminal now has access to their OTP, their banking credentials, their life savings.
This is not hypothetical. Drinik, a banking trojan that specifically targeted 18 Indian financial institutions including the State Bank of India, infected victims by masquerading as the Income Tax Department's official app. It used Android's Accessibility Services to invisibly log keystrokes, suppress OTP notifications, and drain accounts — all while the victim saw nothing unusual on their screen.
When a bank's fraud team discovers a new suspicious APK circulating on WhatsApp, what happens? They hand it to a cybersecurity expert. That expert spends one to three days manually decompiling the code, reading through obfuscated Java, tracing network calls, and writing a report. By the time the report lands on a SOC analyst's desk, hundreds of customers may already be compromised.
That three-day gap is exactly what we built CyberShield to close.
What We're Actually Building (And What We're Not)
Before going further, let's be honest about scope — because hackathon projects often promise the moon.
CyberShield is not a consumer antivirus. It is not competing with Google Play Protect or Bitdefender. We are not trying to scan every app on every phone in India.
What CyberShield is: an AI-powered malware intelligence platform built specifically for the Security Operations Centers of Indian public sector banks. The primary user is a fraud analyst or SOC analyst at a bank who needs to answer one urgent question — "Is this APK that's circulating among our customers dangerous, and what should we do right now?" — in minutes, not days.
The Architecture: Eight Tools, One Brain
The core insight of our system is that no single analysis tool is sufficient. Modern banking trojans are designed to fool individual scanners. They pack their payload, obfuscate their strings, and use legitimate-looking permissions. The only way to reliably catch them is to triangulate across multiple independent analysis dimensions and look for the patterns that only emerge when you see all the evidence together.
Our backend pipeline chains eight specialized tools:
MobSF is our primary orchestrator. It performs static analysis on the APK — extracting permissions, API calls, certificate information, and network security configurations. A legitimate SBI app uses a verifiable Extended Validation certificate. A fake one uses a self-signed cert. MobSF catches that immediately.
JADX decompiles the DEX bytecode back into readable Java source code. This is where we look for things like DexClassLoader (the app is secretly loading a second malicious app), @JavascriptInterface (a WebView is being used to render a fake phishing login page), or USSD strings like *21*# (the app is programmatically forwarding your phone calls to the attacker, so they intercept your voice OTP).
Quark Engine is our behavioral analysis layer. Rather than just looking at what permissions are declared, Quark traces API call sequences and verifies — with mathematical certainty at Stage 5 confidence — whether READ_SMS and an HTTP upload function are operating on the exact same variable. If they are, that's not coincidence. That's OTP theft.
APKiD fingerprints the binary itself. It tells us whether the APK was compiled normally or if it was decompiled, injected with malicious code, and repacked. The presence of dexlib 2.x in the compiler field is a red flag: it means a legitimate banking app was trojanized and redistributed.
APKLeaks hunts for secrets baked into the code — Telegram Bot tokens (increasingly used by malware to exfiltrate stolen OTPs in real time), Firebase database URLs, hardcoded API keys, and IP addresses pointing to command-and-control servers.
Androguard goes deeper into the DEX structure, building cross-reference graphs. It can verify whether a declared BIND_ACCESSIBILITY_SERVICE actually connects through the code to functions that read screen content — the difference between an accessibility app for disabled users and a banking trojan.
Custom Strings Analyzer and Custom Manifest Analyzer are our regional intelligence layers. Standard tools don't flag Hindi-language strings like "Aadhaar link karein" or "PAN card update." We do. These are the social engineering hooks that trick Indian users into granting permissions. The manifest analyzer also detects apps that deliberately hide themselves from the launcher (no LAUNCHER category) to achieve silent, persistent operation.
All eight tool outputs feed into our Correlation Engine — a deterministic rule system that evaluates 17 cross-tool patterns. No single signal fires an alert alone. We require convergent evidence. Rule 3, for example, fires only when: the manifest requests SYSTEM_ALERT_WINDOW and APKLeaks finds a Telegram Bot token and Quark confirms SMS capture at Stage 5 confidence. That specific combination means one thing: a Telegram-backed overlay trojan stealing OTPs. Zero ambiguity.
The AI Layer: Making It Readable for a Fraud Analyst
Raw JSON from eight security tools is not useful to a bank fraud analyst. They're not malware researchers. They're financial professionals who need to make fast decisions.
This is where Generative AI becomes genuinely transformative in our stack — not as a gimmick, but as a translation layer.
After the deterministic engine computes its confidence score and fires its rules, we pass a structured summary to an LLM with a carefully designed system prompt:
"You are a senior malware analyst embedded in a bank's Security Operations Center. Your audience is a fraud analyst at an Indian public sector bank. Always contextualize findings in terms of risk to banking customers — OTP interception, credential theft, unauthorized transfers. End every explanation with a 'Recommended Action' line that tells the bank what to do right now, concretely and specifically."
The output is a human-readable Threat Brief that explains, in plain language: what this APK does, what banking customers are at risk, how it evades detection, and what the bank should do immediately — block specific IP ranges, force password resets for customers who may have installed it, alert the I4C (Indian Cyber Crime Coordination Centre), or push a fraud alert to affected account holders.
The AI doesn't replace the deterministic engine. It annotates it. The engine catches the threat; the AI explains it to the person who needs to act on it.
The Bank Dashboard: What Judges Will Actually See
The main product interface is a SOC dashboard designed for a bank's security team. It shows:
- A live feed of analyzed APKs with risk scores (0–100) and threat classifications
- AI-generated threat briefs in plain English for every scan
- MITRE ATT&CK technique mappings for each detected behavior
- Extracted indicators of compromise — suspicious domains, IP addresses, Telegram bot IDs, Firebase URLs
- Campaign clustering (when multiple APKs share infrastructure, they're likely from the same threat actor)
- Actionable recommendations specific to the bank's context
The upload flow is simple: drag an APK, watch nine analysis stages complete in real time, get a full intelligence report. What used to take a skilled analyst three days now takes the platform three to seven minutes.
The Malware Intake Layer: How APKs Get In
A bank's SOC doesn't proactively hunt for malware APKs. They learn about them when customers call in complaints, when fraud alerts fire, or when their threat intelligence feeds pick something up.
We designed CyberShield with multiple intake vectors. The primary one is direct upload through the dashboard. The secondary — and strategically important — one is a WhatsApp-based submission channel. A bank can publicize a number that customers and employees forward suspicious APKs or links to. The bot automatically routes received files into the analysis pipeline, creating a crowdsourced threat intelligence feed that grows more powerful as more people use it.
This turns the bank's customer base into an early warning network. When a new fake "SBI KYC Update" APK starts circulating, the first customers who receive it and get suspicious can forward it. The bank's SOC gets an alert within minutes rather than days.
Technical Stack
Backend: Python/FastAPI, running the full eight-tool analysis pipeline. Analysis is scheduled asynchronously via FastAPI's BackgroundTasks, so uploads return immediately and processing continues in the background.
Analysis Tools: MobSF (local instance), JADX, Quark Engine, APKiD, APKLeaks, Androguard, custom string/manifest analyzers — all orchestrated through subprocess calls and Python bindings.
Intelligence Engine: Custom Python correlation engine with 17 deterministic rules, a ConfidenceCalculator with weighted scoring, and an AttackChainBuilder that maps findings to the MITRE ATT&CK for Mobile framework.
AI Layer: Claude API / Groq endpoint for threat brief generation and interactive SOC analyst explanations, with section-specific prompting for permissions, network indicators, behavioral rules, and MITRE mappings.
Code Intelligence (GitNexus): A TypeScript RAG system using tree-sitter-java to parse decompiled code, embed it with snowflake-arctic-embed-xs via ONNX Runtime, and serve semantic + keyword hybrid search (BM25 + vector, merged via Reciprocal Rank Fusion) for deep code investigation.
Frontend: Next.js 16, React 19, Tailwind CSS. Four main views: Dashboard, Upload, Live Progress tracking, and Detailed Report.
Report Storage: JSON files on filesystem (filesystem-native for hackathon scale; PostgreSQL migration path planned).
Challenges We Actually Faced
The obfuscation problem. Modern banking trojans are specifically engineered to defeat static analysis. APKiD might tell us a file is packed with a commercial packer — but JADX then can't decompile the inner payload. Our correlation engine accounts for this: a packing detection alone raises suspicion, and we route heavily obfuscated APKs with a higher base risk score. Full dynamic sandbox analysis is on the roadmap.
False positives in APKLeaks. APKLeaks uses broad regex patterns and generates enormous amounts of noise — legitimate analytics domains, UUIDs, library constants. We had to build a filtering layer that cross-references extracted indicators against known-good lists and only surfaces the ones that appear alongside other corroborating signals.
The "one tool isn't enough" problem. Early in development we were tempted to just wrap MobSF with a GPT call and call it done. That would have been useless in production. A sophisticated banking trojan scores fine on MobSF in isolation. It's only when you combine APKiD's "this was repackaged" signal with Androguard's "the certificate CN claims to be SBI but is self-signed" signal with JADX's "this code implements a TextWatcher listening for SBI's package name" signal that the full picture of a targeted trojan emerges. Building the correlation engine to express these relationships correctly was the hardest and most important part of this project.
Making it legible to non-security people. The prompting work to get the AI to write threat briefs that are genuinely useful to a fraud analyst — not full of jargon, grounded in specific banking operations context, ending with concrete action — took significant iteration. The system prompt anchoring the AI as a "senior malware analyst embedded in a bank's SOC" turned out to be crucial. Without that framing, explanations were generic. With it, they were operationally specific.
Why This Matters for India Specifically
India's banking sector faces a uniquely intense mobile malware threat. The combination of rapid smartphone adoption, UPI-based payment infrastructure, widespread use of SMS OTPs as the primary 2FA mechanism, and a large population that may be less familiar with mobile security hygiene creates an exceptionally high-value target for threat actors.
The Drinik trojan specifically targeted 18 Indian banks. Fake apps impersonating SBI, ICICI, and other institutions circulate constantly on WhatsApp and Telegram. The government's own CERT-In has issued repeated advisories about banking trojans targeting Indian users.
Public sector banks — exactly the institutions this hackathon is designed to support — often have fewer dedicated cybersecurity resources than private sector peers. A tool that can dramatically reduce the analyst time required per APK investigation, while also being operable by fraud team members who aren't malware experts, has direct impact on their capacity to protect customers.
CyberShield is built specifically for this context. The regional signals (Hindi-language phishing strings, USSD call-forwarding codes, Aadhaar/PAN lures, fake government app impersonation), the SOC-analyst-friendly output, the WhatsApp intake channel — all of it is designed for the specific reality of banking security operations in India in 2026.
What's Next
The deterministic correlation engine we've built covers the known taxonomy of banking trojans well. The honest frontier is dynamic analysis — actually running suspicious APKs in an instrumented Android sandbox and watching what they do at runtime. Static analysis, however sophisticated, has inherent limits against packed and obfuscated malware. Dynamic analysis breaks through those limits. That's the next major engineering investment.
We're also working on malware family clustering — using the IOCs and behavioral signatures extracted from each analysis to group related APKs, map campaigns, and build threat actor profiles. When five different fake banking apps all phone home to the same Firebase instance, that's a campaign. Banks should know about campaigns, not just individual files.
The vision is a shared threat intelligence network across public sector banks — where an APK submitted to one bank's CyberShield instance enriches the threat intelligence available to all participating banks. Malware campaigns don't respect organizational boundaries. Threat intelligence shouldn't either.
Closing Thought
The gap between when a banking malware campaign begins and when a bank can act against it is measured in human suffering — customers who lose savings, elderly people who can't recover money drained by invisible trojans, small business owners whose accounts are emptied.
We built CyberShield because that gap is not technically inevitable. It exists because the right tools hadn't been assembled in the right way for the people who need them. The technology to close it — static analysis, behavioral correlation, generative AI explanation — all existed. We just had to put it together correctly and aim it at the right problem.
That's what this hackathon is for.
Top comments (0)