In threat hunting, what is stack counting, and what does a rare value actually prove?
answer
- group, count, sort ascending
- frequency, not maliciousness
- the tail is a worklist
- rare in this population, this window
- needs a second, independent fact
basics
~20 sStack counting groups records by a chosen field, counts every value, and reads the smallest counts first. A rare value proves only that it is unusual in this population over this window: a prioritisation signal, never a verdict.
solid answer
~50 sStack counting, or least-frequency analysis, takes a body of records, groups them on a field or a small field set, counts occurrences of each value, and sorts ascending so the rarest sit at the top. Hunting a Kubernetes estate, I might take every pod-create audit record for the last thirty days, group on the container image repository, and read the values that appear once or twice. The claim that supports is narrow: this value is unusual in this population, over this window. That is a reason to look, not a finding - a singleton is just as likely to be a new service's first deploy or a pod someone ran by hand. The converse trap matters too: a common value is not cleared. So every tail row still needs a second, independent fact - who created it, what the container then did, whether that registry appears anywhere else - before it becomes a lead.
go deeper
Be ready to define stack counting in one breath - group on a field, count the values, read the smallest counts - and to say plainly that rare means unusual, not malicious.
Explain what the count is actually over: which records, which field at which granularity, and which window. Show that changing any of the three changes the tail.
Demonstrate how a tail row becomes a lead - the second, independent fact you go and get - and how you judge whether the tail is worth the review hours before you start.
Set the expectation with leadership that hunts which stack cleanly still produce findings rarely, and that 'this estate has no convention on that field' is a legitimate reportable result rather than a wasted quarter.
## The technique **Stack counting** - also called *least-frequency analysis* or *frequency stacking* - is the oldest and cheapest technique in threat hunting. You take a defined body of records, choose a field or a small set of fields, count how many records carry each distinct value, and sort those counts ascending. The output is a two-column table: value, count. The hunter reads it from the bottom of the distribution upward, because the interesting rows are usually the ones with a count of one or two. Nothing is trained, scored or thresholded. It is a `GROUP BY` and an `ORDER BY`. That is the point: it needs no labels, no model, no prior alert and no rule, and it works over data you are already keeping. ## Three things you must state before you count A count means nothing without all three, and an interviewer will check whether you name them unprompted. 1. **The population.** Which records are you counting - every pod-create audit event in the cluster, or only those in namespaces that hold production data? Rarity is relative to whatever you put in the bucket. 2. **The field set.** Which value are you counting occurrences of, and at what granularity? Counting a value that changes on every deploy produces a table where everything has a count of one and nothing is learned. 3. **The window.** Seven days and ninety days produce different tails from the same estate. A monthly batch job is a singleton in a weekly window and a count of three in a quarterly one. ## A worked example In a Kubernetes estate, take every `create` audit event for the `pods` resource over thirty days. Group on the container image *repository* - registry host plus repository path, with the tag and digest stripped - and count. You might get a few hundred distinct repositories, most with counts in the hundreds or thousands as deployments and restarts churn pods, and a few dozen appearing once. That last group is the tail: workloads started from an image essentially nothing else in the estate uses. ## What rarity proves, and what it does not Rarity is a statement about **frequency in a chosen population**, and it carries no information at all about intent, provenance or effect. In any real estate the overwhelming majority of rare things are benign: a new service's first deploy, a debugging pod, a contractor's namespace, a scheduled task that ran once in the window. That base rate is why the tail is a **worklist**, not a set of findings. The converse mistake is more dangerous, because it is silent. A **common value is not cleared**. Adversaries can be common - by borrowing something the estate already runs everywhere, or by riding automation that deploys their persistence as widely as the workload it hides in. And stack counting produces no negative evidence either. An empty tail says nothing about the estate; it says something about the one field set, one window and one record source you stacked. ## Turning a tail row into a lead Rarity gets a row in front of a human. A **second, independent fact** turns it into a lead. For a rare container image that means: which namespace and service account created the pod, what the container executed once it was running, whether the image's registry appears anywhere else in the estate, and whether any change record explains it. If the second fact is also unusual you have a lead; if it is ordinary you close the row and move on. ## Where it sits relative to other things It is **not an anomaly-detection model**: nothing is scored, nothing is trained, there is no contamination parameter and no decision boundary. It is **not a detection rule**: it is run by a human who chose the field, reads the whole distribution, and interprets its shape. It is exploratory analysis whose product is a ranked review list plus the hunter's judgment about what the distribution's shape means. ## Common mistakes - Reading the rarest row as the malicious one by definition. - Assuming a common value is safe. - Quoting a count without saying over which records and which window. - Counting a field that carries per-record entropy, so every row reads one. - Reporting the tail's size as if it were a finding.
- What changes if you stack the same field over seven days instead of ninety?A short window inflates the tail: weekly and monthly jobs, release cadence and holiday cover all appear once. A wider window lets legitimate repeats accumulate and shrinks the tail, but it also lets an adversary's activity accumulate into a count of five and slip out of the rarest rows. Choose the window from the estate's own rhythms and record it in the write-up.
- Your rarest row is one pod from a registry nobody recognises. What is your next step?Enrich before concluding. Find who or what created the pod, in which namespace and under which service account, what the container executed once running, and whether that registry appears anywhere else in the estate or in any change record. Rarity earned the row its place in front of you; the verdict comes from that second fact.
- Why is stack counting worth doing if it produces no verdict on its own?Because it converts an unbounded search into a finite, ranked review list with no labels, no model and no prior alert - one aggregation over data you already hold. It is the cheapest way to surface behaviour nobody wrote a detection for, which is exactly the class a rule-driven SOC cannot see.
It is like reading a warehouse inventory sorted by how many of each item are on the shelves. The pallet with a single unit is worth walking over to look at - but it is usually just a new product line, not a theft.
saying these in an interview costs you the question
- Treats the rarest row as malicious by definition
- Says a common value is therefore benign
- Describes stack counting as a model that scores each record
- Sends the whole tail to the analyst queue as alerts
- Cannot say which population and window the count is over