A detection rule can be wrong in two directions. Fire when nothing happened, and you’ll hear about it fast; every analyst who burns an afternoon chasing a false positive comes looking for whoever wrote the rule. The other failure is quiet. The rule reads correctly, passes review, ships to production, and then never matches the thing it was written to catch. Nothing errors and nothing alerts. Coverage you think you have simply isn’t there, and nothing tells you so.
Most of my work comes down to anchoring detections to artifacts an attacker can’t easily change, then taking binaries apart to learn what those artifacts really are. The lesson that keeps repeating is that the dangerous gap is almost never the technique nobody thought of. It’s the technique everybody thought of, written into a rule that matches only one spelling of it. Nikolas Bielski and I packaged that habit of mind into a public repository, ADE Skills, an Adversarial Detection Engineering knowledge base. This post will introduce it.
What “adversarial detection engineering” means
Detection engineering usually gets framed as coverage. Map your techniques, write the rules, check the boxes. Adversarial detection engineering asks a smaller and more useful question about every rule already on the board: what has to be true for this to fire, and how far can the real technique drift from the textbook version before the rule goes quiet?
So ADE is really the study of the distance between what a rule means to catch and what it literally catches. Attackers live in that distance. They rarely need a novel exploit. They need the same command written a way the rule didn’t anticipate, or the same action done slowly enough to slip under an aggregation threshold, or a log source that was never turned on for that class of host. These things aren’t exotic: they’re the ordinary shape of evasion, and you can see most of it coming if you read a rule the way an adversary reads it.
The taxonomy
At the center is a taxonomy of detection-logic bugs: the reasons a sensible-looking rule fails to fire. Four categories, fifteen subcategories, thirty-seven worked technique files.
ADE1, Reformatting in Actions. The logged input gets reshaped so the string match breaks. NTFS 8.3 short names that turn C:\Program Files into C:\PROGRA~1, PowerShell tick-escaping, quote and whitespace tricks, environment-variable splicing.
ADE2, Omit Alternatives. The rule lists a subset of an equivalence class and misses the rest. certutil -urlcache is watched, while -verifyctl, -decode, and -URL reach the same outcome and aren’t. powershell.exe is on the list; pwsh.exe isn’t. Almost every LOLBin has a cousin the rule forgot to name.
ADE3, Context Development. Here the attacker shapes the context around the action instead of the action itself: cloning a trusted process name, spreading activity across entities to stay under a count, waiting out a correlation window, splitting one logical event into several, spoofing a parent process.
ADE4, Logic Manipulation. The Boolean, filter, or field logic is inverted or just wrong. The case I keep coming back to is a negated filter that references a field which doesn’t exist on the customer’s telemetry. Depending on how the backend evaluates a comparison against a missing field, that exclusion either swallows every true positive or quietly switches itself off. The same Sigma rule can break in opposite directions on two different SIEMs, because the author was thinking in two-valued Boolean logic while the backend runs three.
Every technique file follows one spine: a summary, the ADE classification, the technique itself, a vulnerable rule, a hardened rule, the detection layers that would still catch it, implementation nuances, and references. A good number are tied to specific real findings and name the vendor rules involved.
What’s in the repository
Platform bug-pattern catalogs: Cross-cutting references plus specific ones for Elastic Security, Microsoft Sentinel, and Sigma: the mistakes that recur on each platform, from command-line obfuscation to logging assumptions that quietly don’t hold. Windows 4688 command-line auditing is off by default. Script block logging disappears after a PowerShell v2 downgrade. WSL2 shenanigans.
The false-negative checklist: Four lenses to run over any rule you find in the wild. Does the rule even receive the data it needs? Does it hinge on a threshold that a slower version of the technique falls under? Does it cover one binary, protocol, or version when others are in scope? Is it tuned against a baseline that doesn’t match this environment? The checklist stays at the level of “would this catch the technique, and what has to be true for it to fire.” It produces client questions and validation objectives, not attack recipes.
A findings catalog: A machine-extracted catalog of close to 600 candidate bypass findings (593 at the time of writing), mined from public rulesets across Elastic, Sentinel, and Sigma, each mapped to the taxonomy with the affected fields, the gap, and a suggested fix. Treat it as a browsing surface rather than a target list. The point isn’t any single row. It’s how often the same category of gap turns up across vendors who never compared notes.
Redamon: A purple-team scoping skill that replans adversary emulation around whatever SIEM or EDR stack a target actually runs, maps in-scope techniques to that stack’s public rules, and uses the taxonomy to derive validation objectives and hardening recommendations. Based on the “Redamon” github repo.
What you can use it for
The first is hardening your own detections. Pick a rule you own, run it through the four lenses and the matching category, and you’ll usually turn up at least one member of the equivalence class you never enumerated, or one telemetry assumption you never checked. The hardened-rule sections show what the fix tends to look like.
The second is scoping a purple-team engagement. The checklist and Redamon turn a vague “test our detections” into a worksheet of validation objectives tied to specific rules and specific gaps. That’s the kind of thing a human red-team lead can turn into a test that actually answers whether the coverage you assume is real.
And if you’re newer to this, the worked files are a good way to build the instinct. You stop reading a rule as a description of what it catches and start reading it as a boundary you can measure. That shift is most of the job.
A word on intent
This is defensive material, and the repo says so plainly. Every technique file carries its own guardrails, the reasoning stays at the level of categories of gap rather than tuned bypass recipes, and the goal is to close false negatives, not to arm them. Detection content usually sits outside vendor vulnerability-disclosure and bug-bounty scope, so use responsible-disclosure judgment with the examples. And get authorization before you test anything you don’t own.
Detection engineering is a craft, not a compliance exercise, and the craft lives in the gap between what a rule intends and what it does. ADE Skills is our attempt to map that gap in the open.
The repo is at github.com/Adversarial-Detection-Engineering/adeskills. MIT licensed. If you find a category of gap we missed, that’s the contribution I’d most like to see.
If you enjoyed the article, feel free to connect with me!
https://www.linkedin.com/in/daniel-koifman-61072218b/
https://x.com/KoifSec
https://koifsec.me
https://bsky.app/profile/koifsec.bsky.social
Introducing ADE-Skills — Adversarial Detection Engineering Knowledge Base was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.