AN1773: Analytic 1773
A defender observes an application with declared microphone capability initiating microphone resource use through iOS audio frameworks, potentially during background execution or shortly after a silent wake event, followed by sustained audio capture and outbound encrypted traffic suggesting audio streaming or upload activity.
Analyst context for executives and security teams
AN1773 is a mobile detection analytic for iOS behavior where an app that has microphone capability begins using iOS audio frameworks, possibly in the background or after a silent wake, then sustains audio capture while encrypted outbound traffic suggests streaming or upload. For leaders, the value is not attribution; it is validating whether the organization can notice sensitive audio collection from managed or business-used iOS devices before it becomes a privacy, legal, executive-protection, or incident-response issue.
Executive priority
Prioritize this where iOS devices are used for executive communications, regulated work, sensitive meetings, or operational environments where microphone misuse could create confidentiality or compliance exposure. Security leaders should ask whether mobile device governance, app review, network visibility, and incident response playbooks can distinguish expected microphone use from suspicious background capture and upload behavior. Because ATT&CK provides no official detection logic or relationship context here, this should drive a coverage validation exercise rather than a claim of existing detection maturity.
Technical view
SOC, mobile security, and IR teams should validate whether they can correlate three evidence points on iOS: an application declaring or receiving microphone capability, invocation of iOS audio frameworks during foreground, background, or post-wake activity, and sustained encrypted outbound traffic consistent with upload or streaming. The analytic is platform-specific to iOS and has no supplied tactic or related technique context, so detection engineering should avoid overfitting to a campaign narrative. Triage should focus on app identity, user-approved microphone permission state, timing relative to user activity, background execution indicators, duration of capture, and destination/network characteristics.
Likely telemetry
- iOS application inventory and microphone permission/capability data
- Mobile device management or mobile security records showing app installation, permission state, and background execution context where available
- Endpoint or mobile telemetry indicating use of iOS audio frameworks or microphone resource access where available
- Device activity context around silent wake, background execution, or shortly-after-wake behavior where available
- Network metadata for outbound encrypted connections, including timing, duration, volume, destination, and app association where available
Detection direction
- Validate that detection logic correlates microphone-capable app behavior with actual microphone resource use, not just permission declaration.
- Tune for sustained capture plus outbound encrypted traffic, because either signal alone may be common for legitimate voice, meeting, recording, or communications apps.
- Review background or post-wake microphone use carefully; it is a key context in the supplied analytic but may require telemetry not present on every iOS fleet.
- Use app identity, user activity, business purpose, duration, and network destination to reduce false positives from approved collaboration, calling, dictation, or recording applications.
- Document blind spots where iOS telemetry, app-to-network attribution, background execution visibility, or encrypted traffic metadata are unavailable.
Mitigation priorities
- Maintain governance over which iOS applications are approved for business use and which are allowed microphone access.
- Review microphone permissions for high-risk user groups and sensitive operating contexts, especially where background use would be unexpected.
- Use mobile device management or equivalent policy controls to limit unmanaged or unnecessary applications where supported by the environment.
- Strengthen app review processes to consider declared microphone capability and background behavior before deployment or approval.
- Preserve network and mobile telemetry needed for IR to determine whether observed microphone use was legitimate, sustained, and associated with outbound upload activity.
Analyst notes and limits
This object is a detection analytic, not a technique or campaign report. The supplied ATT&CK fields identify iOS as the platform and describe a behavioral pattern involving microphone capability, iOS audio framework use, possible background or silent-wake context, sustained audio capture, and encrypted outbound traffic. No tactics, relationships, aliases, labels, or official detection logic were supplied, so this Glexia take frames practical validation questions rather than asserting a complete analytic.
Assessment is limited to the supplied official STIX fields, the MITRE external reference, and the absence of relationship context. Local telemetry availability on iOS will determine whether the behavior can be detected with confidence. Encrypted outbound traffic can support suspicion when correlated with microphone activity, but content cannot be inferred from metadata alone.
Analytic 1773
A defender observes an application with declared microphone capability initiating microphone resource use through iOS audio frameworks, potentially during background execution or shortly after a silent wake event, followed by sustained audio capture and outbound encrypted traffic suggesting audio streaming or upload activity.
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 | a1778b74cb33… |
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 AN1773Open 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.