The same encoded PowerShell runs under WINWORD.EXE on one host and under an RMM agent on 4,000 — how does ancestry decide each verdict?
answer
- identical leaves, different roots
- explorer versus the service control manager
- session 0 and SYSTEM are the tell
- verify the parent's path, not its name
- hijacked automation lends its lineage
basics
~20 sCompare the roots, not the leaves. One chain is rooted at an interactive user's document application; the other at the service control manager starting a management agent as SYSTEM in session 0. Identical children, different causes, opposite verdicts.
solid answer
~50 sThe alerted process is the same in both cases, so nothing about it can separate them — I have to read upward. On the workstation the chain roots at `explorer.exe` -> `WINWORD.EXE` under an interactive account at medium integrity in an interactive session: a person opened something and it executed code. On the fleet the chain roots at `services.exe` -> the remote-management agent's service, running as `NT AUTHORITY\SYSTEM` in session 0, with the agent's signed helper binary in its own install directory as the immediate parent, and the same lineage recurs on the agent's maintenance window rather than at random. That second one is a benign true positive: the rule fired on precisely what it was written to match, and the activity was authorised. I would still decode both arguments and check the parent's image path and signer, because the one thing ancestry cannot tell me is whether someone has obtained execution *through* the agent — a hijacked parent lends its whole lineage to the intruder.
go deeper
Know that two identical-looking alerts can have opposite verdicts, and that the first move is to climb to the root of each chain rather than to compare the alerted command lines.
Explain the concrete comparison points — chain root, account, session and integrity level, the parent's full image path and signer — and use the term benign true positive correctly for sanctioned activity a correct rule caught.
Demonstrate the limit out loud: an adversary executing through the management agent inherits its lineage, so a clean chain establishes cause but never authorisation, and you pivot to job records and script content to close that gap.
Be ready to argue what the organisation must maintain for this to be answerable at all — a known set of automation lineages with named owners — and what it costs the SOC when that knowledge lives only in individual analysts' heads.
## The problem: an identical leaf process A detection on `powershell.exe` with a hidden window and an encoded argument will fire on two completely different things in the same estate on the same day. On one workstation the argument arrived because a user opened a document. On four thousand workstations the identical argument arrives because a remote-monitoring-and-management agent runs an inventory or patch script every Tuesday. Byte for byte the alerted record can look the same: same image path, same switches, same base64 shape. **If the verdict lived in the child, both would get the same verdict, and one of them would be wrong.** It lives in the ancestry. ## What to compare, in order **The root of the chain.** Climb until you reach something that explains why anything ran at all. `explorer.exe` means a person launched an application. `services.exe` means the service control manager started a service. `svchost.exe` hosting the Task Scheduler means a registered task fired. These roots are not interchangeable and they are the single most informative thing in the chain. **The account and session.** A user's chain runs as a domain account at medium integrity in an interactive session. The agent's chain runs as `NT AUTHORITY\SYSTEM` in session 0, the non-interactive session where services live. A chain that claims to be a person but runs in session 0, or claims to be a service but runs at medium integrity in a user's session, deserves a second look. **The immediate parent's identity, not just its name.** "The parent was the agent" is a claim about a filename. Check the parent's full image path — is the helper binary in the vendor's own installation directory, or in a temporary or user-writable location wearing the same name? Check its signer. A chain whose parent is a legitimately named binary running from the wrong path is a different finding from one whose parent is the real thing. **The shape over the fleet.** The agent's chain is the same lineage repeating on a schedule the agent owns, across a maintenance window. The user's chain is a one-off under one person's session. That is a statement about lineage and timing, not about whether one binary is rare. **The decoded argument, last.** Decode both. The agent's decodes to an inventory or patch routine consistent with what the tool exists to do; the workstation's decodes to whatever the document brought with it. Decoding is confirmation of a hypothesis the ancestry already gave you, not the starting point. ## The outcome vocabulary matters Closing the fleet-wide case as a *false positive* is wrong and it is the answer interviewers listen for. The rule matched exactly the behaviour it was written to match; the behaviour was real and it was authorised. That is a **benign true positive**. The distinction is not pedantry: a rule that produces benign true positives is working and its logic is sound, while a rule producing false positives is wrong about what it is matching. Those two diagnoses lead to different conversations with whoever owns the rule. ## What ancestry cannot settle This is the limit you must state before an interviewer asks for it. **Ancestry describes causation inside the operating system, not authorisation in the real world.** An adversary who gains code execution through the management agent — by compromising the agent's console, an operator's account, or the script content it distributes — inherits the agent's lineage exactly. The chain will root at `services.exe`, run as SYSTEM, and look like every other Tuesday. Some of the most damaging intrusions have arrived precisely this way, and the ancestry was innocent throughout because the ancestry was true. So the honest reading of a clean chain is: *this execution was caused by the agent*. It is not: *this execution was intended by the people who run the agent*. When the chain roots at automation, the remaining question is no longer "who started it" but "was the automation asked to do this", and that is answered by the decoded content and by the tool's own job records rather than by process telemetry. ## Practical routine For each alert: reconstruct the chain to its root; note the account, integrity level and session; verify the immediate parent's path and signer; decode the argument; then decide. For the workstation, escalate and start on what the user opened. For the fleet, record the lineage and the decoded script in the case, close as benign true positive, and note that the durable fix belongs to whoever owns the rule rather than to you at 03:00.
- Why is closing the fleet-wide case as a false positive the wrong label?Because the rule was right. It was written to catch encoded, hidden-window PowerShell, and that is exactly what happened; the activity was simply authorised. That is a benign true positive. Calling it a false positive tells the rule's owner their logic is broken and invites them to weaken matching that is working, when the real question is how sanctioned automation is recognised without blinding the rule to the same behaviour from elsewhere.
- The parent is named like the vendor's helper binary but runs from a user-writable temporary directory. What now?Treat the chain as unexplained. The lineage claim rests on the parent being the real component, and a matching filename in the wrong location is a common way to borrow trust. Compare the image path against the vendor's install directory, check the signer, and check whether the same name appears from that path anywhere else. Until the parent's identity holds up, its explanatory power does not.
- How would you notice an intruder running commands through the management agent, if the ancestry looks normal?Not from the chain, which is genuinely innocent. You look at the content and the schedule instead: a decoded script that does not match what the tool exists to do, an execution outside the agent's maintenance window, a job the tool's own console has no record of, or a target set that no operator recognises. Ancestry establishes cause; only the agent's own job records establish authorisation.
saying these in an interview costs you the question
- Closes the sanctioned case as a false positive
- Decides on the child process before reading the root
- Accepts the parent's filename as its identity
- Says a SYSTEM-rooted chain is automatically trusted
- Claims a clean ancestry rules out an intruder