Stack counting reads the rarest rows - what kind of intrusion hides in the common ones?

## The assumption inside the method Stack counting ranks by frequency and asks the hunter to read the bottom of the distribution. That is only useful under an assumption: **the hostile thing is infrequent in the field you counted**. It is a good assumption often enough to make the technique the workhorse of hunting, and it fails in specific, predictable ways worth being able to name. ## Failure one: the adversary is in a column you did not stack Consider a cluster where almost every workload runs from a small set of approved base images. An adversary who can create pods does not need an image nobody has seen; they can start a pod from the most-pulled image in the estate and override the container `command` at creation to run whatever they like. Stack the image field and their pods land inside the largest row in the table. Stack the entrypoint and they are a singleton. The general rule: **stack the field where the adversary has freedom and the estate has convention**. A field the estate standardises but the adversary can still control is where rarity carries the most information. A field the adversary must inherit from the estate carries none. ## Failure two: your automation makes them common If something hostile gets into a shared chart, a base layer, a DaemonSet or an admission-injected sidecar, the estate's own deployment machinery replicates it across hundreds of pods. By the time a hunter counts, the artefact has a count in the hundreds and sits comfortably in the head. This is the failure mode with the widest blast radius, and the one the method is least equipped to find: the more thoroughly something spread, the more invisible least-frequency analysis makes it. ## Failure three: the value is deliberately unremarkable An adversary who runs `/bin/sh -c` shares a value with thousands of legitimate containers. Nothing about their execution is rare in that column, even though the specific instance is entirely abnormal in context. Rarity is a property of a value, not of an event, and an event can be extraordinary while the value it produced is ordinary. ## What to do about it **Pair fields.** A joint value can be rare while both components are common. An image with tens of thousands of pulls and a command run by thousands of containers may occur together exactly once. Pairing costs cardinality - every field you add to the grouping key grows the tail - so pair fields that are *conventionally linked*, where the estate normally couples them: image with entrypoint, service account with verb, registry with namespace. **Stack within the head.** Rather than reading the tail across a heterogeneous estate, condition on the largest row and stack inside it. Take the single most-deployed image and count the entrypoints, service accounts, namespaces or node pools its pods used. Rarity within a large, homogeneous group is a far stronger signal than rarity across a mixed one, because the population you are comparing against is genuinely comparable. **Change the record source.** If a technique is common in every field of one source, another source may see it differently. What is unremarkable in creation records may be unusual in what the container then did on the network or on disk. ## The negative-evidence limit This is where the technique's honesty matters most in an interview. A stack that surfaced nothing constrains **only the field set, window, normalisation and record source you used**. It is not a statement about the estate. An adversary who is common in that field, or absent from that record source entirely, leaves the stack looking exactly the same as a clean cluster. Report a hunt as 'no rare values in this field set over this window', never as 'the cluster is clean'. ## Common mistakes - Believing malicious activity must be rare. - Clearing the head without inspecting it. - Reading an empty tail as proof of absence. - Pairing every available field at once, which multiplies cardinality until the entire data set is the tail.