AN1772: Analytic 1772
A defender observes an application holding microphone capture capability transitioning into active microphone resource usage through Android audio APIs (e.g., MediaRecorder or AudioRecord), followed by sustained capture while the application is backgrounded or the device is locked, and subsequent outbound network traffic suggesting potential audio exfiltration or streaming.
Analyst context for executives and security teams
This analytic matters because it focuses on a high-sensitivity mobile privacy and business-risk scenario: an Android application with microphone capability begins actively using the microphone, continues capture while backgrounded or while the device is locked, and then generates outbound network traffic that could indicate audio streaming or exfiltration. For executives and security leaders, the value is not just detecting “microphone use,” but validating whether the organization can prove when mobile devices may be capturing sensitive conversations and whether SOC, mobile security, and incident response teams have the telemetry to investigate it.
Executive priority
Prioritize this where Android devices are used in sensitive business settings, regulated environments, executive communications, field operations, or cyber-physical contexts. Leaders should ask whether mobile device monitoring can correlate microphone permission, active audio API usage, app foreground/background state, device lock state, and network activity. This supports privacy risk management, incident triage, compliance evidence, and decisions about acceptable mobile application behavior. Because ATT&CK provides no official detection logic or relationships for this analytic, organizations should treat it as a validation target rather than evidence of existing coverage.
Technical view
For SOC, detection engineering, and IR teams, the key validation point is whether Android telemetry can show an app moving from microphone capture capability to active microphone resource usage through Android audio APIs such as MediaRecorder or AudioRecord, then sustaining capture while backgrounded or locked, followed by outbound network traffic. Detection should be correlation-based: microphone permission or capability alone is not enough, and network traffic alone is not enough. Useful triage context includes application identity, whether the app was foregrounded, lock-screen state, duration of capture, destination/network pattern, and whether the behavior is expected for the app category.
Likely telemetry
- Android application permission or capability data for microphone access
- Android audio API or microphone resource usage events, where available
- Application foreground/background state
- Device lock or screen state
- Process or application identity metadata
Detection direction
- Validate whether telemetry can distinguish microphone permission from active microphone use.
- Correlate active use of Android audio APIs with sustained capture while the app is backgrounded or the device is locked.
- Look for subsequent outbound network activity after sustained capture, while avoiding conclusions based only on traffic volume or microphone permission.
- Tune for expected applications that legitimately record or stream audio, such as conferencing, voice notes, accessibility, or communication apps.
- Review blind spots where mobile telemetry does not expose API-level microphone use, app state, lock state, or destination context.
Mitigation priorities
- Start with mobile application governance: restrict or review apps that request microphone access on Android devices used for sensitive work.
- Use mobile device management or equivalent policy controls to limit microphone-capable applications where business need is not established.
- Require investigation playbooks for background or locked-device microphone activity paired with outbound network traffic.
- Maintain inventory and approval evidence for applications permitted to access audio capture capabilities.
- For incident response readiness, preserve mobile telemetry sources that can support timeline reconstruction across permissions, audio use, app state, lock state, and network activity.
Analyst notes and limits
This object is a mobile ATT&CK detection analytic for Android. The supplied description gives a clear behavior chain: microphone capability, active audio API use, sustained capture in background or locked state, and outbound network traffic. No tactics, relationships, aliases, labels, or official detection implementation are supplied, so the take emphasizes defensive validation and telemetry requirements rather than specific adversary use or guaranteed detection.
The source fields do not provide detection logic, data source mappings, tactics, related techniques, threat actors, software, mitigations, or examples. Local Android telemetry availability will determine whether this analytic can be implemented reliably. This summary should not be read as evidence of active exploitation, attribution, or existing coverage in any environment.
Analytic 1772
A defender observes an application holding microphone capture capability transitioning into active microphone resource usage through Android audio APIs (e.g., MediaRecorder or AudioRecord), followed by sustained capture while the application is backgrounded or the device is locked, and subsequent outbound network traffic suggesting potential audio exfiltration or streaming.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | dcc590176444… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1772Open source URL
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.