In a hunt over auditd logs, how do you confirm execve records exist on a Linux fleet?

## Why auditd needs an explicit coverage check The Linux audit subsystem does not log by default in any useful sense. The kernel emits audit records for the events that **loaded rules** select; `auditd` is the userspace daemon that writes them out. Rules come in two families that matter to a hunter: - **syscall rules**, which select a system call and optional filters — the execution one is `execve`, and it is the rule that makes "what did this host run" answerable at all; - **watch rules**, which select a file or directory path and the access types to record, and are what make "did a new unit file or cron entry appear" answerable. When no rule matches, nothing is written. There is no truncated record, no counter, no warning in the query result. This is the property that makes a preflight necessary: an uninstrumented host and a quiet host produce identical output. ## What the check actually looks like Take the hypothesis — persistence installed as a `systemd` timer or a user cron entry, executing a payload on a schedule. The records that would betray it are execution records for whatever the timer runs, and write records against the unit directories and the cron spool. For each, confirm three things: **Is the rule loaded, per build image?** Fleets are rarely uniform. Mixed distro builds, images from different eras, hosts that pre-date the hardening baseline: execution auditing may be present on the current image and absent on the older ones, which are frequently the hosts you care about most. Sampling one host per image, rather than one host, is the difference between a real coverage figure and an anecdote. Older images may also carry no EDR sensor at all, so audit records are the only execution telemetry available there — and if the rule is missing, that host contributes nothing. **Do records arrive in the index?** A rule can be loaded on the host while the records never reach the search platform. Confirm by finding a genuine record for that host in the index within the last day, not by trusting the host-side configuration. **Do they carry the fields the hunt filters on?** An `execve` event lands as a pair of records sharing one event identifier: a `SYSCALL` record with the process metadata and a companion `EXECVE` record holding the argument vector. The arguments are the point — a scheduled payload is usually a shell invoked with a script path, so a source that gives you only a process name answers a much weaker question. Check the field names after normalisation too, since a mapping step can rename or drop them on the way in. ## Reading the sample record correctly A few field-level facts change what a record supports: - `syscall=59` on x86_64 is `execve`; the `arch` field tells you which syscall table applies, so a 32-bit process is a different number and rules must cover both architectures to be complete. - `auid` is the login uid. When it is unset it appears as `4294967295` — the unsigned form of -1 — which is normal for anything started by init or a timer rather than by a login session. It means you **cannot attribute the execution to a user from this record**; that is a real limitation to state in a hunt write-up, not a corrupt record. - `key` is the tag from the rule that matched. Its presence is itself useful preflight evidence: it tells you which ruleset is in force on that host. - `ppid` gives the parent process id, but the parent's identity has to be resolved from other records — by the time you look, the parent may be gone. ## What the check produces The honest output is a coverage statement with a denominator and a shape: which images carry execution auditing, which carry the directory watches, how many hosts each covers, and which are dark. That statement then travels with the hunt result, so the negative is read as "not seen across the covered subset" rather than "not present in the fleet". Where an image is dark, the gap is written up as a collection requirement naming the exact records needed and the hunt they unblock — and, in the meantime, the hunter looks for compensating evidence on those hosts: configuration-management inventory of unit and cron files, file-integrity data, and resolver query logs, which are collected centrally and therefore unaffected by the host's audit configuration.