The alert that turned out to be the software working: what was yours?

I published the first False-Positive Hall of Fame this week, and every entry in it came out of somebody else's rule file rather than out of an estate I have worked in. That is the wrong ratio for a format like this, so I am starting the fix here.

Three that made the article, to show the shape:

- Chrome creates named pipes called `mojo.<pid>.<tid>.<number>`, and two of those exact names ended up hardcoded in public Cobalt Strike malleable profiles. So the rule matches Chrome. - Google's updater opens a handle to LSASS. That is the marquee credential-theft detection on Windows, firing on a software update. - An endpoint management agent deleting shadow copies through encoded PowerShell. Every aggravating factor at once, and it is the patch window.

What those three have in common is that somebody wrote the false positive down. That is rarer than it should be. Counting the `falsepositives:` field across the SigmaHQ rules directory on 9 September, 1,551 of 3,144 rules answer it with a single "Unknown" or "Unlikely". Just under half the public rulebase ships with no usable statement of what else it hits, which means the research is homework nobody has done and you end up doing it in production, with your own analysts' nights.

So: what fired on you that turned out to be the software working?

Two things make an entry usable to somebody else:

1. It has to be reproducible. The rule, or the alert text, so a reader can go and find it in their own console. 2. The discriminator has to be a real query, not "we tuned it out". Suppressing the rule is not a discriminator, it is a decision to stop looking.

I would rather have three entries with a working discriminator than thirty war stories, so take your time. Anything that goes into the next one is credited to you by name if you want it, and left anonymous if you would rather.