Repository navigation
Add Linux Auditd Audit Configuration File Modification detection - #4385
vahidmalekk wants to merge 2 commits into
Conversation
Detects tampering with auditd config under /etc/audit/ (rules.d/*.rules, auditd.conf, plugins.d/, audit.rules) and /etc/libaudit.conf via Linux Auditd, correlating the PATH record for the config file with the SYSCALL record to surface the editing process. Catches the stealthy variant where auditing is hollowed out without stopping the daemon (no DAEMON_END). T1562.001 / T1070.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2014c9fcaf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| search: |- | ||
| `linux_auditd` | ||
| ( | ||
| (type=PATH name IN ("/etc/audit/*", "/etc/libaudit.conf") nametype IN ("CREATE","NORMAL","DELETE")) |
There was a problem hiding this comment.
When an editor is invoked after cd /etc/audit or cd /etc/audit/rules.d, auditd can put only auditd.conf or foo.rules in the PATH record's name; data_sources/linux_auditd_cwd.yml:7 explicitly documents CWD as the mechanism for reconstructing this case. This predicate discards those PATH records before correlation, and the later audit_config_file expression accepts only absolute names, so a modification performed with an attacker-controlled relative path never creates a risk event. Include type=CWD in the event correlation and reconstruct the absolute path before applying the /etc/... filter.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in bce7d57 using the CWD-reconstruction pattern from linux_auditd_possible_access_or_modification_of_sshd_config_file: the correlation now includes type=CWD and reconstructs the absolute path with mvmap(names, if(match(names,"^/"), names, current_working_directory."/".names)) before the /etc/audit + /etc/libaudit.conf filter, so a modification performed via a relative path after cd /etc/audit (or /etc/audit/rules.d) now creates a risk event. data_source and how_to_implement updated to require the type=CWD record.
| ( | ||
| (type=PATH name IN ("/etc/audit/*", "/etc/libaudit.conf") nametype IN ("CREATE","NORMAL","DELETE")) | ||
| OR | ||
| (type=SYSCALL syscall IN ("rename","renameat","renameat2","open","openat","openat2","write","truncate","ftruncate","unlinkat","unlink","linkat","symlinkat")) |
There was a problem hiding this comment.
In deployments with additional audit rules that record read access, a read-only open, openat, or openat2 of an audit configuration file emits a PATH nametype=NORMAL record and a matching SYSCALL, so it passes this branch and the later where despite making no modification. The recommended -p wa watch masks this only when it is the sole matching rule; broader audit policies make routine configuration inspection generate score-64 events claiming the file was modified. Require a successful write-capable open (or equivalent evidence from the write-specific audit rule) before classifying these syscalls as modifications.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in bce7d57. The correlation now collects success from the companion SYSCALL record and the guard is where match_count>0 AND success="yes" AND isnotnull(process_name). The reworked pattern (PATH+CWD+SYSCALL joined by audit event id) no longer filters on syscall names at all, so rather than trying to distinguish read vs write by syscall, the success=yes requirement plus the write-type nametype (NORMAL/CREATE/DELETE, produced by the -p wa watch) is what qualifies it as a modification; a read-only or denied open does not satisfy both. Validated against live auditd data - the sed/tee/rm write events surface and nothing else does.
…ard, drop syscall-name filter (address review)
Summary
Adds a new anomaly analytic, Linux Auditd Audit Configuration File Modification, detecting tampering with the auditd configuration (T1562.001 / T1070) under
/etc/audit/- rules files (rules.d/*.rules,audit.rules), the daemon config (auditd.conf), audit dispatcher plugins (plugins.d/) - and/etc/libaudit.conf.Coverage gap
ESCU has auditd daemon/service tamper detections (
linux_auditd_auditd_daemon_shutdown/_daemon_abort/_daemon_start/_auditd_service_stop), but nothing for on-disk config modification. That's a real gap: editingrules.d/*.rulesorauditd.confhollows out auditing on the next reload/reboot without stopping the daemon, so noDAEMON_ENDevent fires and every existing auditd rule stays silent. This analytic closes that blind spot.How it works
Correlates the auditd
PATHrecord for an audit config file (nametypeCREATE for an editor rewrite, NORMAL for in-place write, DELETE for removal) with theSYSCALLrecord from the same audit event id, surfacing the editing process (comm/exe) and user - the sameLinux Auditd Path+Linux Auditd Syscallmodel aslinux_auditd_doas_conf_file_creation.Testing
True-positive dataset captured from a reversible sim on an authorized lab host, covering both edit methods (
sedrewrite -> CREATE,tee -a-> NORMAL) against/etc/audit/rules.d/. Paired attack data: splunk/attack_data#1260;tests.attack_datapoints at it, so the unit test passes once #1260 merges.MITRE ATT&CK
T1562.001 (Impair Defenses: Disable or Modify Tools), T1070 (Indicator Removal)
Modeled as Anomaly with a filter macro because
augenrulesrecompilesaudit.rulesand package upgrades touch these files (documented in known_false_positives). Happy to adjust the path list, syscall set, or FP filtering to STRT conventions.