Reduce the risk by limiting access to system logs, forwarding logs to a separate protected store, and alerting on log clearing or tampering. On Linux and macOS, preserve audit and security logs off-host where possible, because attackers often erase local records after compromise to hide execution, privilege changes, and lateral movement.
How to reduce log erasure risk on Linux and macOS
The practical answer is to make local logs harder to reach, harder to alter, and less important as the only source of truth. That usually means tightening log file permissions, separating administrative access from routine access, and ensuring the system forwards logs to a protected destination before an attacker can delete them on the host.
On both Linux and macOS, local logs are strongest as near-real-time telemetry, not as your only forensic record. If an attacker gains sufficient privilege, they can often clear or manipulate files, disable collection, or target the logging service itself. Off-host retention gives you a second copy that survives the same compromise path, which is why MITRE ATT&CK Guide for Defenders is useful for mapping the behaviors you want to detect, including log clearing and adjacent cover-up techniques.
Detection should focus on the act of tampering, not just on missing records after the fact. Alerting on log truncation, deletion, service changes, audit policy changes, and suspicious privilege escalation helps you catch the compromise while the attacker is still trying to hide it. For Windows teams, the same operational logic is covered in the Windows Event Log Guide, but the defensive pattern applies equally here: preserve the record elsewhere and watch the control plane that produces it.
What should be protected first in the logging path?
The highest-value controls are the ones that prevent an attacker from simply using the compromised host as the only place where evidence exists. Protect the logging daemon, protect the storage path, and protect the administrative accounts that can disable or rewrite logging. Where possible, separate collection from the endpoint so a local root compromise does not automatically erase every copy.
That usually means treating logs as security evidence, not operational clutter. If the host can still write events locally, but cannot overwrite or delete the forwarded copy, you have materially reduced the attacker’s ability to hide execution, privilege changes, and lateral movement. Limiting access to the log path also reduces accidental loss, which matters because many log-clearing events are operational shortcuts until they become incident-response blind spots.
For teams building broader detection coverage, the same behavior-based view fits the ATT&CK model and helps align detection engineering with adversary tradecraft rather than with single-platform log formats. If your environment includes cloud consoles, privileged access tools, or identity systems, the Okta Security Hardening Guide is a useful example of how system logs, configuration drift, and recovery controls work together when logs themselves are part of the attack surface.
How do you keep logs useful after a compromise?
Logs remain useful only if they survive long enough to answer the questions incident responders will ask: what executed, which account changed privilege, which session was used, and what was touched laterally. Forwarding logs to a separate protected store, preserving audit logs off-host, and retaining enough context around authentication and administrative actions are the difference between a contained investigation and guesswork.
The off-host copy should be protected with stricter access than the source system, because attackers often target the easiest path first. If your retention tier is writable by the same admin identity that controls the endpoint, your logging design still has a single point of failure. The objective is not just retention, but retention that remains trustworthy when the endpoint is no longer trustworthy.
When you need a baseline for broader control mapping, CISA’s advisory and threat guidance is a good operational reference point for prioritising defensive work around active abuse patterns, including log tampering and post-compromise cleanup. See CISA cyber threat advisories for current guidance on threat-driven hardening and response priorities.
Risk and Threat Considerations
Log clearing is a classic concealment move because it reduces visibility into how the attacker got in and what they did next. The main risk is not the deletion itself, but the loss of evidence for privilege escalation, persistence, and lateral movement, which can delay containment and widen impact.
Failure mechanism: An attacker with sufficient local or administrative access clears or tampers with host logs, disables collection, or targets the logging service before responders can retrieve evidence from the endpoint.
Impact: Incident responders lose the timeline needed to confirm initial access, scope compromise accurately, and reconstruct account or system changes, which increases dwell time and raises the chance of missed persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070 — Indicator Removal on Host | Covers log clearing and tampering as attacker concealment behavior. |
| Recommendation — Map host log clearing to T1070 and alert on evidence-removal behavior. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Directly addresses collecting, protecting and reviewing logs for security monitoring. |
| Recommendation — Centralize and protect audit logs so endpoints cannot erase the only copy. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Requires audit records to be protected from unauthorized access and modification. |
| AU-6 — Audit Review, Analysis, and Reporting | Supports alerting and review of suspicious log changes or clearing events. | |
| AU-11 — Audit Record Retention | Supports preserving logs long enough for investigation after compromise. | |
| Recommendation — Restrict audit log access so only approved roles can read or alter records. Review audit events for log clearing, service changes and tampering indicators. Retain audit records off-host long enough to support incident reconstruction. | ||
Practitioner Guidance
What to verify: Confirm that log forwarding is working continuously, that the protected destination is outside the attacker’s normal host-admin path, and that audit events for log clearing or service modification are themselves retained. If any of those three fail, you still have a single point of failure.
What to prioritise: Prioritise off-host retention for security and audit logs before fine-tuning retention periods or dashboards. A short, protected trail is more valuable than a long local trail that disappears with the box.
Practitioner takeaway: Treat local logs as evidence-in-transit, not evidence-at-rest, because the moment an attacker gains control of the host, the most important logs are the ones they can no longer erase.