What does an EDR verdict of 'clean, signed binary' actually prove about a process?
answer
- two claims wearing one word
- signature covers origin, not behaviour
- one sensor, one rule set, one window
- absence of a match is not absence
basics
~20 sOnly two narrow things: the file chains to a trusted publisher certificate and is unmodified since signing, and no rule in that one product matched the telemetry the agent collected. Neither claim is about the process's behaviour.
solid answer
~50 sThat one line bundles two separate claims, and neither says the activity was benign. A valid signature proves origin and integrity — the file chains to a certificate the OS trusts and has not been altered since signing. It says nothing about what the process did, and signed legitimate software is routinely driven to do harmful things. `Clean` means no rule or model in that product matched the records the agent produced, on that host, in that window. Silence has three innocent-looking causes: the behaviour was never in the telemetry, no rule expresses it, or the agent was not reporting. So a detection firing proves a rule matched; a detection not firing proves nothing about the estate. I would write the verdict into the case note as claim plus basis plus window, then pivot to what the process actually did.
go deeper
Be ready to separate the two claims out loud: signature equals origin and integrity, clean equals no rule matched this sensor's records. Say explicitly that neither is a statement about the process's behaviour.
Explain what endpoint telemetry actually contains — process creation, module loads, file writes, connection metadata — and name the three reasons a product can be silent: no telemetry, no rule, no agent.
Show that you check agent health and coverage before crediting a clean verdict, and that you record verdicts as claim plus basis plus window so a later analyst cannot close an investigation on a sensor that never observed the behaviour.
Own the consequence for the tooling portfolio: if a product's negative verdicts are read as assurance, you are paying for a control and getting a false comfort signal. Insist that every console's output be expressed as a bounded claim before it is trusted anywhere.
## One line, two claims An endpoint detection and response (EDR) console hands the analyst a single short verdict — *clean, signed* — and analysts routinely read it as "this process was fine". It is nothing of the sort. The line bundles two claims produced by two different mechanisms, and neither of them is a statement about behaviour. ## Claim one: the signature validates Code signing works by hashing the file and signing that hash with a private key whose certificate chains to a root the operating system trusts. Verification establishes exactly two facts: the file has not changed since it was signed, and whoever signed it held the private key for that certificate. That is a claim about **origin and integrity**. It is not a claim about intent or effect: - Legitimate, correctly signed software does damaging things when an adversary drives it. Signed administrative tooling, signed scripting hosts and signed remote-access clients are all genuine, all validly signed, and all abusable. - Signing keys and certificates get stolen, and signing services get abused, so even the "who signed it" half is a trust assumption rather than a proof of good faith. - The signature covers the bytes on disk. It says nothing about the command line the process received, the accounts it authenticated as, or the network conversation it then had. ## Claim two: nothing matched `Clean` means: over the records **this agent produced**, on **this host**, in **this window**, no rule or model in **this product** matched. It is a negative result from one sensor with one detection set. It can be silent while an intrusion is running, for at least three reasons: 1. **The behaviour was never in the telemetry.** Endpoint agents typically collect process creation with command lines and parent images, module loads, file and registry writes, and network connection metadata. They do not see the contents of an encrypted request body, and they see nothing at all about an action an adversary takes inside a SaaS tenant that never touches an endpoint you monitor. 2. **The behaviour is in the telemetry but no rule expresses it.** A rule that does not exist cannot fire, and a product's coverage of a technique is not something the verdict tells you. 3. **The agent was not reporting.** Uninstalled, unhealthy, an excluded path, an unmanaged host, a machine class that was never onboarded. Silence from a sensor that stopped talking looks identical to silence from a quiet host. ## The direction of the claim, which is the actual interview point - A detection **firing** proves a rule matched a record. It does not prove something malicious happened — that is what triage is for. - A detection **not firing** proves nothing about the estate. Absence of evidence from one sensor is not evidence of absence. This asymmetry is why a clean endpoint verdict cannot be used to close an investigation that a different sensor opened. It is also why, when several consoles return verdicts on one event, counting them as votes is a mistake: a product that never observed the relevant surface is silent, not corroborating. ## A worked case where every word of the verdict is true and useless Suppose an adversary runs command and control through a legitimate collaboration platform's own API — tasking and results carried as ordinary messages and file uploads in a workspace, using the vendor's genuine, signed desktop client or a valid API token. The binary is authentic. The signature validates. The parent-child process chain is unremarkable. No implant was dropped. The entire malicious element is the *content* of the traffic, which the endpoint verdict never examined and the file verdict cannot examine in principle. "Clean, signed" is factually correct and answers a question nobody asked. ## How to use the verdict honestly Restate it in the case note as **claim + basis + window + surface**, not as a conclusion: > EDR: no detection on process-creation, module-load and file-write telemetry from `HOST-07`, 09:00–11:00 UTC. Agent healthy and reporting throughout. Binary signature valid, publisher `Vendor X`. Written that way it becomes usable evidence. It argues against one hypothesis — an unsigned implant dropped and executed on that host in that window — while making no claim about hypotheses the sensor could not test. It also forces the check that matters most: **was the agent alive?** A verdict computed over no telemetry is not a verdict. Then pivot from the file to the behaviour: what child processes did it create, which accounts and tenants did it authenticate to, what did the platform's own audit trail record, where did the traffic go and how much of it was there. Those questions have answers; "is the binary signed" does not have the answer people read into it.
- The binary turns out to be signed with a stolen certificate. Does anything in the verdict change?Not the mechanics. Verification still says the file chains to a trusted certificate and is unmodified, because that is all it ever checked. What changes is your trust in the assumption behind it: a signature is a claim about who held a key, not about whether that party intended the release. Treat publisher trust as revocable evidence, and pivot to behaviour rather than re-running the file check.
- How would you write that clean verdict into the case notes so the next analyst is not misled?As a claim with its basis, window and surface: `no EDR detection on process, module and file telemetry from HOST-07 between 09:00 and 11:00, agent healthy`. That is falsifiable and bounded. `EDR says clean` is not — it invites the next analyst to close an investigation on a sensor that never observed the behaviour in question.
- The signed binary is a legitimate collaboration client. What do you look at next?What it did rather than what it is. Which account and workspace it authenticated to, the platform's own audit trail for that account, the volume and direction of data it moved, whether the host class has any business talking to that platform at all, and what child processes it spawned. The maliciousness, if any, lives in the traffic and the tenant, not in the file.
saying these in an interview costs you the question
- Says a valid signature means the vendor vouched for the behaviour
- Treats no EDR alert as proof the host is clean
- Reads absence of a detection as evidence the activity did not happen
- Assumes every host has a healthy agent reporting all the time
- Cannot say what telemetry the verdict was computed over