Docs

Appearance

auditd Setup and Operations — Linux VMs ​

Purpose: Install, configure, and operate auditd on all Linux VMs to satisfy kill chain Phase 1 requirements and HIPAA §164.312(b) audit controls.

Audience: Rory Scope: All Linux VMs — syslog VM (AWS Logging account 038901680748), Cloud PC (Ubuntu 24.04 EC2, AWS Prod 807267566999), any future Linux VMs

Why auditd ​

Windows security events (4688, 4624, etc.) cover Windows hosts. Linux VMs have no equivalent built-in unless auditd is configured. Without auditd:

  • Process execution on Linux hosts is invisible to kill chain detection
  • Privilege escalation, sudo abuse, and SSH key manipulation are undetected
  • HIPAA §164.312(b) audit controls are unmet for Linux-hosted systems

auditd writes to /var/log/audit/audit.log. The AMA (Azure Monitor Agent) forwards those logs to cirius-logging-law-central via syslog. Events land in the Syslog table and can be correlated with Windows SecurityEvent data.

Installation ​

Ubuntu 22.04 / 24.04:

bash
sudo apt-get update && sudo apt-get install -y auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd
sudo systemctl status auditd

Verify it's running and the log file exists:

bash
auditctl -s           # shows audit daemon status
ls -la /var/log/audit/audit.log

Audit Rules ​

The rules below implement the Linux equivalent of the Windows kill chain event set. Place them in /etc/audit/rules.d/cirius.rules. auditd applies rules from /etc/audit/rules.d/ on startup.

bash
sudo tee /etc/audit/rules.d/cirius.rules > /dev/null << 'EOF'
# Delete all existing rules first
-D

# Buffer size — increase if events are being dropped
-b 8192

# Ignore errors (1 = print, 2 = panic)
-f 1

# ── EXECUTION ──────────────────────────────────────────────────────────────
# All process executions (equivalent to EventID 4688)
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

# ── PRIVILEGE ESCALATION ────────────────────────────────────────────────────
# sudo usage
-w /usr/bin/sudo -p x -k sudo_exec
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/sudoers.d/ -p wa -k sudoers_change

# setuid/setgid execution
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -k privilege_escalation

# ── PERSISTENCE ────────────────────────────────────────────────────────────
# Crontab modifications (equivalent to EventID 4698 scheduled task)
-w /etc/cron.d/ -p wa -k cron_change
-w /etc/cron.daily/ -p wa -k cron_change
-w /etc/cron.weekly/ -p wa -k cron_change
-w /etc/crontab -p wa -k cron_change
-w /var/spool/cron/ -p wa -k cron_change

# Systemd service changes (equivalent to EventID 7045 new service)
-w /etc/systemd/system/ -p wa -k service_change
-w /usr/lib/systemd/system/ -p wa -k service_change
-w /lib/systemd/system/ -p wa -k service_change

# SSH authorized keys (persistence via SSH key)
-w /root/.ssh/ -p wa -k ssh_key_change
-w /home/ -p wa -k ssh_key_change

# ── CREDENTIAL ACCESS ───────────────────────────────────────────────────────
# /etc/passwd and /etc/shadow modifications
-w /etc/passwd -p wa -k user_db_change
-w /etc/shadow -p wa -k user_db_change
-w /etc/group -p wa -k user_db_change
-w /etc/gshadow -p wa -k user_db_change

# Authentication failures (equivalent to EventID 4625)
-w /var/log/faillog -p wa -k auth_failure
-w /var/log/lastlog -p wa -k auth_failure

# ── DEFENSE EVASION ─────────────────────────────────────────────────────────
# Log file tampering (equivalent to EventID 1102)
-w /var/log/ -p wa -k log_tamper
-w /var/log/audit/ -p wax -k audit_tamper

# Loading/unloading kernel modules (rootkit installation)
-w /sbin/insmod -p x -k kernel_module
-w /sbin/rmmod -p x -k kernel_module
-w /sbin/modprobe -p x -k kernel_module
-a always,exit -F arch=b64 -S init_module -S delete_module -k kernel_module

# ── NETWORK CONFIGURATION ───────────────────────────────────────────────────
# iptables and network config changes
-w /sbin/iptables -p x -k network_change
-w /sbin/ip6tables -p x -k network_change
-w /etc/hosts -p wa -k network_change
-w /etc/resolv.conf -p wa -k network_change

# ── IMMUTABLE ───────────────────────────────────────────────────────────────
# Lock rules so they cannot be changed without a reboot
# Comment this out during initial tuning, then re-enable
-e 2
EOF

Load the rules without rebooting:

bash
sudo augenrules --load
sudo auditctl -l   # verify rules are loaded

Log Forwarding to LAW ​

auditd logs land in /var/log/audit/audit.log. Two options to forward to LAW:

Option A — via rsyslog (recommended, simpler):

Configure auditd to pipe events to syslog, then AMA picks them up:

bash
# Enable syslog plugin for audispd
sudo sed -i 's/active = no/active = yes/' /etc/audit/plugins.d/syslog.conf 2>/dev/null || \
  sudo tee /etc/audit/plugins.d/syslog.conf > /dev/null << 'EOF'
active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string
EOF

sudo systemctl restart auditd

Verify events are reaching syslog:

bash
sudo logger -t auditd-test "test event"
sudo grep auditd-test /var/log/syslog

Option B — via AMA direct file collection:

In the DCR for this VM, add a custom log source pointing to /var/log/audit/audit.log. This is less clean than Option A but works if the syslog plugin is unavailable.

AMA must be installed on the Linux VM to forward to LAW. See runbooks/cortex-xdr-law-cef-integration.md for AMA installation steps via Azure Arc.

Verification ​

Once AMA is forwarding, verify events arrive in LAW:

kql
// auditd events from a specific host
Syslog
| where TimeGenerated > ago(1h)
| where Computer has "<hostname>"
| where ProcessName == "audit"
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc
| take 50
kql
// execve events (process execution)
Syslog
| where TimeGenerated > ago(4h)
| where SyslogMessage contains "type=EXECVE"
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc
kql
// sudo usage
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage contains "key=sudo_exec"
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc

If no results: check sudo journalctl -u auditd --since "1 hour ago" on the VM, and verify the AMA DCR assignment.

Day-to-Day Operations ​

Checking audit log size and rotation:

bash
ls -lh /var/log/audit/
sudo auditctl -s    # shows current backlog, lost events

If lost > 0: increase the -b buffer in /etc/audit/rules.d/cirius.rules and reload.

Testing a specific rule fires:

bash
# Test exec rule
ls /tmp/nonexistent 2>/dev/null || true
sudo ausearch -k exec -ts recent | head -20

Searching audit log by key:

bash
sudo ausearch -k sudo_exec -ts today
sudo ausearch -k service_change -ts today
sudo ausearch -k ssh_key_change -ts today

Checking for log tamper events:

bash
sudo ausearch -k audit_tamper -ts today
sudo ausearch -k log_tamper -ts today

Responding to auditd Findings in SecOps ​

Once the identity agent or a custom agent is ingesting auditd events from LAW, findings will appear in SecOps. When an auditd-based finding fires:

  1. Note the key field in the audit log (e.g., sudo_exec, service_change, ssh_key_change)
  2. Get the full audit context — auditd records usually span multiple lines with the same serial number:
    bash
    sudo ausearch --serial <serial_number>
  3. Identify the user (uid, euid, auid) and process (exe, comm)
  4. Correlate with any CM tickets for that host
  5. If unauthorized: treat as equivalent severity to the Windows kill chain event it mirrors (new service = persistence HIGH, execve from /tmp = execution CRITICAL)

Cloud PC Specific Notes ​

The Cloud PC (Ubuntu 24.04 EC2 in AWS Prod 807267566999) is the primary Linux workstation. auditd there catches:

  • All commands run via Claude Code or Kobe sessions (they run as a service account)
  • SSH access from Twingate
  • Any cron jobs or systemd services created by automated workflows

Ensure the auid (audit user ID — the logged-in user before sudo) is set correctly. On Ubuntu 24.04 with PAM, auid is automatically populated from the login session.

  • runbooks/kill-chain-phase1-enablement.md — Windows equivalent event enablement
  • runbooks/cloud-pc-operations.md — Cloud PC Ubuntu EC2 setup and operations
  • runbooks/log-retention-verification.md — verifying logs are retained per HIPAA 6-year requirement
  • security/kill-chain-coverage.md — full kill chain coverage matrix

Internal use only — Cirius Group