A phone's camera can record a meeting room, a whiteboard or a screen as easily as a selfie, and mobile spyware is built to use it quietly. MITRE ATT&CK for Mobile tracks this as T1512 Video Capture, a Collection technique for Android and iOS in which malware takes video or still images through the operating system's camera API, sometimes at set intervals, and stores them for later exfiltration. ATT&CK v20 records more than forty malware families and groups using it, from commodity Android trojans to commercial and state spyware. This guide covers the permission model on each platform, the operating system protections that make covert capture harder, the management settings that restrict cameras, how to detect capture that no user started, and how to respond. It is for mobile security engineers, MDM administrators and security teams protecting sensitive sites or high-risk staff. The MITRE ATT&CK for Mobile Guide gives the wider matrix.
Key takeaways
- Camera use needs a user-granted permission on both platforms. ATT&CK notes Android apps need android.permission.CAMERA and iOS apps need the NSCameraUsageDescription key, and the user must approve; root or jailbreak removes that barrier.
- Modern OS versions are the main mitigation. ATT&CK maps M1006 Use Recent OS Version: Android 9 blocks camera access by background apps, and iOS 14 and Android 12 show a status bar indicator during camera use.
- Management can switch cameras off. Android's cameraAccess policy and Apple's allowCamera restriction disable cameras where policy requires it, such as secure areas.
- The detection signal is capture without a user. ATT&CK's analytics look for sustained camera sessions while the app is in the background, the device is locked, or there has been no recent interaction.
- Video capture comes with other collection. The same spyware usually also records audio and screens, so handle a hit as full device compromise.
How T1512 works
ATT&CK v20 describes T1512 as using a device's cameras to record video or capture images, possibly at intervals, through an API the operating system provides, with files written to storage for later exfiltration. It differs from T1513 Screen Capture, which records the display, and sits beside T1429 Audio Capture. On laptops and desktops the equivalent Enterprise technique is T1125 Video Capture.
Procedure examples in ATT&CK v20 show the range of behaviour:
| Behaviour | Examples ATT&CK v20 records |
|---|---|
| Photos and video from front and rear cameras | Stealth Mango, Pallas, ViceLeaker, RCSAndroid, SpyDealer, Monokle, Dendroid |
| Capture triggered by context | Skygofree records when the device is in a specified location; LightSpy takes one, continuous or event-related pictures (HEIC on iOS) |
| Live image streaming | Crocodilus starts and stops image streaming from the front camera |
| Permission abuse | AbstractEmu can grant itself camera permission; Fakecalls and Concipit1248 request it; VajraSpy requests android.permission.CAMERA |
| Spyware and targeted operations | Pegasus for Android takes pictures; the Windshift group included video recording in apps used in Operation BULL |
Almost all recorded families are Android; ATT&CK v20 also records iOS procedures for Concipit1248, Phenakite and LightSpy. ATT&CK lists both platforms because the API and permission path exist on both.
Platform protections
Android and iOS are listed alphabetically. These are the protections an attacker has to get around, and the reason to keep devices current.
| Protection | Android | iOS and iPadOS |
|---|---|---|
| Runtime permission | android.permission.CAMERA, granted by the user | NSCameraUsageDescription in Info.plist, with user approval at first request |
| Background restriction | From Android 9, an app in the background cannot access the camera or microphone; apps that need sensors must run a foreground service | Recording indicator makes background capture visible to the user (see next row) |
| Visible indicator | From Android 12, a status bar icon appears when an app accesses the camera or microphone | From iOS 14, a green indicator means the camera, or camera and microphone, is in use; orange means microphone only |
| User kill switch | From Android 12, supported devices offer a single camera toggle for all apps in Quick Settings and the Privacy screen | Per-app camera access in privacy settings |
The Android 9 rule pushes malware towards foreground services, which is why ATT&CK's Android analytic looks for a foreground service running without visible user action. Indicators help only if users notice them; brief staff who handle sensitive material on what the green indicator or status bar icon means. See the Mobile App Permissions guide for permission review practice.
Restricting cameras with device management
| Platform | Setting | Values and effect | Scope notes from the vendor documentation |
|---|---|---|---|
| Android | cameraAccess (Android Management API) | CAMERA_ACCESS_USER_CHOICE is the default (all cameras available); CAMERA_ACCESS_DISABLED disables all cameras; CAMERA_ACCESS_ENFORCED stops the user using the camera toggle | DISABLED is device-wide on fully managed devices and applies to the work profile otherwise; ENFORCED applies on fully managed devices running Android 12 and above; the older cameraDisabled field is deprecated |
| iOS and iPadOS | allowCamera (Restrictions payload) | Default true; false disables the camera, removes its icon and stops users taking photographs | Apple's schema states support on unsupervised devices is deprecated, so plan on supervision |
Decision guidance:
- Secure areas and classified spaces: disable cameras on corporate devices through policy, or keep phones out of the space altogether; policy cannot stop a personal phone.
- Frontline and kiosk devices: disable cameras unless the job needs them (for example scanning), and use the app allowlist to limit which apps can hold camera permission.
- Knowledge workers: leave cameras on, keep OS versions current, and watch for unexpected camera grants on non-catalogue apps.
- High-risk individuals: add Apple Lockdown Mode or Android Advanced Protection, and see the Mobile Communications Protection for High-Risk Individuals Guide.
Detection
ATT&CK v20's detection strategy for T1512 is more specific than most mobile entries. On Android it correlates camera access by an app with sustained capture, writes to media, cache or staging paths, buffer growth and optional outbound transfer, and treats it as stronger when the app is in the background, running a foreground service without visible user action, active while the device is locked, or capturing without recent user interaction. It strengthens further if the app is unmanaged, was recently granted camera access, or is not approved to record. On iOS, where ATT&CK notes direct runtime visibility is weaker for many enterprises, the analytic anchors on managed app context, device state and downstream effects, using unified log subsystem events as enrichment.
| Analytic | Data source | Platforms |
|---|---|---|
| Camera grant on a non-catalogue app | MDM or EMM app inventory and permission state | Android, iOS (managed apps) |
| Camera session while locked or idle | Mobile threat defence or mobile EDR telemetry | Android, iOS where available |
| Capture followed by burst file writes and upload | MTD telemetry and gateway logs | Android, iOS |
| Policy drift | MDM audit log: cameraAccess or allowCamera changed in a restricted group | Android, iOS |
For a device where spyware is suspected, forensic triage with the Mobile Verification Toolkit (MVT) is the usual next step.
Measures: share of fleet on OS versions with background camera restrictions and indicators; share of restricted-area devices with cameras disabled and the policy enforced; number of non-catalogue apps holding camera permission; and time from a camera-while-locked alert to containment.
Response
- Identify the app and its install source from MDM inventory, and capture its permission grants.
- Preserve before wiping if spyware is suspected: follow the Mobile Spyware Infection Response Playbook.
- Contain: mark the device non-compliant and cut access through conditional access.
- Assess exposure: where and when the device was used, including meetings and secure areas, since captured images may include documents, screens and people.
- Treat as full compromise: the families in this technique also take audio, messages and credentials, so revoke sessions and tokens and reissue credentials.
- Notify where required: images of people can be personal data; involve your privacy team on whether a notification duty applies.
Where identity fits
Cameras are also an authentication channel: QR code sign-in, document scanning for identity checks and face-based unlock all depend on them. Spyware with camera access on a device used for these flows can capture enrolment QR codes or identity documents. Keep enrolment and recovery flows on managed devices, and treat captured QR provisioning codes as compromised credentials. The Mobile Access Credentials guide covers credentials held on phones.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for Mobile | M1006 Use Recent OS Version | Background camera restriction and visible indicators |
| NIST SP 800-53 Rev. 5 | SC-15 | Collaborative computing devices: prohibit remote activation and give an indication of use |
| NIST SP 800-53 Rev. 5 | AC-19, CM-7 | Mobile device access control and least functionality, including disabling cameras where not needed |
| NIST SP 800-53 Rev. 5 | SI-4 | Monitoring for unauthorised camera use |
| NIST CSF 2.0 | PR.AA-05, DE.CM-09 | Permissions managed by policy; monitoring of device software and runtime |
Common failure patterns
- Relying on the indicator alone: a user who does not know what the green dot or status bar icon means will not report it.
- Disabling cameras on unsupervised iOS devices: Apple documents that support for allowCamera there is deprecated; supervise devices that need the restriction.
- Setting CAMERA_ACCESS_DISABLED on work profile devices and assuming the device is camera-free: on those devices it covers the work profile only.
- Keeping old Android versions in service: background camera restrictions arrived in Android 9 and indicators in Android 12.
- Wiping before collecting evidence: spyware investigations need the device state preserved first.
Practitioner checklist
- Enforce minimum OS versions that include background camera restrictions and indicators.
- Set cameraAccess to CAMERA_ACCESS_DISABLED on fully managed Android devices for restricted areas.
- Set allowCamera to false on supervised iOS devices where policy forbids cameras.
- Review camera permission grants on non-catalogue apps every month.
- Alert on camera sessions while the device is locked or idle where MTD telemetry allows.
- Brief staff in sensitive roles on camera indicators and how to report them.
- Add camera-capture scenarios to the mobile spyware response runbook, including privacy assessment.
Standards and references
- MITRE ATT&CK: Video Capture (Mobile T1512)
- Android Developers: Android 9 behaviour changes, limited access to sensors in background
- Android Developers: Android 12 behaviour changes, camera indicators and toggles
- Apple: About the orange and green indicators in your iPhone status bar
- Google: Android Management API, enterprises.policies reference
- Apple: Device management schema, Restrictions payload
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile App Permissions · Mobile Spyware Infection Response Playbook · Mobile Device Management Security Guide