What does a parent-child process baseline give a threat hunter who has no alert in hand?

## The problem a baseline solves Detection engineering starts from a hypothesis about an adversary and writes a rule. Hunting starts from nothing: no alert has fired, no one has reported anything, and you are looking at a process-execution table with tens of millions of rows a day. The only lever that makes that table readable is a model of what the estate ordinarily does, so that everything else stands out. A parent-child process baseline is the simplest and most durable form of that model. ## What it actually is It is the learned distribution of **(parent image, child image)** pairs across the fleet, usually with a count of how many distinct hosts each pair appears on and how often. On Windows the raw material is normally Sysmon **Event ID 1** (process creation), which records the new process image, its command line, its hashes, the user, and the **parent image** and parent command line. The native Windows Security **4688** event also records process creation, but the command line appears only when the "Include command line in process creation events" audit policy is enabled — a detail worth knowing because a great many estates baseline 4688 without it and then wonder why their pairs carry no context. On Linux the same idea is built from `auditd` `execve` records or an EDR's process tree. ## Why the pair, not the process Almost every binary an adversary abuses is one the estate also uses legitimately. A command interpreter, a scripting host, a certificate utility, a remote-management tool: each of them runs thousands of times a day for entirely ordinary reasons, so a baseline of *process names* tells you almost nothing. The lineage is where the behaviour shows. The same child under a software-deployment agent is routine; under a document reader, a mail client, or a web server's worker process it is a lead. This is why hunters talk about ancestry, and why a useful baseline usually keeps at least the grandparent as well — a script host launched by a scheduled-task engine reads very differently from one launched by a spreadsheet. ## Normal is a property of this estate There is no portable list of good and bad parents. An estate that runs a remote-monitoring-and-management product will see a shell spawned from an unfamiliar agent binary all day long. A CI fleet spawns compilers, package managers and shells from a build agent constantly, and the same tree on a finance laptop would be extraordinary. A published "suspicious parent process" list is a starting hypothesis, not a baseline; the baseline is what your own telemetry says. That also means the population you baseline over matters more than the time window: baseline workstations and servers together and each one's normal hides the other's abnormal. ## What it does and does not prove A baseline ranks; it does not judge. If a pair appears on two hosts out of nine thousand, you have established exactly one thing: it is rare **here**. Rare is a reason to read, and the reading is where the verdict comes from — who ran it, from what, with what command line, was there a change record, is there an owner who will claim it. Plenty of rare pairs are a developer testing something, a one-off vendor installer, or an engineer troubleshooting. Equally, common is not safe: an adversary who has been resident long enough for their scheduled task to run on many hosts is inside your definition of normal. ## Making the baseline harder to defeat Because the baseline keys on names, an adversary can hide inside it by reusing a legitimate name in an illegitimate location, or by launching from a parent your estate already trusts. That is not a reason to abandon the technique; it is a reason to fold in fields the name alone does not carry: the full image **path**, the signer, the file hash, the integrity level, the user context, and the command line. A pair that matches the baseline on names but sits in a user-writable directory, or is unsigned where the baselined instance is signed, is exactly the kind of lead a name-only baseline throws away. ## How it is used in practice Build it over a window long enough to include the estate's cycles (patch days, month-end, deployment waves), record the population and window it covers, then work the pairs the baseline does not contain — and, just as importantly, the pairs it contains that no one can explain. Hunting is as much about finding what should not be routine as about finding what is rare.