Mobile T1429 Audio Capture on Android and iOS

Audio Capture (T1429) is an adversary turning a phone's microphone into a listening device, recording conversations, calls and the room around it through the same operating system APIs that voice notes and video calls use. MITRE ATT&CK for Mobile v20 lists T1429 under the Collection tactic for both Android and iOS, and almost every spyware family in the knowledge base does it. This guide is for mobile security engineers, MDM and mobile threat defence (MTD) administrators and SOC analysts who need to know how the permission models work on each platform, what the procedure examples show, which ATT&CK analytics apply and how to respond. It builds on the tactic overview in the MITRE ATT&CK for Mobile Guide rather than repeating it.

Key takeaways

The permission is the control point. Android apps need RECORD_AUDIO and iOS apps need an NSMicrophoneUsageDescription purpose string plus user consent before the microphone opens, so app vetting and permission review catch most commodity cases.
Privilege changes the picture. ATT&CK notes that capturing call audio on Android needs CAPTURE_AUDIO_OUTPUT, which third-party apps cannot hold by default, but that adversaries may gain it after elevating privileges. Mercenary spyware works at this level.
The OS gives users visible signals. Android 12 and later show a status bar icon when the microphone is in use; iOS shows an orange indicator and names the app in Control Center. Train users to report an unexpected indicator.
ATT&CK maps only two mitigations. Use Recent OS Version (M1006) and User Guidance (M1011). Everything else, such as app allowlisting and MTD, is enterprise practice built on top.
Targeted users need more than MDM. For people at risk of state-grade spyware, combine prompt updates, Apple Lockdown Mode where it fits and periodic forensic checks with the Mobile Verification Toolkit.

What T1429 covers on each platform

ATT&CK defines Audio Capture as collecting information by leveraging standard operating system APIs of a mobile device, with targets that include user conversations, surroundings and phone calls. The technique sits in the Collection tactic only and has no sub-techniques in v20. Both platforms are listed and both require apps to ask the user before using the microphone; the mechanics differ.

Aspect	Android	iOS
Declaration	`RECORD_AUDIO` permission in the manifest, granted at runtime	`NSMicrophoneUsageDescription` key in `Info.plist`, shown in the consent prompt
Call audio	`CAPTURE_AUDIO_OUTPUT` is not available to third-party apps by default; only privileged apps from Google or the device vendor hold it (per ATT&CK)	ATT&CK describes no separate third-party call audio permission; procedure examples that record calls on iOS run with elevated privileges
Background limits	Since Android 9, apps running in the background cannot access the microphone or camera	Apps declare background modes; the system controls when an app keeps running
User signal	Android 12 and later: status bar icon when an app accesses the microphone, plus a Quick Settings toggle to block microphone access for all apps on supported devices	Orange indicator when an app uses the microphone without the camera; Control Center names the app that recently used it
Review	Settings, Privacy, permission manager; MDM permission grant state for managed apps	Settings, Privacy & Security, Microphone lists apps that requested access and lets the user turn each off

The key point for defenders is that both platforms make silent microphone use hard for an ordinary app. Commodity Android malware therefore relies on talking the user into granting the permission, often combined with accessibility abuse (see the Mobile App Permissions guide). Spyware that reaches root or kernel privileges sits below these controls, which is why the response for targeted users is different.

What the procedure examples show

ATT&CK v20 lists more than fifty software, group and campaign entries for T1429. They fall into three groups, and each needs a different defensive emphasis.

Group	Examples in ATT&CK	What ATT&CK records	Defensive emphasis
Mercenary and state-grade spyware	Pegasus for iOS (S0289), Pegasus for Android (S0316), Operation Triangulation (C0054), FinFisher (S0182)	Pegasus records audio on both platforms; during Operation Triangulation the actors used a microphone-recording module; FinFisher records phone conversations	Patch speed, Lockdown Mode, forensic checks, incident response for targeted users
Targeted surveillanceware	LightSpy (S1185), Hornbill (S1077), C0033 with StrongPity, BOULDSPY (S1079)	LightSpy captured environment audio, phone calls and VoIP calls; Hornbill records environmental and call audio; StrongPity recorded calls in C0033; BOULDSPY records cell and VoIP calls	App source control, sideloading restrictions, MTD and app vetting
Financially motivated malware	Fakecalls (S1080), GodFather (S1231), XLoader for Android (S0318)	Fakecalls can turn on the microphone to capture audio	Permission review, Play Protect, user guidance on unexpected permission prompts

Kaspersky's analysis of the TriangleDB implant used in Operation Triangulation is a useful reminder of how privileged implants behave: the implant ran in memory, so traces were lost on reboot, and it requested microphone entitlements that its core code did not use, which suggested recording was delivered by separate modules. A permission audit of installed apps would not have shown it. See the Commercial Spyware Guide for the wider market.

Detection: ATT&CK v20 analytics

ATT&CK v20 attaches detection strategy DET0673 Detection of Audio Capture to T1429, with one analytic per platform. Both correlate evidence that an analyst can actually see on mobile, such as app vetting results, management state and network flows, rather than assuming endpoint agents with kernel visibility.

Android, dynamic analysis: calls to AudioRecord.startRecording() or MediaRecorder.start() by an app that is not on an approved audio allowlist, observed in application vetting or instrumented dynamic analysis.
Android, file artefacts: creation of files with audio MIME types such as audio/mp4, audio/aac or audio/3gpp inside the app's private data directory shortly after a recording API starts, seen in dynamic traces or in an acquired app container.
Android and iOS, network: uploads that follow recording activity, seen at a secure web gateway or proxy where inspection is deployed.
iOS, app vetting: code-signing entitlements and Info.plist privacy usage keys, so an app that declares microphone use without a business need is flagged before it reaches devices.
iOS, network flows: flow metadata from Apple Network Extension content filters, per-app VPN or a secure web gateway, compared with what the app is expected to do.

In practice most organisations will not run instrumented analysis on every app. The realistic programme is app vetting before approval, MDM inventory of managed apps and their permission grants, MTD alerts on sideloaded or risky apps, and network telemetry for managed traffic. The Mobile Threat Defense Buyer's Guide covers what to ask MTD tools to report.

Prevention: ATT&CK mitigations in practice

ATT&CK mitigation	What ATT&CK says for T1429	How to apply it
M1006 Use Recent OS Version	Android 9 and above restrict access to the microphone, camera and other sensors from background applications	Set a minimum OS version in MDM compliance policy; block or limit access for devices that fall below it; track patch latency for high-risk users
M1011 User Guidance	Users should be wary of granting dangerous or privacy-intrusive permissions, such as access to microphone or audio output	Teach users what the orange iOS indicator and the Android status bar icon mean, and how to report an app that uses them unexpectedly

Enterprise controls that build on these, labelled here as NHI Mgmt Group practice rather than ATT&CK mappings:

Managed app sources: restrict installation to the managed store or Google Play and the App Store, and block unknown sources on fully managed Android devices. See the Android Enterprise Security Guide.
Permission policy for work apps: on Android Enterprise, the device policy controller can read and set the grant state of runtime permissions for managed apps; deny microphone access for apps that have no business need.
App vetting before approval: review requested permissions and iOS purpose strings against the app's function; a calculator that asks for the microphone is a finding.
Lockdown Mode for targeted users: Apple describes it as an optional, extreme protection for people who may be personally targeted, available from iOS 16. It blocks most Messages attachment types and complex web technologies, which reduces the routes that spyware has used. Note that a device cannot enrol in MDM while Lockdown Mode is on, although a device already enrolled stays managed. See the Apple Lockdown Mode Guide.

How to implement

Inventory: export the managed app inventory from MDM with permission or entitlement data, and list every app holding microphone access on corporate devices.
Define the allowlist: agree which app categories genuinely need the microphone (calling, conferencing, dictation) and record it as policy.
Audit mode first: run the permission comparison for two to four weeks and report deviations without removing apps, so false positives such as approved dictation tools are found early.
Enforce for a pilot ring: apply permission denial and app blocking for one business unit, then widen. Keep a rollback path: the MDM policy that denies a permission can be removed to restore the previous grant state.
Add the high-risk tier: identify executives, journalists, legal and security staff who face targeted threats, and apply faster update deadlines, Lockdown Mode where workflows allow and scheduled forensic checks.
Wire up response: agree who receives MTD and user reports, and what evidence to preserve before a device is wiped.

Decision guidance

Fully managed versus BYOD: on corporate-owned devices you can enforce app sources and permission states. On BYOD with an Android work profile or Apple User Enrollment you control only the managed side, so rely on MTD, user guidance and conditional access.
Small organisations: an MDM minimum OS rule, managed app store only and a one-page user guide on the microphone indicators cover most of the risk.
Large or high-risk organisations: add MTD with app risk scoring, a vetting workflow for new apps, a high-risk user programme and a relationship with a forensic provider.

Responding to suspected audio capture

Do not reset the device first: a factory reset destroys the evidence that an in-memory implant may already have lost on reboot. Isolate it from sensitive meetings, record the indicator or symptom with time and app name, and capture an iOS backup or sysdiagnose, or an Android bug report, before changes. The Mobile Verification Toolkit, released by Amnesty International's Security Lab in July 2021, supports consensual forensic analysis of Android and iOS devices, including iOS backups, filesystem dumps and sysdiagnose archives. See the Mobile Verification Toolkit (MVT) guide and the Mobile Spyware Infection Response Playbook for the full process.

Detection and measurement

Microphone grant ratio: share of managed apps holding microphone access that are on the approved list (target 100 percent).
OS currency: percentage of devices on a supported OS version within your patch deadline, reported separately for high-risk users.
Sideload exposure: number of devices with apps from unknown sources, trending to zero on corporate devices.
Vetting coverage: percentage of approved apps with a recorded permission review.
Report to triage time: time from a user reporting an unexpected microphone indicator to analyst triage.

Framework mapping

Framework	Reference	Relevance to T1429
MITRE ATT&CK for Mobile	T1429, M1006, M1011, DET0673	Technique, mitigations and detection strategy
NIST SP 800-53 Rev. 5	AC-19 Access Control for Mobile Devices; CM-7 Least Functionality; SI-4 System Monitoring	Mobile device restrictions, permission minimisation, monitoring
NIST CSF 2.0	DE.CM-09	Monitoring of hardware, software and runtime environments for adverse events
OWASP MASVS	MASVS-PRIVACY	For in-house apps: minimise access to sensitive data such as audio

Common failure patterns

Trusting the prompt alone: users approve microphone prompts out of habit, especially when the app explains it as a feature.
Allowing sideloading on corporate devices: most commodity families in the ATT&CK list arrive outside official stores.
Wiping before collecting evidence: a reset removes the chance to confirm whether spyware was present and what else it reached.
One policy for every user: the people most likely to face state-grade spyware get the same update deadline as everyone else.
Treating BYOD as covered: on a work profile or User Enrollment the enterprise cannot see personal apps that hold the microphone.

Practitioner checklist

Export managed apps with microphone permission or entitlement and reconcile against an approved list.
Set an MDM minimum OS version and block non-compliant devices from sensitive resources.
Restrict corporate devices to managed or official app stores.
Add microphone permission and iOS purpose strings to app vetting criteria.
Publish user guidance on the Android status bar icon and the iOS orange indicator.
Run a high-risk user programme with faster patching and Lockdown Mode where workflows allow.
Agree evidence capture steps (backup, sysdiagnose, bug report) before any device reset.
Track the five metrics above monthly.

Mobile T1429 Audio Capture: Detecting Data Collection on Android and iOS