Manic hands stolen PINs to the phone next to it, up to four hops from any egress point

ThreatFabric published an analysis on 20 August 2026 of an Android family it calls Manic, described as a blend of banking malware and spyware, rated high severity and targeting 169 banking, government, eID, cryptocurrency and authentication apps ^[1][2][3]. The part that invalidates a common assumption: when Manic cannot reach its command and control server, it encrypts the collected data and looks for other infected devices nearby, relaying over Wi-Fi Direct, Bluetooth RFCOMM or Bluetooth LE GATT through as many as four hops until it finds a device with a direct internet connection ^[4][5].

The collection side is conventional and effective. After tricking the user into granting Accessibility and Notification Access, Manic draws a transparent overlay on the target app's numeric keypad and derives the PIN from where the user taps ^[6][7]. It then uses Accessibility to pass those taps to the real app, so the real screen keeps working normally ^[8]. According to the writeup, because the numbers are re-entered into the genuine app, users rarely notice anything is wrong unless an input fails ^[9]. Beyond PINs it takes SMS and notifications, screens, files, location, OTPs and recovery phrases, and uses WebRTC for remote control ^[10]. The app uses packers and loads DEX files in memory to resist analysis ^[11].

The relay is what deserves attention on the defensive side, because most mobile containment assumes a chokepoint: block the domain, cut the egress, isolate the handset. Manic treats absence of a path as a queueing problem, storing the data and retrying later, then sending it to the C2 once a connected device is available ^[12]. ThreatFabric's own detection guidance concedes the consequence: relay source devices may not show outbound internet traffic ^[13]. A four-hop chain implies as many as five infected devices cooperating on a single exfiltration path ^[14]. The artefacts on the originating device are therefore radio artefacts, not network ones: Wi-Fi Direct group formation, Bluetooth RFCOMM and BLE GATT traffic, and device-to-device relaying up to four hops ^[15].

That shifts the practical detection surface. The listed indicators are unknown apps holding Accessibility or Notification Access, in-memory DEX loading, continuous Bluetooth and Wi-Fi Direct scanning, and WebRTC traffic ^[16]. In corporate device management, the recommendation is to check app permissions and short-range wireless usage ^[17]. Mitigations offered are blocking installation of unmanaged apps and controlling Accessibility permissions, Mobile Threat Defense that detects overlays, in-memory DEX and abnormal permissions, verifying important transactions outside the mobile device or using hardware keys and other theft-resistant authentication, and turning off unnecessary Bluetooth and Wi-Fi Direct ^{[18][19][20][21]}.

Two gaps are worth holding in mind before anyone briefs an executive. The initial distribution method is not confirmed by public information, and email distribution specifically has not been confirmed, with no evidence that distribution links arrived by email ^[22][23]. No CVE and no identified threat actor are attached to the report ^[24].

Watch the account side rather than the device side, since the device side may be silent. The escalation signals given are authentication and account recovery using stolen OTPs, PINs or recovery phrases, and logins from IPs or regions other than the device's usual location ^[25]. The writeup also sets a triage ladder worth copying into your own runbook: attempt observed with success unconfirmed, user interaction confirmed at the point of Accessibility and Notification Access grants, and initial execution confirmed on any sign of overlays, screen capture or in-memory DEX ^[26].