# Manic malware: When Isolating a Device No Longer Stops the Data Leaving

## Summary

On 20 August 2026, ThreatFabric's Mobile Threat Intelligence team published **Manic** — a new Android malware family actively distributed in the wild, sitting at the intersection of **Android banking malware and mobile spyware**.

Manic monitors **169 package IDs** covering banks, payment services, cryptocurrency wallets and exchanges, messaging apps, government and eID services, browsers and email clients. The focus is Ukraine, extending into Russia, Central and Western Europe, and the UK.

But the most significant thing in the report is not the capability list. It is a single sentence:

> **Removing direct internet access from an infected device does not necessarily prevent data exfiltration.**

Manic encrypts collected data with AES-GCM, places it in a local queue, then searches for **another infected device within radio range** over Wi-Fi Direct, Bluetooth RFCOMM or BLE GATT to relay it onward to C2 — with a default limit of **four hops**.

This is a store-and-forward mesh built out of other people's compromised phones. And for incident responders it breaks a foundational assumption: **network isolation is containment**. Here it is not.

**Priority action: update your mobile incident response playbook — for a suspected Android compromise, airplane mode is not sufficient; Bluetooth and Wi-Fi Direct must be disabled separately.**

* * *

## Timeline

![Timeline](https://www.threatfabric.com/hs-fs/hubfs/timeline-1.png?width=717&height=393&name=timeline-1.png align="center")

*Manic's activity timeline (source: ThreatFabric).*

| Date | Event |
| --- | --- |
| Feb 2026 | First associated infrastructure registered |
| Late Mar – Apr 2026 | Development and production services come online |
| Late May 2026 | First retained wrapper and implant observed |
| May – Jul 2026 | Infrastructure expands; the original development environment is gradually abandoned; a second deployment is prepared |
| Jul 2026 | Updated wrapper introduces **stronger anti-analysis checks, in-memory DEX loading and lock-secret phishing**; the new deployment brings an additional panel and API online |
| 20 Aug 2026 | ThreatFabric publishes its analysis |

The pace of evolution between May and July indicates a project under active development rather than a finished product.

One small detail reinforces this: the `reset_password` bot command remains in the dispatcher but **explicitly returns "not supported"** — the device-admin reset logic has been removed from the code. That is the trace of feature pruning, rarely seen in a mature malware family.

* * *

## Targeting: Where Banking Trojan Meets Spyware

| Set | Role | Notes |
| --- | --- | --- |
| **Banks** | Fraud targets | Ukraine is the primary focus; also Russia, Poland, Czech Republic, Slovakia, Austria, Germany, France, Spain, Netherlands, Estonia, Lithuania, UK |
| **Gov / eID** | Identity and state applications | Ukraine, Poland, Germany, Estonia, Lithuania, Czech Republic, Slovakia |
| **Payment apps** | P2P, BNPL, remittance |  |
| **Crypto exchanges** | CEX applications |  |
| **Crypto wallets** | Fraud targets |  |
| **Authenticators** | 2FA apps |  |
| **Messengers** | Notifications and file collection | Major commercial messengers **and military-focused messengers** |
| **Browsers / mail** | Session harvesting |  |

This spread is why ThreatFabric describes Manic as a blend. Financial fraud is clearly a major objective, with coverage across banks, payment services, cryptocurrency exchanges and wallets, government identity apps and authenticators.

But the targeting extends beyond financial applications to **commercial and military-focused messaging apps**, browsers and email. Combined with spyware capabilities such as location tracking, notification monitoring, file collection and remote device surveillance, this gives operators visibility into **both a victim's financial activity and their broader communications**.

This is where the line between financial crime and intelligence collection blurs. A toolkit built purely to move money does not need military messengers on its watch list.

![Manic capabilities](https://www.threatfabric.com/hs-fs/hubfs/Manic_capabilites.png?width=1920&height=1080&name=Manic_capabilites.png align="center")

*Overview of Manic's capabilities (source: ThreatFabric).*

* * *

## pinPadOverlay: An Overlay With No Fake Interface

This is the most technically interesting part of the report, and it has direct consequences for the awareness training most organisations currently run.

![The pinPadOverlay mechanism](https://www.threatfabric.com/hs-fs/hubfs/keypad.png?width=726&height=409&name=keypad.png align="center")

*The overlay covers only the combined bounds of the numeric keypad (source: ThreatFabric).*

The mechanism works as follows. When Manic finds a numeric keypad in a targeted app, it covers **only the combined bounds of those keys** — not the whole screen.

When the victim taps the overlay, Manic logs the tap position and the nearby UI element. It then **briefly disables touch interception and reproduces the tap at the same position through Accessibility**, allowing the real banking app to receive the input and continue normally.

Unlike a traditional phishing overlay, **Manic displays no fake banking interface at all**. It captures input directly from the legitimate app's own keypad.

The consequence for defenders deserves stating plainly: most Android banking trojan awareness content teaches users to **recognise an unusual interface** — a login screen that looks different, a mis-scaled logo, wrong fonts, a credential prompt in the wrong place. With Manic there is nothing unusual to recognise. Real app, real interface, real workflow, and the transaction still succeeds.

### Two PIN Capabilities to Keep Distinct

ThreatFabric describes two separate PIN-related mechanisms, and conflating them leads to a misjudged risk assessment:

| Capability | Operates where | Role |
| --- | --- | --- |
| `pinPadOverlay` | Inside an open banking app | **Theft** — captures the victim's taps on the real keypad |
| `autoEnterPin` | At the Android lock screen | **Reuse** — attempts to enter a stored credential or pattern |

The first records input during banking. The second **can give an operator access to a locked phone**. Those are two different levels of risk, and Manic has both.

* * *

## Accessibility as a Classifying Keylogger

Manic uses its Accessibility service as a UI keylogger, but not crudely. It **classifies captured text before recording it**, distinguishing seven categories:

```plaintext
1. Lock-screen input
2. Recovery-phrase candidates
3. Four- to six-digit SMS codes
4. Passwords
5. Long messages
6. Email logins
7. Ordinary text
```

Each keylog record carries full metadata: the app and package, the captured text, a timestamp, **whether the input came from Autofill or manual entry**, and **whether the app is on Manic's target list**.

Alongside this, SMS and notification access provide additional visibility into authentication flows, while WebRTC remote sessions let the operator watch the screen and interact with the device by abusing Accessibility privileges.

> **An observation of ours, at moderate confidence.** Classifying and labelling data on the device itself is the behaviour of a deliberately engineered product, not of a keylogger that records everything and ships it all. It allows prioritisation and filtering **before** data enters the exfiltration queue.
> 
> That fits neatly with the mesh design described below: a relay channel over Bluetooth or Wi-Fi Direct across several hops has far lower bandwidth and reliability than a direct connection to C2. Under those conditions, sending only what is worth sending is not a convenience feature — it is a **design requirement** for the mesh to be operationally meaningful at all.
> 
> ThreatFabric describes both characteristics but does not draw the connection between them; this is our inference. Verify independently before using it in formal reporting.

* * *

## The Mesh Relay: Mechanism and Detection Points

![Mesh relay diagram](https://www.threatfabric.com/hs-fs/hubfs/mesh.png?width=720&height=479&name=mesh.png align="center")

*The store-and-forward relay mechanism between infected devices (source: ThreatFabric).*

Manic uses a **store-and-forward relay** to exfiltrate data even when the infected device cannot reach the C2 server directly.

**The process:**

1.  Collected files and command results are **encrypted with AES-GCM** and placed in a local queue.
    
2.  The source device can remain entirely offline while the malware searches for a route.
    
3.  Manic first attempts to use an **established Wi-Fi Direct peer**, then queries **Bluetooth peers**, then **BLE peers**, to determine which have internet connectivity.
    
4.  If a suitable peer is found, the encrypted package is transferred to it and forwarded toward C2.
    
5.  If no route is available, the package remains queued and Manic retries later. **Additional detail ThreatFabric provided to The Hacker News:**
    

*   Each newly queued item receives a **four-hop relay limit by default**, though the configuration can change that value.
    
*   **Relay metadata carries the current hop count**, letting intermediate peers know how many legs a package has already travelled.
    
*   An online peer **can create a Wi-Fi Direct group itself when it finds no peers**. Every retained build uses **the same network name** and attempts to create the group **up to three times**. That last detail is the best network-layer detection point the report offers: **a fixed Wi-Fi Direct network name, shared across builds**, is something that can be scanned for in an enterprise environment with radio monitoring.
    

The direct consequence ThreatFabric states: removing direct internet access from an infected device does not necessarily prevent exfiltration, because another infected phone within radio range may act as its gateway.

* * *

## Command Set and Persistence

Manic supports 23 commands from C2:

| Command | Description |
| --- | --- |
| `remote_control` | Starts a live screen or front-camera session in WebRTC, screenshot or accessibility-component mode |
| `get_logs` | Packages the Accessibility activity log for return |
| `location` | Returns current coordinates, accuracy and timestamp |
| `screenshot` | Captures and returns a screen image when MediaProjection is active |
| `export_sms` | Exports stored SMS data |
| `export_calls` | Exports call history |
| `export_contact` | Exports contacts and associated details |
| `export_push` | Exports captured notification and push logs |
| `export_apps` | Exports the installed application list |
| `export_file` | Selects matching local files, archives them and returns the result |
| `send_sms` | Sends operator-supplied text to a supplied telephone number |
| `ussd` | Executes a supplied USSD code through TelephonyManager |
| `send_push` | Displays an operator-supplied local notification |
| `send_file` | Downloads a server-hosted file by key and writes it to a chosen local path |
| `delete_file` | Deletes a selected local file |
| `force_lock` | Locks the screen through the Accessibility service on supported Android versions |
| `geo` | Attempts to enable device location through automated settings interaction |
| `disable_gp` | **Attempts to disable Google Play Protect through UI automation** |
| `get_more_rights` | Drives runtime, notification-listener, all-files, overlay and battery-exemption permission flows |
| `refresh` | Rebuilds and patches filesystem, permission and credential state to the server |
| `reload_config` | Fetches and applies the latest `app_config.json` |
| `reset_password` | Present but explicitly returns "not supported"; device-admin reset logic was removed |
| `default` | No-operation placeholder in the dispatcher |

![Device Takeover flow](https://www.threatfabric.com/hs-fs/hubfs/dto.png?width=727&height=401&name=dto.png align="center")

*Manic's Device Takeover fraud path (source: ThreatFabric).*

**Persistence** relies on background workers, alarms, and the Accessibility and notification services. These components maintain C2 communication, process commands, upload queued data and **synchronise the offline mesh**, with periodic execution **every 10 to 15 minutes** depending on the build.

The July build also **removes the implant from the launcher**, relying on the wrapper or a deep link for activation — meaning the victim sees no icon to suspect or uninstall.

During remote-control sessions, Manic conceals activity behind **black, fake or update screens**, including overlays that hide permission prompts — so the victim does not see the operator granting the malware further privileges.

* * *

## Indicators of Compromise

> Indicators taken from the ThreatFabric report of 20 August 2026.

**Samples (SHA-256)**

```plaintext
80be0942d0e20b5006e240434f42512c8b3cd0d54eee858a25663c1a4224a576
    July wrapper          tech.intel.dialer.updater
 
feea425cde1223fe7afdd7a1ea631678ec6282f6cc20c3d3c0fb97cdbcf65b9b
    July dropped implant  org.lenovo.storage.processor
 
e7abc375f24d0dd2419e0bce4686c7301b3ee82ae38906c67d3481580f6c648e
    Primary implant       tech.apple.dialer.scheduler
 
7c12f1237090e32c18583f66f1a9e44b029ad7c1e61179e1d524fb3093abd59a
    Implant sibling       io.motorola.secure.executor
 
2884108b35eba7b8099087405653c1b23c3839f0d5058c4d61341fc31cfc6040
    May wrapper           org.honor.secure.helper
 
2fb5b01ea5a483d60b659e85327a53c6661bdd630d4afd93dc5fe0941d3ccbbe
    May implant           dev.huawei.media.helper
```

**Package naming pattern — the most huntable artifact**

```plaintext
tech.intel.dialer.updater
org.lenovo.storage.processor
tech.apple.dialer.scheduler
io.motorola.secure.executor
org.honor.secure.helper
dev.huawei.media.helper
```

The formula is highly consistent: **a non-standard TLD** (`tech`, `org`, `io`, `dev`) + **a hardware brand name** (Intel, Lenovo, Apple, Motorola, Honor, Huawei) + **a system-component-sounding word** (updater, processor, scheduler, executor, helper).

The key point: **none of these use the vendors' genuine namespaces.** The legitimate namespaces for these brands are `com.lenovo.*`, `com.huawei.*`, `com.motorola.*`. Using `org.`, `io.`, `dev.` or `tech.` with a hardware brand name is a pattern you can build detection on, and it generalises to unknown samples from the same family.

**Behavioural artifacts**

```plaintext
# Activity cadence
Background workers running every 10–15 minutes (build dependent)
 
# Mesh relay
Fixed Wi-Fi Direct network name, shared across builds
Up to 3 attempts to create a Wi-Fi Direct group
Default 4-hop limit; relay metadata carries the hop count
Channels: Wi-Fi Direct -> Bluetooth RFCOMM -> BLE GATT (in priority order)
Payload encryption: AES-GCM
 
# On device
Accessibility and notification access requested shortly after installation
Implant absent from the launcher (July build)
Overlay covering exactly the numeric keypad bounds inside banking apps
Overlays concealing permission prompts during remote-control sessions
In-memory DEX loading (July build)
```

* * *

## Assessment

**The mesh relay breaks the assumption that network isolation equals containment.**

This is the central point, and it has direct consequences for incident response procedure. Mobile compromise playbooks at most organisations follow a familiar sequence: enable airplane mode, disconnect Wi-Fi, seize the device, analyse later. That sequence rests on an assumption that held true for years — that cutting internet access cuts the data's route out.

With Manic, that assumption fails. Airplane mode disables cellular data and Wi-Fi, but **many Android devices allow Bluetooth to be re-enabled while in airplane mode**, and Wi-Fi Direct can operate independently of infrastructure Wi-Fi connectivity. If another infected device is within radio range — the same office, the same building, the same commuter train — the queued data still has a way out.

The correct measure here is more specific: **disable Bluetooth and Wi-Fi Direct separately**, or for sufficiently serious cases, place the device in a shielded bag. That is a small procedural change, but it needs writing into the playbook rather than leaving the responder to infer it.

**pinPadOverlay invalidates existing training content.** If your awareness programme teaches users to "watch for an unusual interface in your banking app", that content does not apply to Manic. There is no unusual interface.

The message that should replace it is different in kind: **granting Accessibility permission to an application that is not an accessibility tool is a serious warning sign, regardless of how normal everything looks afterwards.** Accessibility access is the prerequisite for nearly Manic's entire capability chain — keylogging, overlays, remote control, self-granting further permissions. It is the one decision point users genuinely control.

**The two most practical detection points** for managed environments:

*   **Unusual Accessibility service grants** to applications outside the approved catalogue.
    
*   **Bluetooth or Wi-Fi Direct connections from phones that are not actively transferring files** — peer-to-peer radio activity with no corresponding business reason. Neither requires prior knowledge of a hash or family name.
    

### Relevance for Vietnam

**To state it plainly first:** ThreatFabric lists targets in Ukraine, Russia, Central and Western Europe, and the UK. **Vietnam does not appear among the 169 package IDs documented**, and we draw no inference beyond the available data.

Three characteristics of the domestic market nonetheless make this technique worth tracking, independent of whether this specific campaign expands.

**First, market structure.** Android holds overwhelming market share in Vietnam, and mobile banking is the primary transaction channel for most individual users. A family targeting the "banking app on Android" combination is targeting the single most common usage pattern in the country.

**Second, Accessibility permission habits.** This is not a theoretical risk — domestic Android banking trojan campaigns have exploited exactly this habit for years, typically through apps impersonating public services or system utilities. What `pinPadOverlay` adds is making **the post-permission stage almost undetectable by eye**. Victims are already accustomed to "the app needs accessibility permission to work"; now they have no subsequent cue either.

**Third, device density.** Mesh relay does not depend on network infrastructure but on **the density of infected devices within radio range**. Vietnam's urban environment — high-density apartment buildings, office towers, public transport at peak hours — is favourable ground for this mechanism if infection rates in an area reach a certain threshold. This is a factor that enterprise network controls cannot reach.

**On BYOD.** For organisations allowing work email or internal application access from personal phones, Manic's `export_file`, `export_push` and WebRTC screen-sharing capabilities turn an infected personal device into a direct window onto organisational data. The difficulty here is structural: **MDM does not control unenrolled devices**, and most domestic BYOD policies stop at requiring a screen lock passcode.

* * *

## Recommendations

*   **Update the mobile incident response playbook:** for a suspected Android compromise, disable Bluetooth and Wi-Fi Direct separately rather than relying on airplane mode; for serious incidents, use a shielded bag.
    
*   **Shift awareness training focus** from "recognise an unusual interface" to "Accessibility permission is the decisive boundary" — it is the only control point users genuinely hold in this chain.
    
*   **Monitor two behaviours on managed devices:** Accessibility grants to applications outside the approved catalogue, and Bluetooth or Wi-Fi Direct activity with no corresponding business need.
    
*   **Turn the package naming pattern into a detection rule:** alert on applications using major hardware brand names with a non-`com.` TLD — a rule that catches unknown samples from the same family.
    
*   **For BYOD policy:** require MDM enrolment for any device accessing email or internal applications, and enable device health attestation rather than only requiring a screen lock.
    
*   **If a device is suspected compromised:** assume both the banking PIN and the screen lock code are exposed, change both from a separate device, revoke active sessions, and review transaction history — `pinPadOverlay` operates silently, so there is no indicator of whether a PIN was captured.
    

* * *

## References

*   ThreatFabric Mobile Threat Intelligence — [Manic: Blend between Banking Malware & Spyware](https://www.threatfabric.com/blogs/manic-blend-between-banking-malware-and-spyware) (20 August 2026) — original report
    
*   BleepingComputer — [New Manic Android malware can exfiltrate data through nearby devices](https://www.bleepingcomputer.com/news/security/new-manic-android-malware-can-exfiltrate-data-through-nearby-devices/)
    
*   The Hacker News — [Manic Android Malware Exfiltrates Data From Offline Phones via Nearby Infected Devices](https://thehackernews.com/2026/08/manic-android-malware-exfiltrates-data.html) — carries additional mesh detail supplied by ThreatFabric
    
*   Security Affairs — [Manic: The Android Malware That Exfiltrates Data Even When the Phone Is Offline](https://securityaffairs.com/197570/malware/manic-the-android-malware-that-exfiltrates-data-even-when-the-phone-is-offline.html)
    
*   Cyber Security News — [New Android Malware Manic Steals Banking PINs and Relays Data Through Peer Devices](https://cybersecuritynews.com/manic-android-malware/)