Detecting T1123 Audio capture

How T1123 audio capture shows up in a SOC queue

A SOC lead rarely receives a ticket that says audio capture is happening. The signal usually arrives as an unexpected process touching a microphone device or writing audio-like files on a host where nobody has a business reason to record. T1123 Audio capture sits under the Collection tactic (TA0009), which ATT&CK defines as the adversary trying to gather data of interest to its goal. For T1123, that goal is spoken or ambient sound from a room where a device sits, such as meeting conversations, calls or sensitive discussions. The technique is identified in ATT&CK by the ID T1123, and this page maps detections against Enterprise ATT&CK 20.0, so any rule or hunt built from it should cite that version.

In intrusions, audio capture tends to appear after an adversary already has a foothold and some reason to believe the device is useful. It is rarely the first thing an attacker does, which means the SOC may see it as one step in a longer sequence rather than as an isolated alert. The practical question for the queue is whether a given host has a documented reason to use a microphone, and which applications and service accounts are approved to do so. Confirm that inventory with the endpoint and collaboration owners before tuning anything, because a missing or stale list will push analysts toward either ignoring alerts or escalating every meeting app. Also confirm with your endpoint vendor which device-access events it records, since that determines whether an analyst can see the capture or only the process that launched it.

Expect the first triage decision to be about context rather than certainty. An analyst should be able to answer three things quickly: which process accessed the audio input, whether that process is one the business expects on that host, and whether the same host shows other suspicious activity in the same window. Build those answers into the alert itself, so a single microphone event does not require a manual investigation from scratch. Plan for false positives from conferencing software, voice assistants and recording utilities that users install on purpose. Those are the cases that will consume most of your review time, so agree the allowed list and its owner before the first alert storm arrives.

Which telemetry reveals audio capture on each platform

This table maps Process Creation (DC0032), File Access (DC0055) and File Creation (DC0039) to the signals that suggest audio capture on Linux, macOS and Windows, and names an open-source collector for each. Read each row as a candidate signal to baseline in your own estate, not as a standalone alert. Process and file telemetry work best when paired with an inventory of which applications are approved to use microphones.

Platform	Telemetry and signal	Open-source collector	Validation note
Linux, Process Creation	Unexpected process starting while an audio input device is in use	Wazuh agent with auditd execution rules	Baseline approved recording tools per host group
Linux, File Access	Reads of audio device nodes by processes outside an approved list	auditd watch rules on device paths	Confirm device paths on your distribution and audio stack
macOS, Process Creation	Unfamiliar process launching while microphone access is granted	Velociraptor artifacts, Wazuh agent log collection	Confirm supported log queries for your macOS version
macOS, File Creation and Access	New audio files written to user library or temp paths by unexpected processes	Wazuh file integrity monitoring, Velociraptor	Test exclusions for legitimate conferencing and dictation apps
Windows, Process Creation	Process with no business role starting alongside microphone use	Sysmon process creation events forwarded to Wazuh	Compare against software inventory before tuning
Windows, File Creation	Audio container files created in profile or temp folders	Sysmon file creation events, Wazuh agent	Confirm which folders your users legitimately write audio to
Windows, File Access	Access to audio capture output files by a process other than the writer	Sysmon file events, Velociraptor hunts	Validate with a range exercise before enabling alerts
ATT&CK mapping (all platforms)	Process Creation and File Creation are the data components most often referenced for Collection	Not applicable, use the ATT&CK 20.0 STIX bundle	Confirm current DET IDs and analytics for T1123 in the bundle

Detection logic SOC teams can tune for T1123

T1123 Audio capture is hard to see because recording is often done with tools that are legitimate on the same endpoint. The cards below describe detection ideas that combine process, file and time context, so analysts can separate suspicious recording from meeting, dictation and assistant activity. Thresholds are starting points that teams should tune against their own baseline.

Unexpected process opening audio devices

Build an allowlist of known processes that open microphone or audio input devices, such as conferencing clients, dictation tools and voice assistants approved for your fleet. Alert when a process outside that list opens an input device, especially a command-line interpreter, a script host or a binary running from a user-writable directory. Tune by device class and by parent process, because a browser tab requesting a microphone looks different from a background service holding one open. Expect false positives from newly installed meeting plugins and from driver utilities that poll devices at boot. Confirm with each endpoint vendor how audio device access is logged before writing the rule.

Audio files written to unusual paths

Alert on creation of common audio container files, such as WAV, MP3, M4A, OGG and FLAC, in locations that users and approved applications rarely write to, such as temporary directories, public profile folders or hidden directories under user home folders. Pair the file creation event with the process that created it, and raise priority when the process was not launched interactively. Tune the path list to your environment and exclude known recording output folders for approved meeting recorders. Expect false positives from ringtones, notification sounds and build pipelines that generate audio assets, so review file size growth over a short window before escalating.

Recording activity outside working windows

Compare microphone access and audio file creation against approved business windows for each user group, such as scheduled meetings, maintenance periods and service desk hours. Activity from accounts that are logged off, locked or idle, or that occurs in the early morning on endpoints assigned to remote staff, deserves review. Set the window per role rather than one global schedule, and treat repeated events as stronger than single events. Expect false positives from shift workers, travelers in other time zones and scheduled jobs that run overnight, so record the exception owner for each approved schedule.

Audio capture followed by staging or transfer

Correlate audio file creation with later archive creation, file access on the same audio file and outbound network connections from the same process within a defined window. The combination matters more than any single event, because most audio capture is harmless on its own. Start with a window that matches your typical meeting length and your exfiltration detections, then tune it using known recording workflows. Expect false positives from users who record meetings and upload them to approved cloud storage, so match destinations against your sanctioned services list.

Sigma-style logic for audio device access

Express the detections as Sigma-style logic: a selection on process creation or device access events, a filter block for approved parents, images and users, and a condition that fires when the selection matches and the filter does not. Keep one rule per signal so each can be tuned and disabled separately. Map each rule to the ATT&CK version your team targets, and record the data components it relies on, such as Process Creation and File Creation, so that gaps in telemetry are visible. Confirm that your log pipeline keeps the fields the filter needs before deploying.

How to validate that the T1123 detection fires

This sequence proves, in a private cyber range, that a benign audio-capture activity on a test endpoint produces telemetry, reaches the SIEM and triggers the T1123 detection within a measured window. It also records false positive behavior so the team knows whether the rule is ready for production.

Agree the emulation scope in writing
The security lead, the detection engineer and the owner of the test endpoints agree which hosts, operating systems and user accounts are in scope, which benign audio-capture activity will be run, and who may stop the exercise. Scope also names the ATT&CK version the rule targets, since releases can rename or deprecate techniques. Done when the signed scope note lists the test assets, the activity, the stop conditions and the ATT&CK version, and the cyber range change record references it.
Prepare the test endpoints and baseline
The range operator confirms that the Linux, macOS and Windows test endpoints run the agents that forward Process Creation, File Access and File Creation telemetry to the SIEM, and that the audio device state is recorded before the run. The detection engineer captures a baseline window with no activity so normal application audio use is known. Done when the baseline shows the expected event types arriving and the agent health checks are green on every endpoint in scope.
Run the benign audio-capture activity
The operator runs a pre-approved, non-malicious audio-capture action on each test endpoint, using the same steps listed in the emulation plan and a timestamp log kept by the operator. Each run is labeled with a unique run identifier so events can be matched later. Done when the operator's log lists the start and end time, the endpoint and the run identifier for every run, and no run went outside the agreed scope.
Confirm telemetry arrives in the SIEM
The detection engineer searches the SIEM for the run identifier's time window and host to confirm that the expected process, file access and file creation events are present, with fields such as host name, user and process path populated. Gaps are logged as collection issues, not detection failures. Done when every run shows the expected event types in the SIEM, or a documented gap has been raised with the owner of the agent or log pipeline.
Confirm the rule fires and measure alert timing
The detection engineer checks that the T1123 rule or analytic generated an alert for each run and records the time between the first event and the alert creation. The alert is compared with the operator's log to confirm it maps to the correct endpoint and run. Done when each run has either a matched alert with a recorded time to alert or a documented miss with the reason, such as a missing event field or a rule condition that did not match.
Record false positive results from normal use
The detection engineer reviews alerts raised during the baseline window and during ordinary user activity on the same endpoints, then classifies each alert as expected, benign or unexplained. Recurring benign sources, such as known conferencing applications, are noted as candidates for tuning rather than suppressed without review. Done when every alert from the test window has a classification and each benign pattern has a tuning decision recorded.
Document results and retest after rule changes
The team records, for each run, the run identifier, endpoint, ATT&CK version, rule version, time to alert, match result and false positive classification in the validation log. After any rule change, the same run set is repeated against the same endpoints so results stay comparable. Done when the validation record is stored with the detection, a retest is scheduled for every rule change, and the results are shared with the security operations lead.

Why Linux, macOS and Windows need different detection logic

Linux does not expose audio capture through one interface, so detection logic has to follow the layer where recording happens. Some processes open capture devices directly under /dev/snd, while others ask a sound server such as PipeWire or PulseAudio, which runs under the logged-in user. These paths produce different telemetry, and a rule written for the first will miss the second. Process ownership is the strongest context: a capture request from a service account or from a process with no interactive session deserves more attention than the same request from a conferencing app in a desktop session. Recordings written to temporary directories or hidden folders in home directories are a second signal, but only after the team has baselined where legitimate audio tools write their files.

macOS adds a permission layer that Linux does not have. Microphone access is granted per application through the privacy framework (TCC), and each grant changes when a user approves or revokes it. Detection on macOS therefore combines what a process did with whether it held a valid grant at that moment. A capture from an unsigned binary, from a helper process with no matching grant, or from a background daemon that never prompted the user is the pattern to review first. Write locations also need local baselines, because user Library folders and temporary directories hold plenty of legitimate application data. Confirm with your endpoint tooling which unified log and file events your fleet collects before you commit to a rule.

Windows splits the decision between a privacy setting and the capture API. Microphone permissions are stored per user under the ConsentStore in the registry, and packaged and desktop applications can record through different permission paths, so a rule that checks only one location will miss the other. Parent-child process relationships help separate a conferencing client started by the user from an unexpected executable launched by a script host. Output files in %TEMP% or %APPDATA% add context, but both locations are noisy. The practical result is one rule per platform that shares a normalized field, such as the recording process and output file, plus a mapping that names its ATT&CK version. ATT&CK v18 replaced technique-page detections with detection strategies and analytics, and later releases can rename, deprecate or revoke techniques. Review the ATT&CK updates page before each mapping review.

Preventive controls that reduce T1123 exposure

Audio capture depends on a device, a permission, and a process that is allowed to use the microphone. The controls below reduce how often a malicious process can reach that combination, and they are most effective when they are set as policy and checked on endpoints rather than assumed.

Microphone permission hygiene

Most audio capture succeeds because an application already holds microphone access it does not need. Review which applications hold microphone permission on macOS and Windows, and on Linux which audio sessions and portal grants are in use. Remove grants for tools that have no business need, and require a documented justification for new ones. Ask your endpoint team to show the current list per device group, and confirm who approves changes to it.

User training on unexpected prompts

Under User Training (M1017), staff learn to treat unexpected microphone or camera prompts, unfamiliar installers and requests to grant device access as security events. This matters for T1123 because a user who approves a prompt from an unknown application can hand over the microphone without any exploit. Training should cover who to call, and it should be refreshed when your device permission model changes.

Least privilege through account management

Under User Account Management (M1018), limit who can install software, change audio device settings and grant application permissions. Standard users should not be able to add drivers or kernel audio components, and administrative accounts should be separate from daily accounts. Confirm with your identity team which groups can change privacy and audio settings through group policy or your mobile device management platform.

Endpoint audit configuration

Under Audit (M1047), configure endpoints so that process creation, file creation and access to audio device files or permission stores are logged and forwarded to your SIEM. Without these records, a capture event cannot be tied to a process or a user afterward. Check that audit policy is applied on every platform in scope, that log volume is acceptable, and that retention matches your investigation needs.

Multi-factor authentication where relevant

Under Multi-factor Authentication (M1032), require strong authentication for administrative sessions and for remote management tools that can change device permissions. This control does not stop a process already running on a logged-in endpoint from using the microphone, so treat it as a limit on how attackers gain the access needed to install or reconfigure audio capture. Ask which consoles and remote access paths are covered.

What to do when a T1123 alert fires

The first decision on a T1123 alert is whether a process is using a microphone without a business reason, and the first step is to confirm the process and the user who started it. Pull the process creation record for the parent and child processes, the executable path, the signing status and the account context from the endpoint telemetry. Then confirm the same facts on the device itself with the endpoint owner, because a logged name can be misleading. Treat an unsigned binary, a script interpreter, or a process running from a user-writable or temporary directory as a stronger signal than a familiar application name. Record the time window and the device identifier so that every later step refers to the same event.

Next, check whether the device access matches a known business application. Ask the endpoint owner which conferencing, dictation, recording or voice tools the user normally runs, whether the user was in a meeting or on a call at the time, and whether the device is managed under a standard image. Compare the process against your approved application list and against the file access and file creation records that accompany the alert. An audio file written to an unexpected location, or a capture process that has no matching window or meeting, keeps the alert open. Preserve volatile evidence before you change anything: running process list, open handles, network connections and memory where your procedures allow it, and copies of any audio or temporary files that were created. Hash what you collect and keep a chain of custody note.

Decide on containment based on the evidence you have, not on the alert severity alone. Options range from stopping the process and monitoring the account, to isolating the endpoint from the network through your endpoint management or EDR platform, to disabling the account. Escalate to incident response as soon as the process cannot be tied to a known application, when the capture coincides with suspicious logons or other alerts on the same host, or when the device handles sensitive meetings or regulated information. Document each decision in the case record with the time, the evidence reviewed, the people consulted, the action taken and the reason, including decisions to close the alert as benign. That record is what a later reviewer will test, so write it so that someone who was not on shift can reconstruct the reasoning. Confirm your escalation paths and evidence handling rules with your own legal and HR contacts before the first alert arrives.

Rehearsing T1123 detection in a private cyber range

The Linux range should mirror your production build: the same distribution family, kernel baseline, audio stack and endpoint agent version, running on isolated virtual machines or hardware in your private cyber range. Scenarios, target hosts and stop conditions are agreed in writing before any inject runs. Injects are described at the level of behavior, such as a non-audio application requesting microphone access, a process opening an audio device node outside its normal workflow, or a newly written recording file appearing in a user temporary directory. Detection logic should combine process creation, file access and file creation events, then correlate them with the parent process and user context. Good detection raises a prioritized alert in your SIEM, such as Wazuh or Security Onion, with the host, user, binary path and file path attached. Good response means the analyst can isolate the host, preserve the recording artifact and confirm whether the capture was legitimate within the agreed response time.

Range build: Confirm the audio subsystem, endpoint agent and log forwarding match production before testing.
Inject design: Plan device access and file write behaviors that mirror known benign applications so tuning is realistic.
Detection checks: Verify that process and file telemetry reach the SIEM and that a Sigma-based rule fires on the scripted event.
Response checks: Time the triage, host isolation and evidence preservation steps against the runbook.
Tuning loop: Record false positives from approved conferencing or recording tools and add documented exclusions.

Check that every alert in the exercise maps to a documented ATT&CK version and a named analytic, so results are repeatable.

Questions detection engineers ask about T1123

How do I separate legitimate voice apps from audio capture?

Start from a baseline of which processes legitimately open microphone devices on your fleet, then alert on deviations rather than on the access itself. Voice assistants, conferencing clients, dictation tools and recording utilities all touch the audio stack, so a rule that fires on any microphone access will be noisy. Useful separators include the parent process, the signing identity or publisher, the install path, and whether the process is launched by a user session or by an unexpected service account. Process Creation telemetry gives you the lineage, and a short allowlist reviewed quarterly keeps the baseline honest. Treat any unsigned binary, an interpreter spawned from an office application, or a capture tool running outside business hours as higher priority.

Is File Creation telemetry enough to detect audio capture?

No. File Creation is useful for spotting where captured audio is written, but it is a late signal because the recording may already exist before the file appears. Pair it with Process Creation to see which process started the capture and with File Access to see who reads the output afterward. Captured audio is often written to temporary directories or compressed on the fly, so include those paths and common audio file extensions in your review, and confirm with your own endpoint team which paths are normal for your applications. Treat File Creation as one leg of a chain, not as the detection on its own.

How do I reduce false positives from conferencing software?

Conferencing applications are the most common source of noise, so tune them deliberately rather than suppressing the whole rule. Build exceptions keyed to the vendor's signed binary, the expected install location and the parent process, and review them whenever the application updates. Keep the exception narrow: a conferencing binary writing audio to an unfamiliar directory, or running from a user-writable path, should still alert. Track the false positive rate in your own environment for a defined period and record each exception with an owner and a review date. Ask your endpoint vendor and the conferencing vendor to confirm their executable names and signing details before you write the rule.

How often should I retest T1123 detection rules?

Retest on a defined schedule and after every material change, including operating system updates, endpoint agent upgrades, new conferencing or voice software, and changes to your telemetry pipeline. A detection can break silently when a log source stops forwarding or a field is renamed, so include a check that confirms the expected events still arrive. Many teams run a small set of replayable test cases on a recurring cadence and after each rule change. Set the cadence with your detection engineering lead and document it in your change process, since the right frequency depends on how often your fleet and tooling change.

How do I map T1123 findings to ATT&CK 20.0?

Record the technique ID, the sub-technique if one applies, and the ATT&CK version your rule targets in every rule's metadata, so future readers know which version the mapping reflects. ATT&CK 20.0 was released on 2026-10-13, and releases can rename, deprecate or revoke techniques, so re-check the mapping when you move to a newer version. Use the STIX 2.1 bundle for the Enterprise domain in the attack-stix-data repository to confirm current names and data component references programmatically. Map each detection to the data components it uses, such as Process Creation or File Access, and to the mitigations you have implemented, so auditors can trace coverage from rule to technique.

Can my own team run T1123 detection exercises without outside help?

Yes, many teams can, provided they have a test environment that mirrors production telemetry and a clear rule-of-engagement for the exercise. The main requirement is an isolated lab where you can generate benign audio activity from known tools and confirm that your Process Creation, File Access and File Creation events arrive and match your rules. Outside help is useful when you need an independent review of coverage, a range built to repeat exercises consistently, or help writing and validating rules across Linux, macOS and Windows. DeployOpen can scope that work in writing, and the written scope sets the deliverables and timeline before work begins.

What should a T1123 alert trigger in my response process?

Define the triage steps before the alert fires: confirm the process lineage, check whether the user and device are expected to use audio, and determine whether captured data was written, read or transmitted. Escalate quickly when an unexpected process holds the microphone for a long period, when output files appear in unusual locations, or when network activity follows the capture. Preserve the relevant endpoint evidence before making changes, and record the decision path so the incident can be reviewed later. Test this playbook in the same cyber range exercises you use for detection, so responders know the steps under pressure.

How DeployOpen builds T1123 detections and range scenarios

DeployOpen treats T1123 Audio capture as a scoped engineering task inside your own environment. We agree what is covered in writing, build and test detections on the telemetry you actually collect, then document and hand over the results for your team to run.

How we scope

Confirm which Linux, macOS and Windows endpoints and identities fall inside the T1123 detection scope
Inventory which audio-related process, file and device telemetry your current logging already captures
Agree in writing which ATT&CK version the detection mappings will target before any rule work starts
Record which response actions and owners are in scope, and which remain with your security operations team

How we build

Map candidate detections to the Process Creation, File Access and File Creation data components for audio capture behavior
Write detection logic in open-source formats such as Sigma and deploy it to your existing SIEM or Wazuh stack
Tune rules against benign audio applications such as conferencing and recording tools to reduce noise in your environment
Build cyber range scenarios that replay the agreed behaviors in an isolated copy of your endpoint build

How we hand over

Deliver a detection record per rule with its data sources, logic description, known false positives and test evidence
Provide range exercise runbooks so your analysts can repeat validation after each rule change
Document response steps and escalation paths that match your existing incident handling process
Walk your team through the handover and confirm ownership of each rule, dashboard and test

How we support

Confirm whether ongoing rule tuning, ATT&CK version updates and re-testing are needed after handover
Offer ongoing support, upgrades and continuous testing as a retainer if your team wants it
Agree retainer scope, review cadence and response expectations in writing alongside the original scope
Ask for a written quote based on the agreed scope, since DeployOpen does not publish a price list

T1123 Audio capture