Your ESXi hunt query returned zero rows — how do you establish the zero is real before writing it up?

## A zero is a measurement, and measurements need controls The worst outcome of a hunt is not missing an intruder. It is writing up an empty result that was empty because nothing could ever have matched, and then having that record cited as evidence of coverage. A zero row count is produced identically by a clean estate and by a broken search, and nothing in the interface distinguishes them. So the discipline is: before the zero becomes a conclusion, demonstrate that the search had ground under it. ## The positive control The strongest single check is a search you know must return rows. Pick activity you can corroborate outside the log platform — a scheduled maintenance window, a named administrator's routine session, a backup service authenticating on a known cadence — and search for it over the same sources, the same hosts and the same window as the hunt. If that returns rows, the pipeline was carrying data and your narrow query's zero is meaningful. If it returns nothing, you have found a telemetry failure and the hunt has not started yet. A weaker but useful variant is to strip your own query down: drop the qualifying conditions and search for the noun alone — any remote shell enablement on any host at all, rather than one done outside a change window. That coarse version should return a background rate. **A background rate of exactly zero is a red flag about the data, not good news about the estate**, because in a real cluster administrators do these things routinely. ## The delivery picture, per host and per day Count events by host and by day across the window. This answers three questions at once: which hosts were in the search at all, whether any host stopped mid-window, and whether the volume looks like the cluster you know. On a virtualisation estate this matters more than almost anywhere else, because the hosts carry no endpoint agent and appear in your data only if each one was individually configured to forward its syslog. A host that sent nothing was not searched and cannot be reported as clean; it belongs in the write-up as a gap. The instinct to drop it from the denominator so the percentage looks better is exactly the wrong move. It is also worth knowing that host-local ESXi logs sit on a small scratch area and may not survive a reboot, so "we can go back and check that host later" is often false. ## Retention, honestly Search interfaces will let you select a range far longer than a given source retained. The result for the missing period is zero rows and no warning. Establish the earliest timestamp actually present for each source in the hunt, and record that as the covered window. If the sources hold fourteen days, the negative is fourteen days long no matter how the search was run. ## The fields you filtered on A filter on a field that is no longer extracted matches nothing and reports success. Parser and schema changes do this quietly: a message format changes on an upgrade, the command text ends up inside an unparsed blob, and every rule and query keyed on the extracted field goes silent without erroring. Sample a handful of raw records from inside the window and confirm the fields your logic depends on are populated in them. This is also why a query written against a normalised field is worth re-running against the raw text once, as a cross-check. ## The logic itself Finally, sensitivity. Describe the record that would have matched. If you cannot write that sentence, you cannot claim the query could have found anything. And be explicit about variants: a hypothesis drawn from one public write-up encodes one implementation, so an actor who achieved the same objective through the management API rather than a host shell produces no match and no contradiction. ## Where this stops This is verification of a one-off hunt's ground truth, not health monitoring of deployed detections — those are separate practices with separate mechanisms. Here the question is narrower and answerable in an afternoon: did my search have data under it, on which hosts, for how long? Answer that first, and the write-up becomes a security statement instead of an unexamined zero.