How do you prove an emulated technique's miss was absent auditd telemetry, not an unmatched rule?

## What you are trying to distinguish Two findings look identical from the pager and cost completely different things to fix: - **The event never existed.** Nothing on that host wrote a record of the behaviour. No query, however good, could have matched. - **The event existed and nothing matched it.** The estate recorded the behaviour and had no rule that said anything about it. You executed the technique, so you know the ground truth: which host, which command line, which second. That turns the question into an evidence exercise rather than a guess. ## Start at the host, not the platform The instinctive move — search the SIEM over the execution window and find nothing — is the move that produces the wrong answer, because an empty result there has at least three causes: 1. The record was never generated (the `execve` audit rule was not loaded, or auditd was not running). 2. The record was generated and never delivered (agent stopped, filter dropped it, queue backed up). 3. The record was generated and delivered, but normalisation renamed or dropped the field your search keyed on, so it is sitting there under a different shape. Only (1) is truly "absent telemetry at the source"; (2) is a delivery problem and (3) is not a telemetry problem at all. So look on the host itself over the window and see whether the local audit log holds the syscall record for your execution. Then compare with what the platform holds for the same window. Host-yes/platform-no is a pipeline finding. Host-no is a collection finding at the source. ## The positive control The single most persuasive artefact in this whole exercise is a **control host**: a machine of a different build class, known to have the `execve` rule loaded, on which you run the identical command. If the record appears there and is absent on the target, you have simultaneously proved three things — the technique does emit an auditable record, your harness actually ran, and the difference is the host's own configuration. Without a control, "I found nothing" is not distinguishable from "I searched badly". The same logic covers your persistence step. A systemd timer's unit file lands on disk; a file-write watch would record the write, and the journal separately records the unit starting. Where auditd is silent but the journal shows the unit being started, the behaviour was observable on a *different* surface — which changes the finding from "invisible" to "visible somewhere nobody is looking", and that is a materially different recommendation. ## Traps that produce a false "absent" - **Clock skew.** Your harness timestamp and the host's clock may differ by minutes. Widen the window generously before declaring emptiness; a five-minute search around a skewed clock manufactures collection gaps that do not exist. - **Searching by the wrong identifier.** For a timer-launched process there is no login session: the audit record carries an unset `auid` and `ses`. A search filtered by a user identity will legitimately return nothing for a record that is right there. - **Truncated fields.** The `comm` field is a short process name, not the command line; the argument vector lives in the `EXECVE` record. Searching `comm` for a script path finds nothing even though the record exists. - **Retention.** If you look a week later and the raw index has aged out, absence is meaningless. Do this walk-back within the retention of the source you are searching. ## Writing the conclusion If the host never wrote the record, the finding is a **collection gap on a named host class**, and it is scoped: state how you know it is the class and not just the one machine you tested. If the record was there all along, you have exonerated collection and the next step is to run the rule's own logic over the stored record — where a non-match has its own two explanations, real logic gap versus a normalisation mismatch that stripped the field the rule keys on. One boundary worth stating out loud in an interview: your output is the attribution and its evidence. *Loading the audit rule across the image class* belongs to whoever owns that image and its telemetry, and *rewriting the rule* belongs to the detection engineers. Purple team's product is the proof of which of them is on the hook.