Shazam for Mac keeps mic recording when 'off'
Reverse-engineering of Shazam's macOS app found it continues recording from the internal microphone even after the user toggles it 'OFF', though it doesn't appear to process or exfiltrate the audio.
Sourceobjective-see.org — open the original
What to check
- Applies to
- Whether this concerns you is not assessed; the names the report mentions are listed below.
- Date
- The source gives no publication date; the date shown is the day Vorant added the brief.
A researcher reversed the Shazam macOS application after a user reported that OverSight (a tool that alerts on webcam/mic access) never showed a 'Mic Deactivation' event when Shazam was toggled off. Deep analysis of the Objective-C code and ShazamSDK.framework revealed that toggling the app to 'OFF' only stops the app from processing captured audio (via a 'generating' flag) rather than actually halting the low-level AudioOutputUnitStop() call that would stop the microphone stream. The 'taggingType' value is hard-coded such that the condition needed to trigger 'stopRecording' is never satisfied, meaning the mic remains active and recording continues in the background regardless of the UI toggle state.
The researcher found no evidence that this recorded audio is saved, processed, or exfiltrated when the app is in the 'OFF' state — the flaw appears to be an oversight rather than intentional spying. However, the behavior is concerning from a privacy standpoint, as it means malware or a compromised process could potentially piggyback on this always-on recording state without triggering typical mic-activation alerts. The researcher contacted Shazam prior to publication; the vendor confirmed the technical findings and indicated a fix would be addressed in a future update.
This is a privacy/behavioral disclosure rather than an active exploit or malware campaign — no IOCs, threat actors, or active exploitation are involved. It serves as a case study in how legitimate apps can inadvertently retain sensitive hardware access beyond user-intended controls, and highlights the value of tools like OverSight for auditing mic/camera usage on macOS.
Detection guidance
Disabled Audio App Maintaining Hardware Capture Stream
A behavioural hunt for the technique in general.
Detects sustained microphone hardware stream activity (no Audio Unit stop call) from audio apps when their recording feature is user-disabled, suggesting circumvention of intended privacy controls. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Disabled Audio App Maintaining Hardware Capture Stream
description: Monitors for the pattern where audio capture applications have a disabled
or OFF recording state (detectable via hardened runtime or sandbox telemetry) but
the underlying Audio Unit session remains open and active without corresponding
stop/teardown syscalls. This reflects apps that suppress output/processing but not
input stream termination.
tags:
- attack.t1123
logsource:
category: process_creation
product: macos
detection:
selection_parent:
Image|endswith: /Shazam.app/Contents/MacOS/Shazam
CommandLine|contains:
- AudioSession
- AVAudioEngine
selection_sustained_access:
ParentImage|endswith: /Shazam.app/Contents/MacOS/Shazam
Image|endswith:
- /usr/libexec/coreaudiod
CommandLine|contains: record
filter_normal_lifecycle:
CommandLine|contains:
- stop
- shutdown
- disable
condition: (selection_parent or selection_sustained_access) and not filter_normal_lifecycle
falsepositives:
- Rapid toggle-on-toggle-off sequences by users re-enabling recording immediately
- Audio framework housekeeping maintaining device connections across brief state changes
level: low
id: 04210110-5c15-57ba-89fb-ba7de61dc2fd
status: experimental
author: Vorant
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://objective-see.org/blog/blog_0x13.html
Free public brief. The detections with Splunk SPL already written (plus Elastic and KQL where they apply) are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply). The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,436 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs