Detection written from the other side

Most detection logic is written from documentation, by people who have never had to evade it. Ours is written from the other side of the engagement.

Vendor rules describe techniques. They rarely describe what an operator does once the rule exists.

Consider the canonical encoded-command rule. It catches the tutorial version of the attack and very little else:

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has "-enc"

Operators moved off that syntax years ago, not because it was detected, but because it was loud enough to be worth avoiding. The rule stays in production, generates false positives, and gets tuned down until it fires on nothing. The technique it was written for keeps working.

The gap is not in the tooling. It is in who wrote the rule, and what that person had never been required to do.

We run the technique the way an operator runs it, including the variants that exist specifically to sidestep the obvious signature. A detection built against the documented version inherits the documentation’s blind spots.

Command lines are cosmetic. Process lineage, API call sequence, handle access patterns and privilege transitions are load-bearing. Break those and you break the technique, which is what makes them worth alerting on.

Every rule we write, we then attempt to evade. If we get past our own logic, the rule is not finished. This step is almost universally skipped, and it is why most detection content degrades the moment it meets a competent operator.

We take focused engagements rather than retainers, scoped against the threat groups actually targeting your sector. If you want to see the reasoning before you talk to us, the blog has full technical breakdowns of the work.