AN0620: Analytic 0620
Processes accessing ALSA/PulseAudio devices or executing audio capture binaries like 'arecord', followed by file creation or suspicious child process spawning.
Analyst context for executives and security teams
This analytic matters because unexpected audio capture on Linux systems can indicate misuse of workstation or server-attached microphones and may create privacy, regulatory, or operational security concerns. The practical value is not just detecting a tool name like `arecord`, but confirming whether the organization can see processes touching ALSA or PulseAudio devices and then creating files or spawning suspicious child processes.
Executive priority
Security leaders should treat this as a coverage validation item for Linux endpoint monitoring, especially in environments where audio-capable systems handle sensitive meetings, regulated data, or operational processes. The priority question is whether SOC and IR teams have enough Linux process, device-access, and file-creation telemetry to prove or disprove unauthorized audio capture during an investigation.
Technical view
For Linux systems, validate visibility into processes accessing ALSA or PulseAudio devices, execution of audio capture binaries such as `arecord`, related file creation, and unusual child process spawning after audio-device access. Because ATT&CK does not provide a detection body or tactic for this analytic, teams should treat AN0620 as a behavioral detection concept and tune it against local baselines for legitimate conferencing, recording, testing, and accessibility software.
Likely telemetry
- Linux process execution events, including command line where available
- Process ancestry and child process creation telemetry
- File creation events following audio capture activity
- Access to ALSA or PulseAudio audio devices
- Endpoint audit or EDR telemetry capable of correlating process, device, and file activity
Detection direction
- Confirm whether Linux monitoring records audio-device access, not only process names.
- Alerting should not rely solely on `arecord`; include broader ALSA/PulseAudio access followed by file creation or suspicious child process behavior.
- Baseline legitimate audio applications to reduce false positives from conferencing, recording, testing, or accessibility use cases.
- Correlate device access with process ancestry and output file creation to improve confidence.
- Document blind spots on unmanaged Linux endpoints, minimal server builds, containers, or systems without endpoint telemetry.
Mitigation priorities
- Inventory Linux systems where microphone or audio capture capability is present and business-relevant.
- Limit audio device access to authorized users and applications where operationally feasible.
- Apply least privilege and endpoint hardening controls to reduce unnecessary interactive or recording capability.
- Use application control or approved software policies where appropriate for sensitive systems.
- Ensure incident response playbooks include collection of process history, file artifacts, and device-access evidence for suspected audio capture.
Analyst notes and limits
AN0620 is a detection analytic object for Linux describing processes accessing ALSA/PulseAudio devices or executing audio capture binaries like `arecord`, followed by file creation or suspicious child process spawning. No tactic, relationships, aliases, labels, or official detection logic were supplied, so implementation should be driven by local telemetry availability and environment-specific baselines.
The supplied ATT&CK fields are sparse: official detection is not provided, tactics are not specified, and no relationship context is supplied. This take does not assert active exploitation, attribution, business impact, or guaranteed detection coverage.
Analytic 0620
Processes accessing ALSA/PulseAudio devices or executing audio capture binaries like 'arecord', followed by file creation or suspicious child process spawning.
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.0 | Current bundle | 3ba4dff3a069… |
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 AN0620Open 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.