MITRE ATT&CK T1123 Audio Capture: Detecting Data Gathering

Audio Capture (T1123) turns the microphone on a laptop, desktop or meeting room PC into a listening device, and the conversations it records (deal talks, board calls, incident bridges, passwords read aloud) are often worth more than the files an intruder can steal. ATT&CK v20 places T1123 in the Collection tactic (TA0009) on Windows, Linux and macOS, with no sub-techniques and no formal mitigations, which makes detection and operating system privacy controls the main defences. This page covers how adversaries use the technique, the behaviour chain ATT&CK v20 tells you to detect on each platform, the microphone controls Windows and macOS give administrators, how to test, and where it maps in common frameworks. It is written for detection engineers and endpoint owners. For the consumer device side (smart speakers and voice assistants), see the Smart Speaker and Voice Assistant Privacy Guide; this page stays on the ATT&CK technique view.

Key takeaways

• It is a feature of commodity and state tooling alike. ATT&CK v20 lists more than 30 procedure examples, from remote access trojans such as DarkComet, NanoCore and Remcos to espionage frameworks such as Flame, TajMahal and MgBot.
• Detect the chain, not the API call. ATT&CK v20 detection strategy DET0221 pairs an unusual process opening audio devices with audio files written to temp or user folders, then exfiltration.
• Call applications are a target too. T9000 recorded Skype calls through the Skype API, TajMahal captured VoIP application audio, and ATT&CK records VOID MANTICORE gathering audio during a Zoom session.
• Privacy controls are your mitigations. ATT&CK v20 maps no M-series mitigation to T1123, so Windows app privacy policies, macOS TCC and PPPC profiles, and hardware mute carry the preventive load.
• Executives and meeting rooms come first. Prioritise devices where sensitive conversations happen: executive laptops, board room PCs and incident response bridges.

What T1123 is

ATT&CK describes Audio Capture as using a computer's peripheral devices (microphones and webcams) or applications (voice and video call services) to record audio and listen in on sensitive conversations. Malware or scripts talk to the device through an API provided by the operating system or an application, and the recordings are usually written to disk and exfiltrated later. The audio APIs involved are ordinary ones:

• Windows: the multimedia libraries (ATT&CK's analytic names winmm.dll and avrt.dll), the Media Control Interface (NightClub used mciSendStringW with the LAME encoder), and call application APIs.
• Linux: ALSA and PulseAudio devices, and capture utilities such as arecord.
• macOS: the AVFoundation and CoreAudio frameworks. LightSpy used AVFoundation to record audio and packaged it as JSON for exfiltration.

Audio Capture sits beside Screen Capture (T1113), Video Capture (T1125, see the MITRE ATT&CK T1125 Video Capture) and Input Capture (T1056) in the same surveillance modules. See the MITRE ATT&CK T1056 Input Capture and the ATT&CK Collection Tactic Guide.

How adversaries use it: real cases

Every row below is an ATT&CK v20 procedure example with its cited source.

Commodity RATs (DarkComet, NanoCore, Remcos, jRAT, Revenge RAT) appear in the same list, so audio capture is not limited to targeted espionage. See the AsyncRAT, Remcos and njRAT Commodity RATs Guide, the APT37 Threat Actor Profile Guide and the Commercial Spyware Guide.

What to detect and where

ATT&CK v20 detection strategy DET0221 has one analytic per platform. Each looks for an unexpected process touching audio input, followed by audio files on disk.

Turning the analytics into rules

• Build an allow-list of microphone users: meeting clients, softphones, dictation and accessibility tools, browsers. Any other process opening the audio stack is a lead. On Windows 11, the Settings app keeps a seven-day app usage history for the microphone and camera that helps build the baseline on sample machines.
• Weight by process path and signer: unsigned binaries, scripts hosts (PowerShell, wscript), and anything running from AppData, Temp, /tmp or ~/Library deserve the highest score.
• Watch for audio files in odd places: .wav, .mp3, .ogg, .aiff or .amr files created repeatedly in temp or hidden folders, especially in fixed-size chunks or at regular intervals.
• Chain to exfiltration: growth in archive files or outbound transfers shortly after audio file creation links the collection to Exfiltration Over C2 Channel (T1041) or Automated Exfiltration (T1020).
• Look inside call clients: unsigned or unexpected modules loaded into Teams, Zoom or softphone processes are a stronger signal than the call client using the microphone.
• Use the TCC record on macOS: a new kTCCServiceMicrophone grant to a binary outside your software catalogue is a high-value alert.

Mitigations and preventive controls

ATT&CK v20 maps no M-series mitigation to T1123, because recording audio is a normal use of system features. The controls below are NHI Mgmt Group recommendations built on platform documentation.

Two limits to plan for. First, Windows camera and microphone policies were historically scoped to packaged (Store and MSIX) apps; the desktop app namespace and unsigned controls are what reach classic Win32 malware, and they need Windows 11 24H2 or later. Second, the Windows and macOS privacy prompts protect against unknown apps, not against malicious code running inside an app that already has microphone permission, which is why module load monitoring in call clients matters. See the macOS TCC and Privacy Permissions Management Guide, the App Control for Business (WDAC) and the M1038 Execution Prevention.

Decision guidance

• Small organisations: rely on EDR alerts for unexpected microphone access, deny the microphone on shared and kiosk devices, and educate executives about the system tray and menu bar recording indicators that show when a microphone is in use.
• Larger organisations: deploy the Windows namespace deny lists and macOS PPPC profiles through MDM, build the DET0221 chain in the SIEM, and run quarterly reviews of which apps hold microphone permission.
• High-risk roles: for executives, legal and M&A teams, add dedicated meeting room hardware with physical mute and keep sensitive discussions off general-purpose laptops. See the Executive and VIP Device Protection Guide.

Where identity fits

Recorded audio is a credential source. Help desk calls, incident bridges and pairing sessions regularly contain one-time codes, recovery answers and API keys read aloud. Treat any confirmed audio capture on a device used for such calls as a credential exposure: rotate secrets and tokens discussed on recorded calls, and review service account and break-glass passwords that were spoken during the exposure window. Recorded voices also feed voice cloning for social engineering, so tighten call-back verification for password resets.

How to test

1. Plan: agree scope and data handling with legal and HR, since test recordings may capture real conversations. Use a lab device or a muted room.
2. Emulate safely: on a test host, run a benign script or an authorised emulation framework module that opens the default microphone and writes a short audio file to a temp folder.
3. Verify telemetry: confirm process creation, device access and file creation events reach the SIEM for each platform, plus the TCC decision on macOS.
4. Verify the rule: the DET0221 chain should alert within your target time, and the allow-listed meeting client should not.
5. Verify prevention: confirm the namespace deny list or PPPC profile blocks an unapproved binary and logs the decision.
6. Roll back: remove test binaries and recordings, and record exceptions created during the test.

Measures: share of endpoints with microphone policy deployed, number of apps holding microphone permission per platform, mean time to alert in tests, and number of unexplained microphone-access alerts per month after tuning.

Common failure patterns

• Treating every microphone user as normal: without an allow-list the alert volume from meeting clients drowns the signal, so the rule gets disabled.
• Store-app-only policy: a privacy policy that covers only packaged apps leaves classic desktop malware untouched.
• Ignoring call client internals: injected modules inside a trusted call client inherit its permission and its normal-looking behaviour.
• No macOS telemetry: LightSpy, MacMa and MacSpy all record audio on macOS, yet many SOCs collect little from Macs.
• Missing the credential angle: confirmed recording without rotating what was said on calls leaves stolen secrets valid.

Framework mapping

Practitioner checklist

• Build an allow-list of processes permitted to use the microphone on each platform.
• Implement DET0221 as a chain: device access, audio file creation, outbound transfer.
• Deploy Windows microphone deny lists for unsigned and unapproved desktop apps on Windows 11 24H2 and later.
• Deploy a macOS PPPC profile that denies microphone access to apps that never need it.
• Collect TCC decisions and unified log audio events from Macs.
• Alert on unsigned modules loaded into call clients and softphones.
• Disable microphones on kiosks and shared devices that do not need them.
• Rotate secrets read aloud on calls from any device with confirmed audio capture.

Standards and references

• MITRE ATT&CK: T1123 Audio Capture
• MITRE ATT&CK: Collection (TA0009)
• Microsoft Learn: Privacy Policy CSP
• Microsoft Learn: Windows privacy controls
• Apple Platform Deployment: Privacy Preferences Policy Control payload settings
• MITRE D3FEND: System Call Analysis
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ATT&CK Collection Tactic Guide · VoIP and SIP Security Guide · Microsoft Teams Security Guide · macOS Detection and Response Guide · Sysmon Guide