Unified Logging Manipulation

The unified logging system (os_log, queried with log show/log stream) replaced legacy syslog as the primary event record on macOS, storing structured, indexed entries in a partly binary, rotated backing store under /var/db/diagnostics. Unlike a flat text log an attacker can simply truncate, unified logging is deliberately hard to tamper with after the fact: entries are written continuously across the system by many processes, storage is rotated and pruned automatically, and the format isn't a single editable file. That pushes attackers toward evasion rather than deletion — writing malware that itself never calls os_log (so its actions leave no first-party trace to begin with), disabling logging for a specific subsystem where an unprivileged or lightly-privileged toggle exists, or aggressively forcing local log rotation/pruning where permissions do allow it, to shrink the window an investigator can look back through.

How it works

Malware authors typically just omit os_log/os_signpost calls from their own code entirely, since nothing forces a process to log its own behavior — the technique here is an absence, not an API call. Where a subsystem-level toggle is reachable, logging for a specific subsystem/category can be suppressed:

log config --mode "level:off" --subsystem com.apple.securityd

Aggressive local pruning shortens the retrospective window without an obvious single "clear logs" event:

log erase --all

Both commands require elevated privilege to affect system-wide configuration, so this technique is most relevant post-compromise, as a step to reduce the evidence available to incident responders rather than a stealth mechanism used during initial execution.

Detection & analysis

Static analysis:

• A binary invoking log config/log erase, or calling the underlying OSLog/ASL configuration APIs to disable a subsystem, has no legitimate reason to for ordinary software — treat it as a strong anti-forensic signal on its own.

Dynamic analysis:

• Monitor process execution for log erase and log config --mode "level:off" invocations, and for direct manipulation of files under /var/db/diagnostics or /Library/Preferences/Logging outside normal log rotation by the OS itself.
• Because local evasion can't retroactively affect logs already forwarded off the host, the most reliable detection is architectural: ship unified log events to a remote collector continuously, so a gap or a sudden absence of expected event categories in the shipped stream is itself the alert, independent of what happens to the local copy afterward.

Detection rule hint:

Alert on execution of log erase/log config --mode "level:off" by any non-administrative process, and separately alert on a sustained absence of expected os_log event categories (e.g. security or endpoint-relevant subsystems suddenly going silent) in centrally forwarded logs from a host that was previously producing them normally.