Mobile T1663 Remote Access Software: Detecting Command and Control Channels on Mobile Devices

When an attacker can watch and drive a phone screen through remote access software, every app on it, including the authenticator and the banking app, becomes the attacker's interface. MITRE ATT&CK for Mobile T1663 Remote Access Software (tactic TA0037 Command and Control, platforms Android and iOS) covers adversaries who use legitimate remote access tools, or remote access modules built into malware, to run an interactive session on a target device. This guide explains how the technique works on each platform, what the ATT&CK v20 procedure examples show, which telemetry from mobile device management (MDM) and mobile threat defense (MTD) can surface it, and how to block it without breaking legitimate support. It is written for mobile security engineers, endpoint and SOC teams and app security owners in banks and other high-fraud sectors. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• The tool can be legitimate. ATT&CK names VNC, TeamViewer, AirDroid and AirMirror as examples: products built for support and device access, which makes signature-only blocking a poor fit.
• Banking trojans bundle their own remote access. ATT&CK records BRATA (S1094) viewing a device through VNC and Escobar (S1092) using VNC to control an infected device, both on Android.
• Permissions are the choke point on Android. Remote control on Android usually rests on the Accessibility Service and device administrator grants, which Android 13 and later gate behind restricted settings for some app installs.
• Managed devices give you an app inventory. ATT&CK mitigation M1012 Enterprise Policy notes that an MDM in fully managed (Android) or device owner (iOS) mode, in ATT&CK's wording, can list installed apps and block specific remote access tools.
• App backends can ask the device. The Play Integrity API reports whether apps that could capture the screen or control the device are active while your app runs, which lets a bank refuse a high-risk transaction during a live remote session.

How the technique works

ATT&CK describes three patterns. First, a remote access app is installed after compromise as a redundant channel. Second, an interactive session is opened so a human operator can act on the device in real time. Third, a remote access component is built into the malware itself and connects outward to an adversary-controlled service. ATT&CK adds that installing a remote access tool may also give persistence.

The value for the attacker is that actions happen on the victim's own device, with the victim's own sessions, device binding and location. Fraud checks that trust "known device" signals see nothing unusual. That is why the published cases are dominated by banking fraud: the operator watches the victim log in, then moves money from the trusted device.

• Legitimate remote access apps: installed from an app store, often at the request of a caller posing as bank or IT support. The app works exactly as designed; the abuse is in who is on the other end.
• Embedded remote access modules: part of the malware. Cleafy's January 2022 analysis of BRATA describes a VNC module and a get_screen command that sends screenshots to the command and control server, with the Accessibility Service obtained during installation used to watch the victim.
• Remote control plus credential theft: BleepingComputer's March 2022 report on Escobar describes a VNC Viewer that lets the operator control the device when it is unattended, alongside theft of Google Authenticator codes, SMS and notifications, and a target list of 190 banks and financial institutions in 18 countries.

Android and iOS: what differs

ATT&CK lists both platforms for T1663. All procedure examples in ATT&CK v20 are Android malware; ATT&CK lists no iOS procedure example for this technique. The defensive controls below are given for both platforms, because legitimate remote access and screen sharing apps exist on both stores and the MDM control in M1012 applies to both.

See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide for the management modes these controls depend on.

Detection

ATT&CK v20 ships a detection strategy for T1663 with one analytic per platform. Both tell the analyst to correlate device, network and management evidence, and to alert on a state change that is inconsistent with the device or app baseline, approved policy or expected workflow. Both also warn against inferring API calls or payload content from management state alone. In practice that means three signal families.

Google's Play Integrity documentation defines the KNOWN_ prefix as apps installed by Google Play or preloaded on the system partition, and UNKNOWN_ as any other apps. Verified accessibility services known to Google Play are excluded from the capturing, controlling and overlay values, which keeps genuine assistive tools from triggering the check. A bank can therefore step up or block a payment while an unknown app can control the device, rather than relying on the customer noticing.

Metrics that show it is working:

• Percentage of managed devices reporting a complete app inventory in the last 24 hours.
• Count of devices with an unapproved remote access app, and median time from detection to removal.
• Count of non-accessibility apps holding the Accessibility Service on managed Android devices.
• For customer apps: share of high-value transactions evaluated with an app access risk verdict, and the fraud rate on sessions flagged UNKNOWN_CONTROLLING.
• Percentage of Android devices where Play Protect is on (no POSSIBLE_RISK verdicts).

Prevention and hardening

• Enforce an app policy on managed devices (M1012): block known remote access and screen mirroring apps by package or bundle identifier, and allow only the support tool your service desk uses. On Android work profiles, allow only managed Google Play apps in the work profile.
• Keep Google Play Protect on: Google's help page states Play Protect checks apps at install, periodically scans the device including apps from outside Google Play, and can disable a harmful app until it is uninstalled. It is on by default; report and alert when it is turned off.
• Treat restricted settings as a control, not a nuisance: on Android 13 and later, Android can block sensitive settings such as accessibility for an app until the user explicitly allows restricted settings in App info. User guidance (M1011) should say plainly that no bank or IT team will ask them to do this.
• Restrict unknown sources: on fully managed and work profile devices, disallow installs from unknown sources so the dropper stage BRATA used is closed off.
• Build the check into sensitive apps: request a Play Integrity verdict before login, payee creation and payment, and act on the capturing and controlling values server side. On iOS, use App Attest through your app's attestation flow; see Mobile App Attestation.
• Run your own remote support safely: if the service desk uses remote control on phones, require a user-visible consent prompt per session, log every session centrally and keep the tool to an approved list. The RMM Tool Security Guide covers governance of the approved tool.

Where identity fits

A remote session inherits every identity on the device. Escobar is the clearest example: BleepingComputer reports it collected Google Authenticator codes and uploaded them to its server, which defeats time-based one-time passwords generated on the same phone. Passkeys bound to the device and to the relying party's origin resist remote phishing, but an operator who controls the unlocked screen can still approve actions inside an already authenticated app, so transaction signing and Play Integrity checks matter as much as login strength. See the Phishing-Resistant MFA Guide.

The non-human side is the management plane itself. MDM administrator accounts, API tokens used by MTD-to-MDM integrations and the credentials of any remote support platform can push or remove apps across the fleet. Store them in a secrets manager, scope them to the minimum role and review their use, as covered in the Mobile Device Management Security Guide.

Responding to a suspected remote session

1. Cut the session: for customers, freeze outbound payments and sessions on the account first; for staff, move the device to a quarantine compliance state in MDM, which removes corporate data access.
2. Preserve evidence before wiping: record the app inventory, permission grants, network log batch and MTD findings. BRATA's factory reset kill switch (described by Cleafy) shows why evidence may vanish if you wait.
3. Remove the tool and reset credentials: uninstall the remote access app, revoke the Accessibility Service and device administrator grants, then rotate passwords and re-enrol any authenticator that was on the device.
4. Hunt across the fleet: search inventory and DNS logs for the same package names and relay domains.
5. Fix the entry point: most cases start with a lure or a call; see the Android Banking Trojans Guide and the Mobile Malware Guide for the delivery side.

Rolling out controls

1. Inventory first: turn on managed app inventory reporting for every enrolled device and baseline which remote access apps are present today.
2. Audit, then block: run the deny list in report-only mode for two weeks, contact owners of legitimate uses, then switch to block for a pilot group before the whole fleet.
3. Add network signals: enable Android Enterprise network logging or route managed traffic through a per-app VPN or secure web gateway, and add the relay domains of common remote access services to a watch list.
4. Customer apps: add Play Integrity requests to the login and payment flows in observe mode, measure the rate of capturing and controlling verdicts, then enforce step-up or blocking.
5. Rollback: keep the deny list as a single MDM policy so it can be paused for a business unit within minutes, and keep integrity enforcement behind a server-side flag.

Common failure patterns

• Blocking by name only: malware with a built-in VNC module, as with BRATA and Escobar, never appears as a "remote access app" in inventory. Permission state and network data are needed as well.
• Unmanaged personal devices out of scope: the inventory control only applies to enrolled devices, so staff who approve payments from personal phones are invisible.
• Trusting the device instead of the session: fraud rules that treat a known device as low risk are exactly what an on-device operator exploits.
• Telling users to allow restricted settings: support scripts that walk users through enabling accessibility for a non-assistive app train them to follow the attacker's script.
• No owner for the approved tool: an unmanaged legitimate remote support product, with shared accounts and no session logging, is indistinguishable from abuse.

Framework mapping

Related mobile techniques that often appear alongside T1663 are Mobile T1453 Abuse Accessibility Features and Mobile T1660 Phishing.

Practitioner checklist

• Managed app inventory is reported daily from every enrolled Android and iOS device.
• A remote access and screen mirroring deny list is enforced in MDM, with one approved support tool.
• Installs from unknown sources are disallowed on fully managed devices and work profiles.
• Non-accessibility apps holding the Accessibility Service or device administrator raise an alert.
• Play Protect status is part of Android compliance, and a disabled state is alerted.
• Android network logging, per-app VPN or a secure web gateway gives DNS and connection data for managed devices.
• Customer apps evaluate Play Integrity app access risk before login and payment, and enforce server side.
• User guidance states that no legitimate caller will ask users to install remote access apps or allow restricted settings.
• The response runbook preserves evidence before any wipe and resets authenticators that were on the device.

Standards and references

• MITRE ATT&CK: Mobile T1663 Remote Access Software
• Android Developers: Play Integrity API integrity verdicts
• Google: Use Google Play Protect to help keep your apps safe
• Google: Allow restricted settings
• Google Play: Use of the AccessibilityService API
• Cleafy Labs: How BRATA is monitoring your bank account
• BleepingComputer: Android malware Escobar steals your Google Authenticator MFA codes

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile Threat Defense Buyer's Guide, Mobile App Permissions, Mobile Banking App Security Guide.