analyzing-linux-audit-logs-for-intrusion skill by mukul975

Analyzing Linux Audit Logs for Intrusion

When to Use

Investigating suspected unauthorized access or privilege escalation on Linux hosts
Hunting for evidence of exploitation, backdoor installation, or persistence mechanisms
Auditing compliance with security baselines (CIS, STIG, PCI-DSS) that require system call monitoring
Reconstructing a timeline of attacker actions during incident response
Detecting file tampering on critical system files such as /etc/passwd, /etc/shadow, or SSH keys

Do not use for network-level intrusion detection; use Suricata or Zeek for network traffic analysis. Auditd operates at the kernel level on individual hosts.

Prerequisites

Linux system with auditd package installed and the audit daemon running (systemctl status auditd)
Root or sudo access to configure audit rules and query logs
Audit rules deployed via /etc/audit/rules.d/*.rules or loaded with auditctl
Recommended: Neo23x0/auditd ruleset from GitHub for comprehensive baseline coverage
Familiarity with Linux syscalls (execve, open, connect, ptrace, etc.)
Log storage with sufficient retention (default location: /var/log/audit/audit.log)

Workflow

Step 1: Verify Audit Daemon Status and Configuration

Confirm the audit system is running and check the current rule set:

# Check auditd service status
systemctl status auditd
 
# Show current audit rules loaded in the kernel
auditctl -l
 
# Show audit daemon configuration
cat /etc/audit/auditd.conf

If the backlog limit is being reached, increase it:

Step 2: Deploy Intrusion-Focused Audit Rules

Add rules that target common intrusion indicators. Place these in /etc/audit/rules.d/intrusion.rules:

Reload rules after editing:

Step 3: Search for Intrusion Indicators with ausearch

Use ausearch to query the audit log for specific events:

Step 4: Generate Summary Reports with aureport

Use aureport to produce aggregate summaries for triage:

Step 5: Reconstruct the Attack Timeline

Combine ausearch queries to build a chronological narrative:

Step 6: Forward Audit Logs to SIEM

Configure audisp-remote or auditbeat to ship logs to a central SIEM for correlation:

Key Concepts

Term	Definition
auditd	The Linux Audit daemon that receives audit events from the kernel and writes them to `/var/log/audit/audit.log`
auditctl	Command-line utility to control the audit system: add/remove rules, check status, set backlog size
ausearch	Query tool that searches audit logs by message type, user, file, key, time range, or event ID
aureport	Reporting tool that generates aggregate summaries of audit events for triage and compliance
audit rule key (-k)	A user-defined label attached to an audit rule, enabling fast filtering of related events with ausearch and aureport
syscall auditing	Kernel-level monitoring of system calls (execve, open, connect, ptrace) that captures process and file activity
augenrules	Utility that merges all files in `/etc/audit/rules.d/` into `/etc/audit/audit.rules` and loads them into the kernel

Verification

auditd is running and rules are loaded (auditctl -l returns expected rule count)
No audit backlog overflow (auditctl -s shows backlog: 0 or low value, lost: 0)
ausearch returns events for each custom key (ausearch -k <key> -ts today returns results)
aureport generates non-empty summaries for authentication, executable, and file events
Timeline reconstruction produces a coherent chronological sequence of attacker actions
Critical file watches trigger alerts on test modifications (touch /etc/shadow generates an event)
Logs are forwarding to central SIEM (verify with a test event and confirm receipt)
Audit rules persist across reboot (rules in /etc/audit/rules.d/, not only via auditctl)