Reading the Host: Process Ancestry & Command Lines

What is it?

Process ancestry is the parent-child chain that shows which process started which. A command line is the exact instruction a process was launched with. Together they say not just what ran, but who launched it and why — the two facts that decide whether a process is normal or malicious.

Why it matters

Attackers rarely bring exotic tools; they abuse trusted, signed programs (PowerShell, wscript, rundll32). The binary name looks innocent, so a name-only view sees nothing. Malice shows only in the ancestry and the command line — the parent that should never have launched it, and the arguments a legitimate use would never pass.

Where you see it

Process ancestry and command lines live in endpoint telemetry — Sysmon Event 1, Windows Event 4688 (with command-line auditing enabled), and EDR process trees. The SIEM indexes them so you can pivot from a host to its full process history.

What normal looks like

Normal ancestry is predictable: services.exe starts services, explorer.exe starts the apps a user clicks, a software updater starts its own child from a protected path. The same trusted binary, launched by its usual parent with ordinary arguments, is just the system working.

What suspicious looks like

Suspicion is a parent-child pair that has no business existing — a document application spawning a script interpreter — combined with a command line built to hide (encoded, hidden window) or to reach out (a download, an execution from a public folder). The pair plus the arguments, not the name, is the signal.

How analysts investigate

Start from the suspicious process and walk UP the ancestry to the root, asking at each step 'should this parent have launched this child?'. Then read the command line in full — decode it if encoded — and ask what a legitimate use of this program would look like. The gap between the two is your finding.

Common beginner mistakes

Judging a process by its name alone — a trusted name run by the wrong parent is the most common attacker technique.
Reading only the immediate parent and stopping, instead of walking the whole ancestry to the root.
Ignoring an encoded command line as 'unreadable' instead of decoding it — the encoding is itself a signal.

What you will be able to do

Walk a process ancestry from a suspicious child up to its root.
Read a command line as evidence — including decoding an encoded one.
Judge a process by its parent and arguments, not by its name.

A Tier-2 analyst handed an endpoint alert does not ask 'is powershell.exe bad?' — of course it is not, on its own. They ask 'what launched this powershell.exe, and what did it run?'. The answer lives in two places: the ancestry above the process, and the command line inside it.

Term	Meaning
Parent process	The process that started another
Ancestry	The full chain of parents up to the root
LOLBin	A trusted, signed binary abused by an attacker
Command line	The exact arguments a process was launched with

Step by step: (1) locate the suspicious process; (2) walk up — read its parent, then its parent's parent, to the root; (3) at each link ask whether that parent legitimately launches that child; (4) read the full command line, decoding any encoding; (5) compare against what a legitimate use would look like.

Worked example — which line is the smoking gun?

Sysmon Event 1 · host FIN-WS-09

explorer.exe -> WINWORD.EXE  (user opened a document)
WINWORD.EXE  -> powershell.exe  -enc SQBFAFgA...  (hidden window)
powershell.exe -> C:\Users\Public\rt.exe

Three parent-child links. Before reading on, decide: which link tells you this is an intrusion?

The answer: the middle link. explorer.exe launching WINWORD.EXE is a user opening a document — normal. But a document application (WINWORD) launching a script interpreter (powershell.exe) with an encoded command and a hidden window is a parent-child pair that has no legitimate reason to exist, and the arguments confirm intent to hide. The third link — dropping rt.exe to a public folder — is the payload that follows. Read by name, all three look like signed Microsoft binaries; read by ancestry and command line, the story is obvious.

Recap

Malice on the host shows in the parent-child pair and the command line, not the process name.
Walk the whole ancestry to the root; do not stop at the immediate parent.
An encoded or hidden command line is itself a signal — decode it, don't skip it.