Module 0.5: File System, Process, Network, and Identity Telemetry

ES and Unified Logging are event streams. They tell you what is happening right now. But macOS also produces a wealth of state based telemetry: artifacts that persist on disk, process metadata you can query at any time, network state you can inspect, and identity databases you can audit. These sources do not stream events. They sit there waiting for you to query them.

This module maps the four major state telemetry categories on macOS and shows you what each one contains, how to access it, and how to use it in detections and hunts. By the end you will understand the full telemetry landscape, both streaming and state based, that you have available for macOS detection engineering.

File System Telemetry

The file system is the most important state telemetry source on macOS. Almost every action an attacker takes leaves a file somewhere. Persistence mechanisms are almost always files. Downloaded payloads are files. Collected data is staged in files. The file system is a forensic record of activity, and a skilled detection engineer knows where to look.

The Persistence File System Map

Let us walk through the file system locations that matter most for detection. These are the directories where attackers plant persistence, stage data, and leave artifacts. We reference this map throughout Phase 1 and Phase 9.

System level persistence locations:

• /Library/LaunchDaemons/ - system level LaunchDaemon plists
• /Library/LaunchAgents/ - system level LaunchAgent plists (run for all users)
• /Library/StartupItems/ - legacy startup items (mostly deprecated but still functional)
• /Library/Application Support/ - application support directories (TCC database lives here)
• /Library/Preferences/ - system preferences including login window configuration

User level persistence locations:

• ~/Library/LaunchAgents/ - user level LaunchAgent plists (run for the current user)
• ~/Library/Preferences/ - user preferences including login items
• ~/Library/Application Support/ - per application data, including browser profiles and extensions
• ~/Library/Containers/ - sandboxed application containers
• ~/.zshrc, ~/.bashrc, ~/.bash_profile - shell startup scripts

Temporary and staging locations:

• /tmp/ and /var/tmp/ - world writable temporary directories
• ~/Downloads/ - files downloaded by the user
• /private/var/db/ - system databases
• /private/var/log/ - legacy log files

A detection engineer builds baselines of these directories. You inventory what normally lives in each location on a clean system, then alert on new additions. This is the core of persistence detection, which we cover in Phase 1.

Extended Attributes

macOS files carry extended attributes, which are metadata stored alongside the file data. The most security relevant extended attribute is com.apple.quarantine, which Gatekeeper uses to track files downloaded from the internet. But there are others:

xattr -l /path/to/file

This lists all extended attributes on a file. You will see attributes like com.apple.quarantine (downloaded files), com.apple.provenance (App Store origin tracking), and com.apple.metadata:kMDItemWhereFroms (download source URL). These attributes are forensic gold during investigations. An attacker who downloads a payload and then strips the quarantine attribute to hide its origin will leave a trace: the file exists but has no quarantine attribute, which is unusual for a recently downloaded file.

File System Events (FSEvents)

macOS records file system changes in a database called FSEvents. FSEvents tracks directory level changes and is used by Spotlight and Time Machine. For detection, FSEvents is useful for historical reconstruction. If you need to know what directories changed in the last 24 hours, FSEvents has the record, even if the files themselves were deleted.

You can query FSEvents using tools like fseventer (third party) or by reading the FSEvents log files in /private/var/db/fseventsd/. This is more of a forensic technique than a real time detection, but it is valuable for post incident investigation.

Process Telemetry

Process telemetry is the metadata about running and recently run processes. ES gives you process events in real time, but there is additional state you can query at any time.

The Process List

The ps command shows running processes. For detection, the full command with all arguments is most useful:

ps auxww

The ww flag tells ps not to truncate command line arguments, which is essential for seeing the full picture. A process running with suspicious arguments (like a reverse shell command with an IP address and port) will be visible here.

Process Ancestry

Every process on macOS has a parent process that created it. The parent-child relationship is a powerful detection signal. Normal applications have predictable ancestors: GUI apps are children of launchd, terminal applications are children of Terminal or iTerm, and so on. Anomalous ancestry is suspicious.

For example, if a word processor spawns a shell, that is anomalous. If a system daemon spawns a Python interpreter, that is anomalous. These parent-child relationships are the foundation of behavioral detections. We build several ancestry based detections in Phase 2.

The lsof Command

The lsof command lists open files for running processes. This includes network connections (which are represented as file descriptors), memory mapped files, and regular open files. For detection, lsof is useful for identifying processes that have suspicious network connections or are accessing sensitive files:

lsof -i -nP

This shows all processes with network connections, without resolving hostnames or port names. An unexpected outbound connection from a process that should not have network access is worth investigating.

Network Telemetry

macOS network telemetry tells you which processes are talking to the network and where they are sending data. An important architectural detail: the Endpoint Security framework does not provide TCP or network socket connection events. ES covers Unix domain IPC sockets (UIPC_BIND, UIPC_CONNECT) but not TCP/IP connections. This means network visibility requires alternative sources beyond ES.

The Network Connection Table

The netstat command shows active network connections:

netstat -anp tcp

This lists all active TCP connections. For detection, you are looking for connections to unusual destinations. Outbound connections to known bad IP addresses, connections on non standard ports, and connections from processes that should not be making network calls are all suspicious.

The pf Firewall Log

macOS includes the Packet Filter (pf) firewall. When enabled with logging, pf records connection attempts. The pf log lives at /var/log/pf.log and can be queried with tcpdump:

sudo tcpdump -nn -e -r /var/log/pf.log

This is most useful in environments where pf is configured with explicit allow and deny rules. Connection attempts that hit deny rules are logged and can indicate reconnaissance or C2 attempts.

DNS Resolution

DNS queries are a telemetry source that many detection engineers overlook. When a process resolves a domain name, the resolution can be observed. Malware C2 domains, data exfiltration via DNS tunneling, and command and control via domain fronting all generate DNS traffic. On macOS, DNS resolution goes through mDNSResponder, and you can monitor its activity:

log stream --predicate 'process == "mDNSResponder"' --info

This streams DNS resolution events in real time. A detection engineer can build rules that flag DNS resolutions to known malicious domains, newly registered domains, or domains with suspicious characteristics (high entropy names, domains that look like DGA output).

Identity Telemetry

Identity telemetry is the metadata about users, groups, and authentication state on the system. Attackers interact with identity when they escalate privileges, create new accounts, modify group memberships, and steal credentials.

User and Group Databases

The traditional Unix user and group databases exist on macOS and are queryable:

dscl . list /Users UniqueID
dscl . list /Groups GroupMembership

The dscl command queries the Directory Service, which is macOS's unified identity store. You can enumerate all users, their UIDs, their group memberships, and their home directories. A new user account that appeared unexpectedly, or an existing user added to the admin group, are both detection signals.

Authentication Logs

macOS records authentication events in the unified log under the com.apple.Authorization subsystem and the com.apple.securityd subsystem. Successful and failed sudo attempts, authorization right evaluations, and login window events appear here.

For detection, a spike in failed sudo attempts can indicate password guessing. A successful sudo from an unexpected user or at an unexpected time can indicate privilege escalation. We cover authentication detection in Phase 4.

The Authorization Database

macOS has an authorization database that defines which rights exist and who can exercise them. Modern macOS stores this in two locations: a static template at /System/Library/Security/authorization.plist and a live runtime database at /var/db/auth.db. The runtime database is a SQLite file that the system consults at authorization time. You can inspect rights through the security authorizationdb read <right_name> command. An attacker who modifies the authorization database can grant themselves rights they should not have. Monitoring this database for changes is a detection task for high security environments.

The Complete Telemetry Picture

Let us assemble everything from Modules 0.3, 0.4, and 0.5 into a single picture. On a macOS endpoint, you have access to:

No single source tells the whole story. Professional detection engineering combines these sources. ES tells you a process executed. Unified Logging tells you the sandbox denied its first file access. The file system shows a new LaunchAgent plist appeared. The process list shows the process is still running. The network table shows it has an outbound connection. Put together, these sources build an evidence chain that catches the attacker at multiple points.

What Comes Next

Module 0.6 covers evidence quality: how to distinguish signal from noise, how to think about confidence levels, and how to communicate detection limits to stakeholders. Not every telemetry signal is a real threat, and being able to reason about false positives and detection confidence is what separates a detection engineer from a rule writer.