Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1429: Audio Capture

Adversaries may capture audio to collect information by leveraging standard operating system APIs of a mobile device. Examples of audio information adversaries may target include user conversations, surroundings, phone calls, or other sensitive information.

Android and iOS, by default, require that applications request device microphone access from the user.

On Android devices, applications must hold the `RECORD_AUDIO` permission to access the microphone or the `CAPTURE_AUDIO_OUTPUT` permission to access audio output. Because Android does not allow third-party applications to hold the `CAPTURE_AUDIO_OUTPUT` permission by default, only privileged applications, such as those distributed by Google or the device vendor, can access audio output.[1] However, adversaries may be able to gain this access after successfully elevating their privileges. With the `CAPTURE_AUDIO_OUTPUT` permission, adversaries may pass the `MediaRecorder.AudioSource.VOICE_CALL` constant to `MediaRecorder.setAudioOutput`, allowing capture of both voice call uplink and downlink.[2]

On iOS devices, applications must include the `NSMicrophoneUsageDescription` key in their `Info.plist` file to access the microphone.[3]

MobileT1429TechniqueObject v3.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Audio Capture matters because a compromised or abusive mobile app can turn a phone into a collection device for conversations, surroundings, calls, or other sensitive audio. For executives and security leaders, this is less about generic malware and more about protecting high-value mobile users, sensitive meetings, legal/compliance discussions, and operational environments where phones are present. ATT&CK notes Android and iOS permission gates, but the relationship context shows this behavior is common enough across mobile spyware and RAT families to merit explicit mobile security validation.

Executive priority

Prioritize this as a mobile privacy, executive protection, and incident response readiness issue. Leaders should ask whether managed mobile devices are kept on recent OS versions, whether microphone permissions are reviewed for business justification, and whether the organization can produce evidence during an investigation showing which apps had microphone access. This is especially relevant for high-risk users and environments where recorded speech could affect negotiations, regulated data handling, or operational security.

Technical view

For Android and iOS, validate controls around microphone authorization and visibility. Android apps require RECORD_AUDIO for microphone access; CAPTURE_AUDIO_OUTPUT is normally limited to privileged applications but may become relevant after privilege elevation. iOS apps require NSMicrophoneUsageDescription in Info.plist to request microphone access. Since ATT&CK provides no official detection text, SOC and mobile security teams should base coverage validation on the related detection strategy DET0673, local MDM/mobile security telemetry, app inventory, permission state, OS version, jailbreak/root indicators where available, and investigations of apps with unjustified microphone access.

Likely telemetry

  • Mobile device inventory with Android/iOS platform and OS version
  • Installed application inventory and app provenance where available
  • Application permission state, especially microphone access on Android and iOS
  • Android manifest permissions such as RECORD_AUDIO and any indication of privileged audio-output access such as CAPTURE_AUDIO_OUTPUT
  • iOS app metadata such as NSMicrophoneUsageDescription where available

Detection direction

  • Confirm whether DET0673 or an equivalent internal detection strategy is implemented for mobile audio capture behavior; ATT&CK does not provide native detection guidance for this technique.
  • Tune around permission context: microphone access alone is not malicious, so prioritize apps with no business need, suspicious provenance, high-risk users, or co-occurring root/jailbreak/privilege-elevation signals.
  • Review Android cases where privileged permissions or elevated access could change expected access boundaries, especially around CAPTURE_AUDIO_OUTPUT and voice-call audio capture.
  • On iOS, validate whether app review, MDM, or forensic workflows can identify apps requesting microphone access through NSMicrophoneUsageDescription and correlate that with user and device risk.
  • Expect blind spots where mobile telemetry is limited by OS privacy controls, unmanaged/BYOD scope, lack of app-permission history, or inability to inspect privileged or jailbroken devices.

Mitigation priorities

  • Keep mobile operating systems current, aligning with ATT&CK mitigation M1006 Use Recent OS Version, because newer releases may add security architecture improvements as well as patches.
  • Provide user guidance, aligning with M1011, on reviewing microphone permission prompts, denying unnecessary access, and reporting unexpected microphone indicators or suspicious apps.
  • Apply risk-based mobile app governance: inventory apps, review microphone permissions for business justification, and reduce unnecessary access for managed devices.
  • For high-risk users, validate incident response procedures for mobile collection: app inventory capture, permission review, OS version check, and escalation when spyware or RAT indicators are present.
  • Use local policy and compliance requirements to define evidence retention for device posture, app permissions, and user guidance completion.
Analyst notes and limits

The relationship context associates Audio Capture with multiple mobile campaigns, groups, and software families, including Android and iOS examples, which supports treating it as a recurring mobile surveillance behavior rather than a niche permission issue. However, those relationships do not prove current activity in any specific environment. The strongest defensive value is validating whether mobile governance and investigations can distinguish legitimate microphone use from suspicious or unjustified access.

ATT&CK lists no tactics for this object and provides no official detection text. The supplied fields identify platforms, permissions, external references, mitigations M1006 and M1011, and related detection strategy DET0673, but do not include detailed analytic logic. Local device management coverage, BYOD policy, OS restrictions, and available mobile telemetry will determine practical detectability.

Official MITRE ATT&CK definition

Audio Capture

Adversaries may capture audio to collect information by leveraging standard operating system APIs of a mobile device. Examples of audio information adversaries may target include user conversations, surroundings, phone calls, or other sensitive information.

Android and iOS, by default, require that applications request device microphone access from the user.

On Android devices, applications must hold the `RECORD_AUDIO` permission to access the microphone or the `CAPTURE_AUDIO_OUTPUT` permission to access audio output. Because Android does not allow third-party applications to hold the `CAPTURE_AUDIO_OUTPUT` permission by default, only privileged applications, such as those distributed by Google or the device vendor, can access audio output.[1] However, adversaries may be able to gain this access after successfully elevating their privileges. With the `CAPTURE_AUDIO_OUTPUT` permission, adversaries may pass the `MediaRecorder.AudioSource.VOICE_CALL` constant to `MediaRecorder.setAudioOutput`, allowing capture of both voice call uplink and downlink.[2]

On iOS devices, applications must include the `NSMicrophoneUsageDescription` key in their `Info.plist` file to access the microphone.[3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

Group Mobile

G0112: Windshift

Windshift is a threat group that has been active since at least 2017, targeting specific individuals for surveillance in government departments and critical infrastructure across the Middle East.[1][2][3]

Malware Mobile

S9005: DocSwap

DocSwap is an Android malware first identified in 2025, and attributed to Kimsuky. DocSwap’s name is a combination of its Korean name “문서열람 인증 앱” (Document Viewing Authentication App) and a phishing page masquerading as CoinSwap at the C2 address. Based on DocSwap’s name and Korean-language strings, DocSwap potentially targets mobile device users in South Korea. Several variants of DocSwap exist; one of the latest samples indicates that the adversary added a native decryption function that decrypts an internal APK.[1][2]

Android
Malware Mobile

S0507: eSurv

eSurv is mobile surveillanceware designed for the lawful intercept market that was developed over the course of many years.[1]

AndroidiOS
Malware Mobile

S1079: BOULDSPY

BOULDSPY is an Android malware, detected in early 2023, with surveillance and remote-control capabilities. Analysis of exfiltrated C2 data suggests that BOULDSPY primarily targeted minority groups in Iran.[1]

Android
Tool Mobile

S0408: FlexiSpy

FlexiSpy is sophisticated surveillanceware for iOS and Android. Publicly-available, comprehensive analysis has only been found for the Android version.[1][2]

FlexiSpy markets itself as a parental control and employee monitoring application.[3]

Android
Malware Mobile

S0328: Stealth Mango

Stealth Mango is Android malware that has reportedly been used to successfully compromise the mobile devices of government officials, members of the military, medical professionals, and civilians. The iOS malware known as Tangelo is believed to be from the same developer. [1]

Android
Relationship explorer

All related ATT&CK context

uses · Malware S0327: Skygofree Mobile uses · Malware S9005: DocSwap Mobile uses · Malware S0316: Pegasus for Android Mobile uses · Malware S0295: RCSAndroid Mobile uses · Malware S0507: eSurv Mobile uses · Malware S1079: BOULDSPY Mobile uses · Malware S0318: XLoader for Android Mobile uses · Malware S1082: Sunbird Mobile uses · Tool S0408: FlexiSpy Mobile uses · Malware S0489: WolfRAT Mobile uses · Malware S0328: Stealth Mango Mobile uses · Malware S0535: Golden Cup Mobile uses · Malware S0550: DoubleAgent Mobile uses · Malware S0558: Tiktok Pro Mobile uses · Malware S1077: Hornbill Mobile uses · Group G0112: Windshift Mobile uses · Malware S9006: VajraSpy Mobile uses · Malware S0655: BusyGasper Mobile uses · Malware S1231: GodFather Mobile uses · Malware S1080: Fakecalls Mobile uses · Malware S1061: AbstractEmu Mobile uses · Malware S0505: Desert Scorpion Mobile uses · Malware S1069: TangleBot Mobile uses · Malware S0320: DroidJack Mobile
Mitigations

Mitigation direction

Mitigation Mobile

M1006: Use Recent OS Version

New mobile operating system versions bring not only patches against discovered vulnerabilities but also often bring security architecture improvements that provide resilience against potential vulnerabilities or weaknesses that have not yet been discovered. They may also bring improvements that block use of observed adversary techniques.

Mitigation Mobile

M1011: User Guidance

Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
3.1
Created
Modified
Raw hash
6289c736e9f9fc19...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 3.1 Current bundle 6289c736e9f9…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Android Permissions

    Google. (2021, August 11). Manifest.permission. Retrieved September 22, 2021.

    Open source URL
  2. [2]
    Manifest.permission

    Android Developers. (2022, March 17). Voice Call. Retrieved April 1, 2022.

    Open source URL
  3. [3]
    Requesting Auth-Media Capture

    Apple Developers. (n.d.). Requesting Authorization for Media Capture on iOS. Retrieved April 1, 2022.

    Open source URL
  4. [4]
    Android Privacy Indicators

    Google. (n.d.). Privacy Indicators. Retrieved April 20, 2022.

    Open source URL
  5. [5]
    NIST Mobile Threat Catalogue APP-19
    Open source URL
  6. [6]
    iOS Mic Spyware

    ZecOps Research Team. (2021, November 4). How iOS Malware Can Spy on Users Silently. Retrieved April 1, 2022.

    Open source URL
  7. [7]
    mitre-attack T1429
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use