Malicious or Normal

## Three verdicts, not two A detection is a rule over records; an alert is one firing of that rule. When you judge a firing you are answering two separate questions, and collapsing them is the most common triage error at this level. 1. **Did the rule match what it was written to match?** 2. **Was the behaviour it matched an adversary?** That gives three outcomes: | Verdict | Rule matched its intent | Behaviour was malicious | |---|---|---| | True positive | yes | yes | | **Benign true positive** | yes | no — it was authorised | | False positive | no | n/a — the match itself was wrong | A **false positive** is a defect in the detection. The rule claimed to have seen a behaviour it did not see: a command-line substring collided with an unrelated argument, a field means something different on this platform, a parser split a quoted path, a decoder mangled the record. Nothing suspicious happened, and nothing *matching* happened either. A **benign true positive** is not a defect. The command really ran, in the form the author described, and the only reason it is not an intrusion is context the rule cannot see: the account belongs to the packaging team, the host's whole job is to fetch and repackage vendor installers, there is an open change record, or it was a scheduled red-team exercise you were not told about. ## Why the distinction is operational, not pedantic The remedy differs, and applying the wrong one damages you in opposite directions. - For a **false positive**, you change the rule's logic — anchor on the process image rather than a raw substring, match the argument shape properly, fix the field mapping. The detection gets *more* accurate. - For a **benign true positive**, the logic is already correct. Editing it to make the noise stop usually means narrowing the rule until an adversary can adopt the identical command line and no longer trip it. Instead you scope an **exception** — keyed as tightly as you can to the host group, the service account and the argument pattern, with an owner, a reason and an expiry — or you add **enrichment** so the packaging context is rendered in the alert and the next analyst spends thirty seconds instead of ten minutes. Every exception is a documented blind spot: an adversary who lands on that host inherits it, which is why the scope and the expiry matter. There is also a measurement consequence. A rule's false-positive count is the argument used for and against keeping it. If your analysts close authorised-but-flagged activity as "false positive", the rule's record shows an inaccurate detection, and someone will eventually weaken or delete a rule that is working perfectly. The estate knowledge — *this behaviour is normal on these forty hosts* — is also lost, because it was recorded as a rule fault rather than an environmental fact. ## The signed-binary trap `certutil.exe` is a Microsoft-signed utility that ships with Windows. Candidates routinely offer the signature as the reason the alert is benign. It is not. A valid signature establishes that the file on disk is the one Microsoft published and has not been tampered with. It says nothing about who invoked it, with what arguments, or to what end. Living-off-the-land tradecraft exists precisely because these binaries are signed, present everywhere and permitted by application control; ingress tool transfer via `certutil -urlcache -split -f <url> <file>` (ATT&CK `T1105`) is popular for exactly that reason. Signature status is a property of the image; maliciousness is a property of the invocation. ## Authorised is not the same as safe One more direction check. "The account was allowed to do this" answers a different question from "a legitimate person did this". If the packaging service account's credential has been stolen, everything the adversary does through it is authorised and none of it is benign. So the confirmation matters: an open change record, a ticket, a build job that explains the fetch, or a check with the owning team through a channel the suspect account does not control. Asking through the potentially compromised account or its mailbox is asking the adversary. ## What a good answer sounds like "Benign true positive — the rule fired on exactly the behaviour it describes, and the activity was authorised. I'd close it with the reason recorded, not as a false positive, because the rule isn't broken. If this host group produces it daily I'd propose a scoped exception or enrichment rather than touching the logic, and I'd want a change record or a check with the packaging team's owner before I treat 'authorised' as settled."