Module 0.4: Unified Logging for Detection and Hunting

The Endpoint Security framework is powerful, but it has a critical limitation we covered in Module 0.3: it requires a special Apple entitlement, and most detection engineers interact with it only through their EDR product. Unified Logging is different. It is available on every Mac, requires no special entitlement, and produces a constant stream of structured security relevant events. If ES is your primary detection source, Unified Logging is your most important backup.

This module teaches you how Unified Logging works, which subsystems produce detection relevant events, how to query the log in real time and historically, and how to combine unified log data with ES events to build detections that neither source could produce alone.

What Unified Logging Is

macOS Unified Logging is the native logging system introduced in macOS 10.12 (Sierra). It replaced the older Apple System Logger (ASL) and the traditional syslog daemon. Unified Logging collects log messages from every part of the operating system: the kernel, system daemons, user applications, frameworks, and drivers. All of these messages flow into a single, centralized logging infrastructure.

The key properties of Unified Logging for detection engineers:

Always on. Unified Logging runs on every Mac by default. There is nothing to install, no entitlement to obtain, and no vendor relationship required. If you have a Mac, you have Unified Logging.

Structured. Log messages include metadata: the subsystem that produced them, the category within that subsystem, the process name and PID, the timestamp, and the message text. This structure makes it possible to filter and query precisely.

Tiered. Unified Logging has three log levels with different retention and storage behavior. The default level captures most operational events. The info level captures more detail but has shorter retention. The debug level captures everything but is typically only enabled during troubleshooting. Understanding these tiers is important because a message you expect to see might not be retained if it was logged at info or debug level.

Historically queryable. The log command can stream events in real time (log stream) or search historical events (log show). You can go back hours or days, depending on the retention settings and the log level.

Querying the Unified Log

The primary tool for working with Unified Logging is the log command line utility. Let us cover the two most important commands for detection engineers.

Streaming live events:

log stream --predicate 'subsystem == "com.apple.securityd"' --level info

This streams events from the security daemon subsystem in real time. The --predicate flag uses NSPredicate syntax to filter events. You can filter by subsystem, category, process, message content, and more.

Searching historical events:

log show --predicate 'subsystem == "com.apple.sandbox"' --last 1h

This shows events from the sandbox subsystem from the last hour. You can specify different time ranges: --last 5m for five minutes, --last 2h for two hours, --start and --end for precise ranges.

The predicate syntax is powerful. Here are common patterns for detection:

# Find sandbox denials
log show --predicate 'subsystem == "com.apple.sandbox" AND messageType == 1' --last 1h

# Find Gatekeeper evaluation failures
log show --predicate 'subsystem == "com.apple.gkeval"' --last 1h

# Find TCC prompt events
log show --predicate 'subsystem == "com.apple.TCC"' --last 1h

Learning the predicate syntax is a core skill for macOS detection engineers. Spend time with log show --help and experiment with different predicates against your own system.

Security Relevant Subsystems

Not all log messages are useful for detection. The unified log contains an enormous volume of operational noise. The skill is knowing which subsystems produce security relevant events. Here are the most important ones:

com.apple.securityd. The security daemon handles Keychain operations, code signing validation, and secure enclave interactions. Events from this subsystem can reveal credential access attempts and signing anomalies.

com.apple.sandbox. The sandbox subsystem logs every access denial. When a sandboxed application tries to access something it is not allowed to, the denial is logged here. A spike in sandbox denials from a process can indicate an attacker probing the sandbox boundary.

com.apple.gkeval. Gatekeeper evaluation. This subsystem logs the result of every Gatekeeper check: whether a binary was allowed, blocked, or prompted. Failed evaluations or unexpected evaluations are worth monitoring.

com.apple.TCC. The TCC subsystem logs consent prompt events. You can see when an application requests access to protected resources like the camera, microphone, or full disk contents. A TCC prompt from an unexpected application is suspicious.

com.apple.mdm. The Mobile Device Management subsystem logs MDM commands and profile installations. Unexpected profile installation events can indicate an attacker using a configuration profile for persistence.

Combining Unified Logging With ES

The real power of Unified Logging emerges when you combine it with ES events. ES tells you what happened at the system call level. Unified Logging tells you what the security subsystems thought about it. Together, they tell the complete story.

Consider an example. An attacker delivers a malicious application and the user opens it. Here is what each telemetry source sees:

ES sees: A process exec event. The binary at /Applications/Malware.app/Contents/MacOS/malware executed. The parent process was Finder. The signing identity is an ad hoc signature with no team ID.

Unified Logging sees: Gatekeeper evaluated the application and allowed it because the user clicked through the warning (or because the binary was notarized). The sandbox denied the application's first attempt to access ~/Library/Keychains/. AMFI logged a library validation warning when the application tried to load an unsigned dylib.

ES alone tells you the process ran. Unified Logging alone tells you the security subsystems reacted to it. Combined, you have the full picture: the process ran, what it tried to access, what was denied, and what was allowed. That combined picture is what lets you build a precise detection with low false positive rates.

In Phase 1 through Phase 8, every detection module identifies both the ES event and the unified log events that correspond to the technique. This dual source approach is a hallmark of professional macOS detection engineering.

Limitations of Unified Logging

Unified Logging is powerful but it is not a silver bullet. You need to understand its limitations to use it effectively.

Retention limits. The default level logs are retained for a few days. Info level logs are retained for a shorter period. Debug level logs are almost never retained after a reboot. If you need long term log retention for detection or investigation, you must configure a log collection pipeline that exports events to a SIEM before they expire.

Performance impact. Querying the unified log heavily, especially with broad predicates over long time ranges, can impact system performance. In a production environment, you should run log collection agents that stream events to a remote SIEM rather than querying the local log repeatedly.

No structured event IDs. Unlike Windows Event Log, which has well known event IDs for security events, Unified Logging messages are identified by subsystem, category, and message text. There is no standardized event ID system. This means your detections must match on message content and patterns, which is more fragile than matching on event IDs. Message formats can change between macOS versions.

Privacy redaction. Apple redacts certain log messages for privacy. User names, file paths, and other potentially sensitive data may be replaced with <private> in the log output. This redaction can make it harder to build detections that rely on specific path or user information. You can disable redaction on your own lab machine using log config --mode private_data:on, but in production environments this is often not feasible.

What Comes Next

Module 0.5 covers the remaining telemetry sources: file system artifacts, process metadata, network connection data, and identity information. These are not single frameworks like ES or Unified Logging. They are collections of system state that you can query during detection and hunting. Together with ES and Unified Logging, they complete your telemetry picture. com.apple.launchd. The launch daemon subsystem logs service registration and launch events. This can reveal new persistent services being installed.

com.apple.amfi. Apple Mobile File Integrity. This subsystem logs code signing validation failures and library validation checks. AMFI denials can indicate unsigned code loading attempts.

There are dozens more subsystems. Part of becoming a proficient macOS detection engineer is learning which subsystems matter for the specific techniques you are trying to detect. Each module in later phases points you to the specific subsystems relevant to that technique.