A newly documented Android malware family dubbed Manic is actively targeting users across multiple European countries, and it introduces an exfiltration technique defenders need to understand immediately: when the malware cannot reach its command-and-control (C2) infrastructure directly, it falls back to relaying stolen data through nearby infected devices — using local, device-to-device communication channels as a covert egress path.
This is a meaningful tactical evolution. Traditional mobile malware defenses are built around the assumption that exfiltration requires internet egress — which means egress filtering, DNS monitoring, and mobile threat defense (MTD) solutions that watch outbound connections are the primary control layer. Manic breaks that assumption. A device on a segmented corporate network with no direct internet path to attacker infrastructure can still be drained of data if another compromised device nearby has connectivity. Think of it as a mesh-based exfiltration relay: proximity becomes the attack surface.
For organizations with BYOD programs, frontline mobile workforces, or executives traveling in Europe, this is not a theoretical concern. If you manage Android devices in your environment, you need to reassess what "contained" actually means for a compromised handset.
Technical Analysis
What Manic Does
Based on the reporting, Manic is a data-stealing Android malware family with the following notable characteristics:
- Geographic targeting: Users in multiple European countries, suggesting either region-specific lures (localized smishing, banking trojan overlays) or distribution through regionally popular app channels.
- Primary function: Data exfiltration from infected devices.
- Fallback exfiltration mechanism: When direct C2 communication fails — whether due to blocking, lack of connectivity, or sandboxing — Manic can transfer stolen data to other infected devices in physical proximity, which then relay it onward when they have a working path out.
The Attack Chain (Defender's Perspective)
While full technical details are still emerging, Android malware of this class typically follows a predictable chain. Defenders should instrument each stage:
- Delivery / Installation. Sideloaded APKs delivered via SMS phishing (smishing), malicious ads, trojanized apps on third-party stores, or droppers on Google Play that pull the payload post-install. Observable artifact: package installation from unknown sources (
INSTALL_SOURCE_UNKNOWN), ADB-initiated installs, or Play Store packages with anomalous permission sets. - Permission abuse. Android stealers of this class almost universally request high-risk permission combinations: Accessibility services (for overlay attacks and self-protection), SMS read/send, contacts, storage access, and often Notification Listener access to intercept 2FA codes.
- Collection. Harvesting of SMS, contacts, call logs, files, credentials, and application data within the sandbox's reach (expanded via Accessibility abuse).
- Primary exfiltration. HTTPS to attacker C2. Observable: TLS connections to low-reputation domains, non-Play-Store apps generating sustained outbound traffic, beaconing intervals.
- Fallback exfiltration (the novel piece). Local peer discovery and relay to nearby infected devices. On Android, this class of behavior is most plausibly implemented over Google Nearby Connections API, Bluetooth / Bluetooth LE, or Wi-Fi Direct — the same legitimate frameworks used by file-sharing apps. Observable artifacts: apps holding
BLUETOOTH,BLUETOOTH_ADVERTISE,BLUETOOTH_CONNECT,NEARBY_WIFI_DEVICES, orACCESS_FINE_LOCATIONpermissions (location is required for BLE scanning on Android) with no legitimate reason; BLE advertising/scanning activity by non-system packages; Wi-Fi Direct group formation initiated by third-party apps.
Why the Fallback Channel Matters Defensively
The mesh-relay design defeats several common controls:
- Egress blocking is no longer sufficient. A compromised device on an isolated or tightly filtered network segment can still offload data via a nearby peer that has open egress.
- Per-device containment assumptions break. Quarantining one infected device's network access does not stop exfiltration if it can still radio to a peer.
- Attribution and scoping get harder. During IR, the exfil path may traverse devices you haven't identified as compromised. Your blast-radius analysis must now include proximity, not just network topology.
Exploitation Status
This is an active, in-the-wild malware campaign targeting European Android users — not a theoretical proof-of-concept. No CVE is associated with this reporting; Manic is conventional Android malware, not an OS vulnerability exploit. Distribution and infection rely on social engineering and permission abuse rather than platform exploitation, which means user-behavior and permission-hygiene controls are your primary prevention layer.
Detection & Response
A candid note up front: Android endpoints are notoriously under-instrumented in enterprise SOCs. Most of your visibility will come from MDM/MTD telemetry ingested into your SIEM, network-layer observation of mobile VLANs, and DNS/proxy logs. The detections below are built for that reality.
SIGMA Rules
The following rules target observable behaviors in the Manic kill chain: sideloaded package installation (via logged process/telemetry), suspicious high-risk permission grant combinations, and anomalous local-radio activity by third-party apps (logged where MTD/EDR mobile telemetry is forwarded to the SIEM as process or network events).
---
title: Android Package Installation from Unknown Source
description: Detects Android package installation events originating from sideloading or ADB rather than managed app stores, a common Manic-class malware delivery vector. Fires on telemetry forwarded from MDM/MTD or Android logging pipelines.
references:
- https://www.bleepingcomputer.com/news/security/new-manic-android-malware-can-exfiltrate-data-through-nearby-devices/
- https://attack.mitre.org/techniques/T1476/
author: Security Arsenal
date: 2026/04/06
status: experimental
tags:
- attack.initial_access
- attack.t1476
logsource:
product: android
category: process_creation
detection:
selection_pm:
CommandLine|contains:
- 'pm install'
- 'pm install-unknown-sources'
- 'adb install'
selection_installer:
InstallerPackageName|contains:
- 'com.android.shell'
condition: selection_pm or selection_installer
falsepositives:
- Enterprise MDM-driven app deployment (filter by known MDM installer package names)
- Developer/QA devices with ADB enabled
level: medium
---
title: High-Risk Android Permission Combination Granted to Third-Party App
description: Detects third-party Android applications holding permission combinations characteristic of data-stealing malware with local relay capability — Accessibility plus SMS plus Bluetooth/nearby-device radios. Requires MTD/app-inventory telemetry ingested into the SIEM.
references:
- https://www.bleepingcomputer.com/news/security/new-manic-android-malware-can-exfiltrate-data-through-nearby-devices/
- https://attack.mitre.org/techniques/T1429/
author: Security Arsenal
date: 2026/04/06
status: experimental
tags:
- attack.collection
- attack.exfiltration
- attack.t1429
logsource:
product: android
category: application_inventory
detection:
selection_accessibility:
GrantedPermissions|contains: 'android.permission.BIND_ACCESSIBILITY_SERVICE'
selection_sms:
GrantedPermissions|contains:
- 'android.permission.READ_SMS'
- 'android.permission.RECEIVE_SMS'
selection_radio:
GrantedPermissions|contains:
- 'android.permission.BLUETOOTH_ADVERTISE'
- 'android.permission.BLUETOOTH_CONNECT'
- 'android.permission.NEARBY_WIFI_DEVICES'
filter_system:
InstallerPackageName:
- 'com.android.vending'
- 'com.google.android.gms'
IsSystemApp: true
condition: selection_accessibility and selection_sms and selection_radio and not filter_system
falsepositives:
- Legitimate accessibility tooling or MDM agents — allowlist by package hash/name
level: high
---
title: Third-Party Android App Initiating BLE Advertising or Wi-Fi Direct Activity
description: Detects non-system Android applications performing Bluetooth LE advertising/scanning or Wi-Fi Direct group formation — the local-radio behavior Manic-class malware uses to relay exfiltrated data to nearby infected peers. Requires mobile EDR/MTD network-activity telemetry.
references:
- https://www.bleepingcomputer.com/news/security/new-manic-android-malware-can-exfiltrate-data-through-nearby-devices/
- https://attack.mitre.org/techniques/T1011/
author: Security Arsenal
date: 2026/04/06
status: experimental
tags:
- attack.exfiltration
- attack.t1011
logsource:
product: android
category: network_connection
detection:
selection:
LocalTransport|contains:
- 'bluetooth_le'
- 'ble_advertise'
- 'wifi_direct'
- 'nearby_connections'
filter_known:
PackageName|startswith:
- 'com.google.android'
- 'com.android'
- 'com.samsung'
condition: selection and not filter_known
falsepositives:
- Legitimate file-sharing, wearable-companion, and IoT apps — tune by package allowlist in managed fleets
level: medium
KQL (Microsoft Sentinel / Defender)
If you ingest MTD telemetry (Microsoft Defender for Endpoint on Android, or a third-party MTD forwarded via CEF/Syslog), hunt for the delivery and permission-abuse stages. This query pivots across process events for sideloading and app inventory for the high-risk permission stack:
// Hunt 1: Sideloaded APK installs via shell (ADB or local pm) on managed Android devices
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where DeviceOsPlatform =~ "Android" or DeviceType =~ "Android"
| where ProcessCommandLine has_any ("pm install", "adb install", "install-unknown-sources")
or InitiatingProcessCommandLine has_any ("pm install", "adb install")
| project TimeGenerated, DeviceName, DeviceId, FileName, ProcessCommandLine,
InitiatingProcessCommandLine, AccountName, RemoteIP
| order by TimeGenerated desc;
// Hunt 2: Third-party apps with malware-characteristic permission stack
// (Accessibility + SMS + nearby-radio permissions) — requires app inventory ingestion
let SuspiciousPerms = dynamic([
"android.permission.BIND_ACCESSIBILITY_SERVICE",
"android.permission.READ_SMS",
"android.permission.BLUETOOTH_ADVERTISE",
"android.permission.NEARBY_WIFI_DEVICES"]);
DeviceInfo
| where TimeGenerated > ago(7d)
| where OSPlatform has "Android"
| join kind=inner (
AlertEvidence
| where TimeGenerated > ago(14d)
| where EntityType =~ "Process" or EntityType =~ "File"
) on DeviceId
| summarize Alerts=count(), AlertTitles=make_set(Title, 5) by DeviceName, DeviceId, OSPlatform
| order by Alerts desc;
// Hunt 3: Outbound beaconing from mobile VLAN / guest wireless to low-reputation hosts
// Useful when devices sit behind corporate proxy/firewall with CEF ingestion
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP startswith "10.50." // <-- replace with your mobile/BYOD subnet(s)
| where DeviceAction in ("allow", "permit")
| summarize BytesSent=sum(tolong(SentBytes)), Connections=count(),
FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
by SourceIP, DestinationHostName, DestinationIP, DestinationPort
| where Connections > 200 and BytesSent < 500000 // high-count, low-volume = beaconing pattern
| order by Connections desc;
Velociraptor VQL
Velociraptor doesn't run on Android handsets, but it does run on the Windows and Linux workstations that interact with them — and that's where you'll find forensic evidence of sideloading. If Manic or a dropper APK was installed via ADB from a managed workstation (developer machines, kiosk provisioning stations, or an attacker using a compromised host to stage devices), this artifact surfaces it:
-- Hunt for ADB-based APK installation activity from managed endpoints
-- Targets workstations where adb.exe was executed to push/install packages,
-- plus staging directories where APK payloads were dropped before installation.
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)adb'
OR CommandLine =~ '(?i)adb (install|push|sideload)'
OR CommandLine =~ '(?i)\.apk'
-- Sweep common staging locations for APK artifacts on endpoints
-- Flags APK files in Downloads/Temp/Desktop modified in the last 30 days
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
'C:/Users/*/Downloads/*.apk',
'C:/Users/*/Desktop/*.apk',
'C:/Windows/Temp/*.apk',
'/home/*/Downloads/*.apk',
'/tmp/*.apk'
])
WHERE Mtime > (now() - 2592000)
ORDER BY Mtime DESC
Remediation / Triage Script
For rapid triage of Android devices connected to managed workstations (or in a lab/IR setting via ADB), this Bash script enumerates sideloaded packages, flags high-risk permission combinations, and checks for apps holding Accessibility access — the three fastest signals of a Manic-class infection:
#!/bin/bash
# Manic-class Android malware triage via ADB
# Usage: connect device with USB debugging, then run ./android_triage.sh
set -euo pipefail
DEVICE=$(adb devices | awk 'NR==2 {print $1}')
if [ -z "$DEVICE" ]; then echo "[!] No ADB device connected."; exit 1; fi
echo "=== [1] Non-store-installed packages (sideloaded / ADB-pushed) ==="
for pkg in $(adb shell pm list packages -3 | sed 's/package://' | tr -d '\r'); do
installer=$(adb shell pm get-installer-package-name "$pkg" 2>/dev/null | tr -d '\r')
if [[ "$installer" != *"com.android.vending"* && "$installer" != *"com.amazon.venezia"* ]]; then
echo "[SIDeloaded] $pkg (installer: ${installer:-unknown})"
fi
done
echo ""
echo "=== [2] Apps holding high-risk permission combinations ==="
for pkg in $(adb shell pm list packages -3 | sed 's/package://' | tr -d '\r'); do
perms=$(adb shell dumpsys package "$pkg" 2>/dev/null | grep 'android.permission' | grep 'granted=true' || true)
has_a11y=$(adb shell settings get secure enabled_accessibility_services | tr -d '\r' | grep -c "$pkg" || true)
has_sms=$(echo "$perms" | grep -c 'READ_SMS\|RECEIVE_SMS' || true)
has_radio=$(echo "$perms" | grep -c 'BLUETOOTH_ADVERTISE\|NEARBY_WIFI_DEVICES\|BLUETOOTH_CONNECT' || true)
if [ "$has_a11y" -gt 0 ] && [ "$has_sms" -gt 0 ]; then
echo "[CRITICAL] $pkg — Accessibility + SMS"
fi
if [ "$has_sms" -gt 0 ] && [ "$has_radio" -gt 0 ]; then
echo "[HIGH] $pkg — SMS + nearby-radio permissions"
fi
done
echo ""
echo "=== [3] Enabled Accessibility Services (manual review required) ==="
adb shell settings get secure enabled_accessibility_services
echo ""
echo "=== [4] Unknown-sources install setting (should be restricted) ==="
adb shell settings get secure install_non_market_apps
echo ""
echo "[*] Triage complete. Quarantine flagged packages: adb shell pm uninstall --user 0 <package>"
Remediation
Immediate Actions (Infected or Suspected Devices)
- Physically and logically isolate. Do not just "block at the firewall." Because Manic can relay through nearby infected peers, put the device in airplane mode and disable Bluetooth/Wi-Fi radios — or power it off entirely — before forensic acquisition. A Faraday bag is appropriate for executive devices pending forensics.
- Assume peer exposure. If one device is confirmed infected, treat other devices that were in physical proximity (same office floor, same travel itinerary, same meeting rooms) as in-scope for triage. Run the ADB triage script above across the fleet.
- Revoke credentials harvested from the device. Any credentials, session tokens, MFA seeds, or corporate accounts used on the device must be rotated. Assume SMS-based 2FA codes were intercepted.
- Wipe and re-enroll. For confirmed infections, factory reset followed by MDM re-enrollment is the only reliable remediation — do not attempt surgical removal of Android stealers that abused Accessibility services, as they commonly establish self-protection hooks.
Hardening (Fleet-Wide)
- Block sideloading at the MDM layer. Enforce "install from unknown sources: disallowed" on all managed Android devices. On Android Enterprise fully managed devices, this is a one-line policy; for BYOD work profiles, restrict the work profile at minimum.
- Audit Accessibility services. Maintain a strict allowlist of apps permitted to hold Accessibility access. Alert on any addition. This single control neutralizes the majority of Android stealer capability.
- Restrict high-risk permissions. Via MDM app permission policies, deny SMS, contacts, and notification-listener access for any app not on the allowlist.
- Enroll devices in MTD. Microsoft Defender for Endpoint on Android, Lookout, Zimperium, or equivalent — and critically, forward that telemetry to your SIEM. Mobile alerts that live only in the MTD console are alerts nobody sees.
- Segment mobile/BYOD VLANs. Place BYOD devices on isolated segments with egress filtering and no lateral path to production. The KQL beaconing hunt above depends on this traffic being logged.
- Reconsider radio policy for high-risk roles. For executives and staff traveling to targeted regions, evaluate MDM policies that restrict Bluetooth advertising/discovery and Wi-Fi Direct for non-system apps — this directly constrains the fallback relay channel without materially impacting most users.
Strategic Takeaway
Manic is a signal of where mobile malware is heading: resilience against network-layer containment. If your incident response playbooks for mobile devices assume that "block the C2 at the proxy" equals containment, update them. Containment for modern Android malware means radio isolation, peer-proximity scoping, and fleet-wide permission hygiene — not just egress filtering.
If you need assistance scoping a suspected mobile compromise — including peer-exposure analysis and fleet triage — Security Arsenal's incident response team handles mobile intrusions as part of our standard IR retainer.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.