Android banking malware has learned to run the real banking app inside its own virtual container, so the app looks genuine to the user while the malware reads everything typed into it. MITRE ATT&CK for Mobile T1670 Virtualization Solution (tactic TA0030 Defense Evasion) covers adversaries who use virtualization to escape the Android app sandbox and avoid detection. ATT&CK lists Android as the only platform for this technique, and both of its procedure examples are Android banking malware. This guide explains how the technique works, what GodFather and FjordPhantom show, and how MDM, mobile threat defense (MTD), app-side integrity checks and forensics expose it. It is written for mobile security teams and for the owners of banking, payment and other high-value apps.
Key takeaways
- Android only in ATT&CK. T1670 lists Android as its sole platform and has no iOS procedure examples; this page does not invent an iOS equivalent.
- The genuine app runs, unmodified. Promon reports that FjordPhantom launches the target banking app inside a virtual container without changing it, which defeats repackaging checks, and that the approach needs no root.
- Hooks hide the evidence. Zimperium and Promon both report hooks inside the container that make the list of enabled accessibility services come back empty, defeating a common app-side check.
- Delivery is the weak link. Both cases rely on getting a malicious host app installed, by sideloading after a lure or a phone call; ATT&CK's mitigation M1011 is to install apps only from authorised stores.
- Verify on the server. Integrity verdicts evaluated server side, such as Play Integrity, give the app owner a signal the malware cannot simply hook away inside the container.
How the technique works
Android isolates apps with a per-app Linux user ID enforced by the kernel, with SELinux, seccomp filtering and, for apps targeting API level 28 and later on Android 9, per-app SELinux sandboxes adding layers (Android Open Source Project, Application Sandbox). Escaping that sandbox on a properly configured device generally requires a kernel compromise.
App-level virtualization side-steps this. A host app carries a virtualization framework and runs other apps inside its own process space, so the "guest" app shares the host's sandbox. Promon describes this as breaking the Android sandbox, because apps hosted in the same container share a sandbox with each other. The host can then hook the guest app's code, read its memory and network traffic and change what the guest sees about the device.
ATT&CK also names the Android Virtualization Framework (AVF) as an example of a virtualization solution on Android. AOSP describes AVF as providing protected virtual machines on the pKVM hypervisor, supported only on ARM64 devices, intended for security use cases that need stronger isolation than the app sandbox. The two procedure examples in ATT&CK v20 use app-level virtualization frameworks rather than AVF.
Procedure examples
| Malware (ATT&CK ID) | Source and date | What the source reports |
|---|---|---|
| FjordPhantom (S1208) | Promon, 30 November 2023 | Embeds a virtualization solution and a hooking framework built from open-source or free projects, plus the APK of a targeted banking app, and launches that app in a virtual container. Hooks report accessibility services as off, make Google Play Services appear unavailable and close some security warning dialogs. Spread mainly by email, SMS and messaging apps, with call-centre social engineering. Mainly Indonesia, Thailand and Vietnam. |
| GodFather (S1231) | Zimperium zLabs, 18 June 2025 | Uses the open-source VirtualApp framework and Xposed hooking. When the victim opens the real banking app, the malware intercepts the launch and starts a virtual copy inside the host, then hooks methods to capture credentials and network traffic. Hooks the API that lists active accessibility services so it returns an empty list. Virtualization attack focused on about a dozen Turkish financial institutions, within a wider target list of about 500 apps. |
Related Mobile defence evasion pages: T1655 Masquerading and T1406 Obfuscated Files or Information. Both cases sit inside the wider banking trojan pattern covered in the Android Banking Trojans Guide.
What iOS teams should take from this
ATT&CK does not list iOS for T1670, and none of the sources above describe an iOS variant. The transferable lessons are generic: keep app installation to the App Store or your managed distribution, and validate app integrity on the server rather than trusting checks that run on the device. For Apple's app integrity service and how to use attestation server side, see Mobile App Attestation.
Detection: device, app and server views
ATT&CK v20's Android analytic for T1670 correlates application permission state (DevicePolicyManager.getPermissionGrantState() and manifest permission review), managed package inventory and metadata from Android Enterprise or an EMM, and network flows from Android Enterprise network logging or an enterprise VPN, alerting on changes inconsistent with the baseline or approved policy.
| View | Signal | Why it helps against T1670 |
|---|---|---|
| MDM inventory | Apps installed from outside the managed store; packages not on the approved list | The host app has to be installed; on managed devices that is visible and blockable |
| Permission review | Install-from-unknown-sources, accessibility and overlay permissions on new apps | Delivery and follow-on abuse depend on these grants |
| MTD app analysis | Embedded APKs, known virtualization or hooking frameworks in an app package | Both cases embed open-source virtualization and hooking components |
| Server-side integrity verdict | Play Integrity appRecognitionVerdict other than PLAY_RECOGNIZED; device verdict below policy; appAccessRiskVerdict showing unknown capturing, controlling or overlay apps; playProtectVerdict of MEDIUM_RISK or HIGH_RISK | Evaluated by Google and checked by your server, not by code the host can hook |
| Fraud analytics | New payees and payments shortly after a fresh install or a support call | FjordPhantom used call-centre guidance to steer transactions |
| Forensics | Package list, install sources and app data from a device examination | Confirms the host app and the guest copies; see the Mobile Forensics Guide |
Treat any single client-side check as advisory. The point of T1670 is that the attacker controls the environment the guest app runs in, so a local "am I virtualized?" check can be answered by the attacker. OWASP MASVS-RESILIENCE frames such controls as defence in depth that aims to ensure the app runs on a trusted platform, and states that they must not replace sound architecture and server-side validation.
Metrics:
- Share of sensitive app sessions (login, payee creation, payment) with a server-verified integrity verdict.
- Rate of sessions with an unrecognised app verdict or unknown controlling apps, and the fraud rate within them.
- Count of managed devices with apps installed from unknown sources.
- Percentage of Android devices where Play Protect is on.
- Median time from an MTD finding of a hooking or virtualization framework to app removal.
Prevention
- Authorised stores only (M1011): on fully managed devices and work profiles, block installs from unknown sources; for customers, say plainly in app and on the website that the bank never sends app files by SMS, email or chat.
- Keep Google Play Protect on: it scans apps at install and periodically scans the device, including apps from outside Google Play, and can disable a harmful app. FjordPhantom's hooks targeted Google Play Services, which is a reason to verify Play Protect status from the server rather than the device.
- Use restricted settings as intended: Android 13 and later can block sensitive settings such as accessibility for an app until the user explicitly allows restricted settings.
- Gate high-risk actions on server-side verdicts: require a recognised app and an acceptable device verdict before payment or payee changes, with step-up or a cooling-off period otherwise.
- Layer app shielding: runtime protection can raise the cost of hooking but should feed signals to the server rather than decide alone; see the Mobile App Shielding and RASP Buyers Guide.
Implementation steps
- Threat model the app: list the actions an attacker inside the container would want (credential capture, payee change, one-time code reading) and the server calls behind them.
- Add integrity requests in observe mode: request a verdict on those calls and log it without enforcing, for at least one release cycle.
- Set thresholds: decide which verdict combinations trigger step-up, delay or block, and agree them with fraud and customer support.
- Enforce for a percentage of users: roll out behind a server-side flag, watching support contacts and false positives on older or uncertified devices.
- Close the delivery path on managed fleets: enforce unknown-source blocking and app allow lists in MDM.
- Rollback: keep enforcement switchable per verdict and per app version so a bad threshold can be relaxed without an app release.
Common failure patterns
- Trusting local checks: both reported cases hook the accessibility service list; an app that only checks locally sees a clean device.
- Relying on repackaging detection: the guest app is the genuine, signed app, so signature checks on the app itself pass.
- Ignoring the call-centre angle: FjordPhantom victims were guided by fake support staff; fraud teams need the integrity signal at the moment of the call-driven transaction.
- Blocking every uncertified device outright: without a staged rollout, legitimate customers on older devices are locked out and pressure builds to remove the control.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile | T1670, tactic TA0030; mitigation M1011 User Guidance | The technique and its listed mitigation |
| NIST SP 800-53 Rev 5 | CM-11, SI-3, SI-7, AC-19 | User-installed software, malicious code protection, integrity verification, mobile access control |
| NIST CSF 2.0 | PR.PS-05, DE.CM-09 | Preventing unauthorised software, monitoring runtime environments |
| OWASP MASVS | MASVS-RESILIENCE | Runtime environment and tamper checks as defence in depth |
Practitioner checklist
- Unknown-source installs are blocked on fully managed devices and work profiles.
- Play Protect status is part of Android compliance and of server-side app risk decisions.
- Sensitive app actions request an integrity verdict that is checked on the server.
- Unrecognised app verdicts and unknown controlling or overlay apps trigger step-up or delay for payments.
- MTD app analysis flags embedded APKs and known virtualization or hooking frameworks.
- Customer messaging states that the organisation never sends app files outside the official store.
- Fraud and support teams can see integrity signals during a live support call.
- Enforcement thresholds can be changed server side without an app release.
Standards and references
- MITRE ATT&CK: Mobile T1670 Virtualization Solution
- Android Open Source Project: Application Sandbox
- Android Open Source Project: Android Virtualization Framework
- Android Developers: Play Integrity API integrity verdicts
- OWASP: Mobile Application Security Verification Standard
- Google: Use Google Play Protect to help keep your apps safe
- Promon: FjordPhantom Android malware
- Zimperium zLabs: Your mobile app, their playground, the dark side of the virtualization
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile Banking App Security Guide, Android App Security Guide, Mobile Threat Defense Buyer's Guide.