Dominic Jainy has spent years in the trenches of mobile security, bridging AI-driven detection, machine learning heuristics, and the gritty realities of Android incident response. In this conversation, he dissects Herodotus—a MaaS banking trojan that operates outside the Play Store, abuses Accessibility, and “humanizes” its actions to sidestep fraud engines. We explore how MaaS reshapes attacker economics, the SMS-to-install funnel, overlays for credential theft, why signature AV missed it, and a practical playbook for defenders: correlation steps, runtime app safeguards, and forensics that preserve evidence while starving the threat of oxygen.
Herodotus runs as Malware-as-a-Service and hides as a legit tool. How have you seen MaaS change attacker playbooks, and what’s new here? Walk us through a real incident, rough timelines, and the business model incentives that make this scalable.
MaaS turned one-off malware ops into repeatable franchises. Instead of bespoke builds, operators rent a kit, flip a few toggles, and outsource distribution to affiliates who get paid on installs or monetized sessions. In one case, the affiliate campaign spun up a landing page, seeded SMS lures, and had live infections within the same afternoon—fast enough that takedowns always trailed by a step. What’s new with Herodotus is the tight coupling of “looks-legit” packaging, outside-Store installs, and a post-permission detonation model that keeps it quiet until it owns the glass. The economics reward low-friction setup and stealthy persistence more than loud privilege escalation, and that’s exactly the niche it fills.
The malware spreads via SMS phishing that pushes APKs outside the Play Store. What do those lures look like in the wild, and how do users get convinced? Share examples, click-through rates you’ve observed, and the step-by-step path from link to install.
The lures mimic urgent service messages—missed deliveries, bank security checks, or telecom billing reminders—with a short URL and a calm, authoritative tone. The link opens a page themed to the spoofed brand with a friendly “Download the latest secure app” banner. From there, the page walks users to enable installs from unknown sources and taps “Install.” The social hack is the rhythm: urgency first, reassurance second, and a clean UI that feels familiar. I’ve watched victims move from tap to install in a few breaths when the branding lands.
It requests critical permissions, including Accessibility. Which exact prompts tip you off during install, and how do attackers nudge users to accept them? Give practical screenshots you’d expect, common social-engineering lines, and a sequence defenders should train for.
The giveaways are: “Allow from this source” for unknown apps, the Accessibility toggle flow that shows the service name, and any request to “display over other apps.” Expect screens nudging: “To protect your account, enable Secure Access,” with a subtitle like “Helps detect fraud.” Attackers sequence it: install prompt, open app, guided tour, then a forced detour into Settings > Accessibility with an arrow overlay pointing at the service. Defenders should train users to pause at Accessibility services that aren’t from their bank or OS vendor and to distrust any app that immediately asks for overlay rights.
You mentioned overlay attacks on banking apps for credential theft and session hijacking. Could you break down the overlay chain, from detection of a target app to the spoofed screen? Include timing, UI cues, and metrics on how long the window stays active.
The trojan monitors foreground packages; when a target banking app is detected, it raises a full-screen overlay that mirrors the bank’s login. The fake screen appears right after the legitimate splash, so it feels like a branded step. Once credentials are entered, the overlay dismisses and the real app continues, creating the illusion of a harmless hiccup. The overlay persists only as long as needed, then yields to avoid suspicion. To the user, it’s a blink—familiar colors, the right logo, and no jarring transitions.
The “humanization” technique uses random delays, micro-movements, and realistic typing. How do these patterns compare to real user behavior in data you’ve seen? Share timings, jitter ranges, and examples where this fooled anti-fraud systems, plus how to detect the subtle tells.
Real users don’t move in perfect grids; they hover, hesitate, and mis-tap. Herodotus imitates that with tiny drifts before taps and uneven keystroke pacing that feels organic. Anti-fraud systems that only look for straight-line automation or perfectly spaced intervals get duped. The tells are context-level: inputs that are “human-like” but eerily consistent across devices, or micro-movements that never overshoot edges. Signal fusion helps—mix UI focus changes, scroll inertia, and error frequencies to spot synthetic smoothness masquerading as messy human behavior.
Herodotus captures screen content and keystrokes in real time. What pipelines handle that data, and how is exfiltration timed to avoid alarms? Walk us through artifacts, bandwidth footprints, and the sequence from capture to transaction execution.
It hooks into Accessibility events for text fields and uses screen capture APIs or rendered-view scraping for visuals. Data is buffered locally, lightly encoded, and shipped over encrypted channels to blend with normal app traffic. Exfil happens in short bursts—often piggybacking on moments when the user is active—to avoid idle-time anomalies. Once credentials or session tokens are confirmed, the operator can push scripted actions that the malware plays back while the victim’s session is valid.
Analysts found no alerts in a leading antivirus signature database. Why does signature reliance fail here, and where do behavior models break down? Give concrete test results, false-negative rates, and how threat intel feeds could have caught this earlier.
Signatures stumble because everything looks like a clean utility until the user blesses the dangerous permissions. Behavior models break when they treat “user-approved” accessibility and overlay use as benign without examining sequence and intent. Threat intel could have flagged the SMS domains and the sudden cluster of installs from unknown sources tied to a single app certificate. The lesson is simple: lineage and sequence beat single-point indicators, especially when the binary itself wears a harmless costume.
The trojan performs banking operations while victims remain logged in. Describe the exact steps it takes post-login, including session handling, multi-factor bypasses, and transaction limits. Share case examples with timestamps and any bank-side telemetry you’ve reviewed.
After login, it reads on-screen balances and navigates via Accessibility gestures as if it’s the user. If a challenge appears, it can capture OTPs from notifications or prompt the victim under a pretext, then forward the values. It stays inside the live session to avoid new-device checks, moving quickly before timeout. On the bank side, telemetry shows ordinary device fingerprints and familiar navigation paths, which is why it blends in so well.
Initial access hinges on SMS phishing, unknown-source install, and user-approved permissions. How should defenders correlate these events in sequence? Provide a playbook: log sources, rules, priority scoring, and sample correlation queries that reduce noise.
Start with mobile threat telemetry: SMS parsing in MDM, package installer logs, and Settings changes for unknown sources and Accessibility. Correlate link-click events leading to a non-Store domain, followed by an install, then the enabling of an Accessibility service not on an allowlist. Score highest when these occur in close succession and the app later requests overlay capability. In a SIEM, stitch by device ID: sms.link_domain NOT IN approved_list AND install.source NOT IN store_list AND settings.change = accessibility_enabled AND appops includes SYSTEM_ALERT_WINDOW.
You highlighted screen overlays and simulated interactions as key signals. What indicators distinguish them from accessibility features for legitimate apps? Offer thresholds, heuristics, and example detections that worked in production without flooding analysts.
Legit apps disclose purpose and only foreground overlays during feature use; malware overlays near banking app launches without user initiation. Heuristics that work: flag overlay invocations that immediately follow detection of a banking package, and Accessibility actions that traverse multiple screens without corresponding touch events from the hardware input stack. Add a cooldown so a single assistive task doesn’t alert repeatedly. Require two or more co-occurring anomalies—overlay plus synthetic navigation—before paging an analyst.
Traditional antivirus missed it, but layered detection might not. If you had to design a control stack today, what are the top five checks, ordered by impact? Include deployment steps, tuning tips, and rough reduction percentages you’ve seen.
First, sequence-aware detection: correlate non-Store installs, new Accessibility services, and overlay grants. Second, SMS link reputation tied to device policy. Third, on-device runtime hooks that watch for overlays on protected apps. Fourth, notification hygiene—block unknown apps from reading or acting on OTP notifications. Fifth, user friction at the right time: interstitial warnings when enabling powerful services. Tune by allowlisting known enterprise tools and tightening on high-risk app categories.
On-device protections often flag one signal at a time. How can teams stitch together “harmless” events into a high-confidence alert? Share a real case study, the timeline of events, and the correlation logic that finally surfaced the attack.
In one case, three low-grade flags—unknown-source toggle, a new Accessibility service, and a brief overlay—each auto-closed as informational. We wrote a correlation rule that looked for that trio within a short window and tied it to a non-Store landing page click. The next run produced a single, high-confidence case with the full breadcrumb trail. Analysts moved from chasing noise to reviewing one coherent story with a clear containment decision.
For mobile app teams, what code or runtime defenses blunt overlay and accessibility abuse without hurting UX? Walk through implementation steps, user prompts that still convert, and measurable outcomes from A/B tests.
Use secure flags to block screenshots and detect overlays on sensitive screens, then gracefully pause with an inline prompt: “To protect your account, please close apps drawing over the screen.” Add in-app attestation to verify integrity and verify Accessibility presence only for declared assistive partners. Implement step-up checks when Accessibility is active: confirm intent with a simple challenge that’s tough to automate but easy for users. Teams report smoother drop-offs when the message is empathetic and explains the why, not just the what.
What forensics should responders capture first on an infected Android device running Herodotus? Detail a step-by-step triage checklist, key files and logs, volatile data to grab, and how to preserve evidence while limiting attacker actions.
Isolate the device from networks without powering it down—airplane mode with Wi‑Fi and Bluetooth off. Collect a full bugreport, package list, Accessibility settings (enabled_accessibility_services), app ops for overlays, and notification logs. Grab app data for the suspicious package, its shared prefs, and any cached web views; preserve SMS inbox and links. Then revoke Accessibility and overlay rights, uninstall only after evidence is sealed, and reset credentials from a clean device.
If you were advising a bank’s fraud team today, how would you tune risk engines for “humanized” automation? Share signal weights, session analytics to add, and examples where adding micro-movement profiles or dwell-time math shifted detection rates.
Weight sequence-aware risk higher than device novelty—penalize sessions where fresh app installs and Accessibility changes preceded login. Add micro-movement profiling that looks at scroll inertia, edge overshoots, and correction taps. Blend UI focus telemetry with keystroke variability; automation often nails the average but misses the messy corners. When those layers work together, the false comfort of “human-like” goes away, and risky sessions stand out even when everything else looks familiar.
Do you have any advice for our readers?
Treat any app that asks for Accessibility or overlay rights on day one as guilty until proven innocent. Install only from the official store, and if a text message tells you to rush, do the opposite—slow down and verify. For teams, move beyond single-signal alerts and make your tooling tell a story across SMS, install, permission, and behavior. The attackers are professionalizing; our defenses need the same discipline and choreography.