Detect auditd and logging configuration changes by monitoring edits to audit rules, service state changes, and modifications to log collection or rotation settings. Alert when logging is stopped, rules are removed, or destinations are redirected. Correlate the change with administrative sessions and package activity, since attackers often weaken logging before further execution or data theft.
What to watch in the audit trail when logging is being weakened
Configuration tampering usually shows up before the final outage in evidence quality. Look for edits to audit rule files, changes to the audit daemon state, and modifications to syslog, journald, rsyslog, or logrotate settings that reduce what gets collected or where it is sent. Those changes matter most when they are made from interactive admin sessions or alongside package activity.
On Linux, the practical issue is not just that logging changes happened, but that they often remove the very telemetry needed to explain later actions. A useful detection program watches for rule deletion, service stops or disables, destination redirection, and sudden drops in event volume or log forwarding continuity. The most reliable alerts combine file integrity style monitoring with process and service state observations.
When the change path is visible, preserve the before-and-after configuration and the command context. That lets you separate a legitimate maintenance window from an attempt to blind defenders. In practice, the strongest signal is a configuration change that decreases audit coverage for authentication, privilege, execution, or file modification activity.
How to detect the change with high confidence
A good detector correlates several layers instead of relying on one file watch. Monitor the relevant configuration directories and service unit state, then compare those events with recent command execution, package installs, and changes to scheduled tasks or startup scripts. If an attacker tries to suppress auditd, the change often lands in the same time window as privilege escalation or log cleanup.
Alerting should distinguish between normal tuning and suspicious reduction. For example, adding a rule to reduce noise is different from removing collection paths, disabling forwarding, or pointing logs to a local sink that is not monitored. The latter are strong indicators because they create a visibility gap that makes follow-on activity harder to detect.
The Linux Detection and Response Guide is a useful companion when you need to extend these checks into broader host telemetry, rootkit hunting, and Linux incident response.
What to do after you detect a logging change
Do not stop at reverting the configuration. First determine whether the change was used to hide earlier access, because defenders often discover the tampering only after the adversary has already executed additional commands, staged tooling, or moved data. If the host is still active, isolate the system or at least preserve volatile evidence before making broad repairs.
Then verify whether logging was interrupted long enough to create a blind spot. If so, use adjacent sources such as authentication logs, package manager records, shell history, central log collectors, EDR, or network telemetry to rebuild the missing timeline. The key question is whether the attacker had enough time to operate without leaving durable local evidence.
The most useful external reference for organizing that response is the NIST Cybersecurity Framework 2.0, especially its detect, respond, and recover functions for preserving visibility and restoring trustworthy logging.
Risk and Threat Considerations
Logging changes are dangerous because they are often a precursor to persistence, credential abuse, or data theft. If an attacker can suppress auditd or redirect logs, they can reduce the chance that privilege escalation, file tampering, or lateral movement will be noticed in time.
Failure mechanism: The attacker modifies audit rules or logging destinations, then uses the reduced telemetry window to carry out additional actions while defenders lose reliable host evidence.
Impact: You may miss the earliest signs of compromise, lose forensic continuity, and be forced to investigate with incomplete records after the attacker has already left the host or exfiltrated data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Detecting logging tampering depends on continuous monitoring of host and service changes. |
| PR.DS-10 — Integrity and Availability of Data | Logging configs protect the integrity and availability of security records. | |
| Recommendation — Monitor auditd, log services, and config drift for suspicious visibility loss. Protect log pipelines so configuration changes cannot silently remove records. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Audit records and their settings must resist tampering and suppression. |
| CM-5 — Access Restrictions for Change | Unauthorized config edits are a core change-control concern for logging systems. | |
| SI-4 — System Monitoring | Host monitoring should detect service stops, rule removal, and abnormal logging loss. | |
| Recommendation — Protect audit data and alert when audit controls are disabled or redirected. Restrict who can modify audit and logging configuration. Correlate config changes with host monitoring and administrative activity. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | This question is directly about detecting tampering with audit and logging settings. |
| Recommendation — Monitor audit settings, centralize logs, and alert on logging suppression. | ||
Practitioner Guidance
What to verify: Confirm that audit rules, service state, and log forwarding are all monitored together. Single-source monitoring is easy to bypass when the change itself disables the sensor or reroutes its output.
Decision rule: If the change reduces collection breadth, stops the logging service, or breaks central delivery, treat it as a potential compromise until you can prove it was an authorised maintenance action.
Practitioner takeaway: The important judgement is whether the host still produces trustworthy evidence after the change, because detection value collapses as soon as logging is degraded.
Related resources from NHI Mgmt Group
- How do you detect changes to federation configuration in Microsoft Entra ID?
- How do you detect application URI configuration changes in Microsoft Entra ID?
- How should security teams detect privilege changes that bypass normal Active Directory logging?
- How should teams configure audit logging when audit configuration changes are not being monitored?