The charging port on a phone is also a data port, and a compromised computer, kiosk or charging station can use it to read data, install apps outside the store or attack the device directly. MITRE ATT&CK for Mobile T1458 Replication Through Removable Media sits in two tactics, TA0027 Initial Access and TA0033 Lateral Movement, and ATT&CK v20 maps it to Android and iOS. Despite the name, the mobile technique is about USB connections rather than memory cards. This guide covers how the technique works on each platform, the documented malware, the MDM settings that close the port, and how to detect misuse. It is for mobile and endpoint engineers and for anyone setting USB policy for a managed fleet. The matrix overview is in the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Two directions, one port. As Lateral Movement, a compromised host pushes apps onto a connected phone; as Initial Access, a malicious connection attacks the phone to get at its data.
- Trust prompts are the control point. The iOS host trust decision and the Android USB debugging authorisation are what stand between a cable and data access, so users should refuse them on unknown hosts.
- Both platforms can disable USB data by policy. iOS restricts accessories until the device is unlocked and supervised devices can block pairing with unapproved hosts; Android Enterprise can block USB file transfer or all USB data on company-owned devices.
- Locked bootloaders matter. ATT&CK lists M1003 Lock Bootloader because several published USB attacks relied on bootloader or debug weaknesses.
- The infected host is part of the incident. WireLurker and DualToy spread from compromised computers, so a phone finding means checking the computers it was plugged into.
How T1458 works on mobile
ATT&CK describes two uses. For Lateral Movement, an adversary uses a phone's physical connection to a compromised or malicious charging station or computer to bypass application store requirements and install malicious apps directly. For Initial Access, the adversary exploits the device over the connection to reach data stored on it. The examples ATT&CK gives are all physical-connection attacks:
- Bootloader weakness over USB: insecure bootloaders on Nexus 6 and 6P devices allowed actions including intercepting calls and network traffic and obtaining location (IBM research).
- Weak security boundaries over USB: Google Project Zero showed weakly enforced boundaries on devices such as the Google Pixel 2.
- Passcode unlock via the data port: ATT&CK notes that products from forensic vendors purportedly could exploit some iOS devices through physical access to the port to unlock the passcode.
The public "juice jacking" concern, a malicious public charger that harvests data, falls under the Initial Access use. See the Juice Jacking Guide for the consumer-facing side; this page stays on enterprise controls.
Documented malware
| Software | Platforms affected | Behaviour recorded by ATT&CK | Defensive lesson |
|---|---|---|---|
| WireLurker (S0312) | iOS, via an infected macOS computer | Monitors for iOS devices connected over USB to an infected OS X computer and installs downloaded or generated apps on them (Palo Alto Networks) | A trusted host can be the attacker; limit which computers phones may pair with |
| DualToy (S0315) | Android and iOS | Side-loads malicious or risky apps to both platforms over a USB connection (Palo Alto Networks) | Disable USB debugging and unknown-source installs; check the host |
Platform controls: iOS and Android
Both platforms gate USB data behind the lock screen and a trust decision, and both give administrators a stronger policy option on managed devices.
| Control | iOS and iPadOS | Android |
|---|---|---|
| Default data protection on the port | The device must be unlocked before it connects to USB or Thunderbolt accessories or a Mac or PC; storage accessories always need an unlock; power adapters still charge a locked device | A new computer must be authorised before ADB debugging works, and developer settings must be on first |
| User setting | Settings > Privacy & Security > Security > Wired Accessories (USB-C models: Always Ask, Ask for New Accessories, Automatically Allow When Unlocked, Always Allow) | USB mode chosen per connection; developer options and USB debugging off unless enabled |
| Admin policy for the port | USB Restricted Mode restriction (supervised devices) | Android Management API deviceConnectivityManagement.usbDataAccess: DISALLOW_USB_FILE_TRANSFER or DISALLOW_USB_DATA_TRANSFER (company-owned devices; full block needs Android 12 and USB HAL 1.3, otherwise falls back to blocking file transfer) |
| Admin policy for hosts or debugging | "Allow pairing with non-Apple Configurator hosts" turned off: only computers holding a valid supervision host certificate can reach the device | advancedSecurityOverrides.developerSettings set to DEVELOPER_SETTINGS_DISABLED (the default) |
| Recovery and boot | Since iOS and iPadOS 14.5, unpaired hosts cannot put a device into recovery and restore it without physical interaction | Locked bootloader: only an OS signed by the root of trust boots; every lock or unlock transition wipes the data partitions |
| Sideloaded app installs | With host pairing turned off, only computers with a valid supervision host certificate can reach the device over USB | untrustedAppsPolicy set to DISALLOW_INSTALL; googlePlayProtectVerifyApps set to VERIFY_APPS_ENFORCED |
| Removable storage | Storage accessories require an unlock | mountPhysicalMediaDisabled blocks the user mounting external media |
ATT&CK's M1006 Use Recent OS Version entry notes that iOS 11.4.1 introduced USB Restricted Mode, which disables data access through the port under certain conditions. Apple's current documentation describes the behaviour through the Wired Accessories setting above. On the Android side, ADB is the main route for USB installs; the Android Platform Tools and ADB guide covers developer-device handling.
Rolling out USB controls
- Inventory first. From MDM, list Android devices with developer settings allowed, any device-wide unknown-source permission, and iOS devices that are not supervised (and so cannot take the host pairing restriction).
- Define who needs USB data. App developers, testers and some field staff using wired tools genuinely do. Put them in a separate policy group rather than weakening the default.
- Pilot the restrictive policy. Apply
DISALLOW_USB_FILE_TRANSFERand disabled developer settings on Android, and the host pairing restriction on supervised iOS, to one pilot ring. Check that charging, wired headsets, car integration and any line-of-business accessories still work. - Roll out by ring, then raise Android to
DISALLOW_USB_DATA_TRANSFERwhere devices support it and wired peripherals are not needed. - Issue chargers. ATT&CK's M1011 User Guidance advises against public charging stations and computers and recommends chargers from a trusted source.
- Rollback: keep the exception group ready so a broken workflow can be moved there within minutes; document every exception with an owner and expiry.
Detection and measurement
ATT&CK v20's DET0691 Detection of Replication Through Removable Media correlates, on Android, app permission and managed package state with file creation of APK, DEX, shared library or shell files in app storage or /data/local/tmp/ from a USB-mounted path or external storage. On iOS it relies on Apple MDM device information, security information, profile lists and restriction compliance, treated as periodic state rather than real-time events. Useful signals:
- Policy drift: a device reporting developer settings or USB debugging enabled outside the developer group.
- Unexpected packages: apps present that were not deployed through the managed store, especially just after a device was connected to a computer.
- Profile and certificate changes: new configuration profiles or trust certificates on iOS that MDM did not push.
- Host-side evidence: EDR on corporate computers flagging tools that talk to phones over USB.
Metrics
- Percentage of company-owned Android devices with USB file transfer or all USB data blocked.
- Count of devices with developer settings allowed outside the approved group.
- Percentage of corporate iOS devices that are supervised and carry the host pairing restriction.
- Number of USB exceptions past their expiry date.
Where identity fits
A trusted host pairing is a long-lived credential in its own right: the host keeps a pairing record that lets it reconnect without asking again. Treat supervision host certificates and the computers holding them as privileged assets, restrict who can use Apple Configurator, and remove pairing trust when staff change roles. Data pulled over USB can include cached app tokens, so keep tokens in the Keychain or Android Keystore and short-lived; see Mobile Access Credentials.
Common failure patterns
- Developer options left on after testing: a device used once for debugging stays exposed to any computer the user later trusts.
- Unsupervised iOS devices: the host pairing and USB Restricted Mode restrictions need supervision, so corporate devices enrolled without it cannot take them.
- Ignoring the computer side: WireLurker shows the infection lives on the host; cleaning the phone alone leaves the source.
- Unlocked bootloaders on test hardware that drifts into production use: a device with an unlocked bootloader boots unsigned software after a warning.
- Training users to tap Trust: help desk scripts that tell users to accept any trust prompt undo the main control.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile | M1003 Lock Bootloader; M1006 Use Recent OS Version; M1011 User Guidance; M1012 Enterprise Policy; M1001 Security Updates | The listed mitigations |
| ATT&CK Enterprise | T1091 Replication Through Removable Media | Desktop counterpart |
| NIST SP 800-53 Rev 5 | AC-19 Access Control for Mobile Devices; MP-7 Media Use; CM-7 Least Functionality; SI-2 Flaw Remediation | Device policy, port and media control |
| NIST CSF 2.0 | PR.PS-01; PR.PS-05; DE.CM-09 | Configuration management, blocking unauthorised software, device monitoring |
| ISO/IEC 27001:2022 Annex A | A.8.1 User end point devices; A.7.10 Storage media | Endpoint and media handling |
Practitioner checklist
- Supervise all corporate iOS devices and turn off pairing with non-Apple Configurator hosts where users do not need it.
- Block USB file transfer on company-owned Android devices, and all USB data where supported.
- Keep Android developer settings disabled outside a named developer group.
- Keep bootloaders locked on production devices and alert on unlocked state.
- Block unknown-source installs and enforce Play Protect verification.
- Issue trusted chargers and tell users not to trust unknown computers or kiosks.
- On any USB-borne finding, investigate every host the device was paired with.
Standards and references
- MITRE ATT&CK: T1458 Replication Through Removable Media (Mobile)
- Apple: Allow USB and other accessories to connect to your iPhone or iPad
- Apple Platform Deployment: Manage USB pairing
- Google: Android Management API policies reference
- Android Open Source Project: Verified Boot device state
- Android Open Source Project: Verified Boot
- MITRE ATT&CK: S0312 WireLurker
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Removable Media and USB Control Guide · iOS and iPadOS Enterprise Security Guide · Android Enterprise Security Guide · Mobile T1461 Lockscreen Bypass · Mobile T1664 Exploitation for Initial Access