Rare Is Not the Same as Malicious

What is it?

Hunting at scale surfaces outliers — the least-frequent values in a large population. Validation is deciding whether a rare result actually confirms your hypothesis or is just an uncommon-but-benign artefact, and then, when confirmed, turning the hunt into a detection.

Why it matters

Least-frequency analysis is powerful and treacherous: rare things are interesting, but most rare things are benign (a one-off admin script, a new vendor tool). Calling every outlier malicious floods the SOC; dismissing them all misses the intrusion. Validation is the judgment in between.

Where you see it

In stack-counting results (a column of values ordered by frequency), where the rare tail is the hunt output, and in the detection you write once a rare pattern is confirmed as a technique.

What normal looks like

A rare-but-benign outlier has an accountable explanation: a signed binary, a known admin, a change-ticket, a vendor process — context that a quick check confirms.

What suspicious looks like

A rare outlier with no benign account, whose properties match the hypothesis' technique (unsigned, user-writable path, Office parent) and that clusters with other incident indicators.

How analysts investigate

For each outlier, seek the benign explanation first (signer, owner, change record). If none survives and the properties match the hypothesis, it is a confirmed find — then write the detection that would have caught it, targeting the technique not the single value.

Common beginner mistakes

Treating 'rare' as 'malicious' and escalating every low-frequency outlier without checking for a benign owner.
Writing a detection for the exact rare value found, so it catches that one artefact and nothing else the technique produces.

Validate the outlier, then generalise the catch

  stack count (parent of powershell.exe, by frequency)
   explorer.exe      12,904   ── common, benign
   services.exe       4,110   ── common, benign
   winword.exe            3   ── RARE  ─┐  seek benign owner:
   excel.exe             1   ── RARE  ─┘  signed? change ticket? macro-enabled?
  rare + no benign account + matches hypothesis  ─▶  confirmed technique
  detection targets: Office app  ──parent──▶  powershell/cmd/wscript (the TECHNIQUE)

The rare tail is the hunt output; validation checks each outlier for a benign owner, then the detection targets the technique, not the one value.

Worked example. Stack-counting parents of powershell.exe across 20,000 hosts leaves a rare tail: winword.exe (3) and excel.exe (1). You check each: no signed macro-automation, no change ticket, and the affected users are all in the phishing target list — the benign explanation fails. Confirmed. Now the detection: not 'winword.exe is parent of powershell' (too narrow) but 'a Microsoft Office application is the parent of any script interpreter (powershell/cmd/wscript/mshta)' — the technique, so it also catches excel.exe→mshta next time.

Quick check

Your stack-count surfaces a rare LOLBin (a signed, Microsoft-shipped tool) used once. Before calling it malicious, what matters most?

A quick self-check — it doesn't affect your XP or progress.