40% off with code HYPERLAUNCH

Claim offer
HyperMonitor
ListeningGuide 02 of 04

What is listening on my Mac?

“Listening” means two different things on a Mac: an app using your microphone, or an app waiting for network connections. This guide covers both, starting with the microphone.

4 min read3 commands

Question 01

Is something listening through my Mac’s microphone?

When an app is using the microphone, recent versions of macOS show an orange dot in the menu bar, next to the Control Centre icon. A green dot, and the green light beside the built-in camera, mean the camera is in use. To see which app it is, open Control Centre: the top of it names the app that is using the microphone or used it recently. If you don’t recognise the app, quit it, then open System Settings › Privacy & Security › Microphone. That list shows every app that has asked for microphone access, and you can turn access off for any of them; the app has to ask again before it can use the microphone. Video calls, dictation, Siri and voice memos are the usual reasons for the dot. HyperMonitor doesn’t monitor the microphone; macOS already tracks it, and the indicator and the privacy settings are the right tools for it.

Question 02

What does “listening” mean for network ports?

In networking, a process is listening when it has opened a port and is waiting for other software to connect to it. Most Macs have several listeners at any time, and most of them are normal. mDNSResponder handles Bonjour, which is how your Mac finds printers, speakers and other Macs, on UDP port 5353. On recent macOS versions, ControlCenter listens on ports 5000 and 7000 when AirPlay Receiver is on. Developer tools add their own: a web server on 3000 or 8000, Postgres on 5432, Docker’s engine API on 2375 if it is exposed, or Node’s debugger on 9229. The important detail is where a listener is bound. A port on 127.0.0.1 only accepts connections from this Mac. A port on * or 0.0.0.0 accepts them from any device that can reach your Mac over the network, which is worth knowing on shared or public Wi-Fi.

Question 03

How do I list every app that’s listening on the network?

The quickest built-in way is Terminal. Run sudo lsof -iTCP -sTCP:LISTEN -n -P for TCP listeners and sudo lsof -iUDP -n -P for UDP sockets. Each line shows the command name, its process ID (PID), the user it runs as and the address and port it is bound to. The sudo matters: without it, macOS hides sockets that belong to root and other system users, so you would miss many of the services that start before you log in. To learn more about a PID, run ps -p 1234 -o pid,user,command to see the full command line, or find the process in Activity Monitor by its PID. Activity Monitor can also show the ports for one process: select it, click the Info button and open the Open Files and Ports tab. It has no single view of every listener at once, so lsof is the better starting point.

Terminal — zsh
# TCP listenerssudo lsof -iTCP -sTCP:LISTEN -n -P# UDP socketssudo lsof -iUDP -n -P

Question 04

Which listeners should I worry about?

Start with the ones that are reachable from the network, meaning bound to * or 0.0.0.0, and that you can’t explain. Then look at where the executable lives: apps normally run from /Applications, /System or a developer tool’s folder, while something running from Downloads, /tmp or a hidden folder deserves a closer look. Check who signed it with codesign -dv --verbose=4 followed by the path. Apple’s own processes are signed by Apple, most third-party apps carry a Developer ID with a team name, and “code object is not signed at all” means nobody vouches for it. A recently installed launch agent that starts the same program at every login is another signal. None of these prove anything on their own; plenty of developer tools are ad-hoc signed and listen on all interfaces. If you can’t tie a listener to something you installed, quit it, find what launches it, and look it up before deleting files.

Terminal — zsh
# Who signed an executable?codesign -dv --verbose=4 /path/to/executable