Detection engineering has matured significantly over the past decade. We now have standardized rule formats like Sigma, comprehensive frameworks like MITRE ATT&CK, and detection-as-code practices embedded in CI/CD pipelines. Yet despite this progress, a fundamental problem persists: our detection rules often fail to detect what they were designed to catch.
These failures aren’t always due to missing telemetry or sophisticated evasion techniques. Many stem from something far more preventable — bugs in the detection logic itself.
Enter the Adversarial Detection Engineering (ADE) Framework, a new open-source project created by Nikolas Bielski and myself, that provides a formal taxonomy for understanding, classifying, and proactively identifying detection logic bugs before threat actors exploit them.
The Hidden Problem: Detection Logic Bugs
Every detection rule embodies an intention — what the rule is meant to catch. But there’s often a gap between that intention and what the rule’s logic actually implements. This gap is what the ADE Framework calls a Detection Logic Bug.
Consider a simple example: a rule designed to detect PowerShell downloading files might look for Invoke-WebRequest in the command line. The intention is clear—catch PowerShell-based downloads. But PowerShell offers multiple ways to accomplish the same task: wget, curl (aliases), System.Net.WebClient, Start-BitsTransfer, and more. If the rule only checks for Invoke-WebRequest, it contains a logic bug that creates a predictable false negative.
This isn’t a tuning issue or a data quality problem. It’s a structural flaw in how the detection logic was written.
The ADE Framework argues that these bugs follow predictable patterns and can be systematically identified — if we know what to look for.
Thinking Like an Attacker
The core insight behind ADE is deceptively simple: instead of waiting for real-world false negatives to reveal themselves in incident response, detection engineers should proactively ask:
“What variations would cause this rule’s detection logic to miss what it was intended to catch?”
This adversarial line of reasoning mirrors how threat actors already think. Red teamers and malware authors routinely study detection rules to find bypasses. The ADE Framework formalizes this process for defenders, giving them a structured approach to anticipate weaknesses before they’re exploited.
The ADE Taxonomy: Four Categories of Logic Bugs
The framework organizes detection logic bugs into four top-level categories, each containing specific subcategories with concrete examples and bypass techniques.
ADE1: Reformatting in Actions
These bugs occur when attackers can achieve the same malicious outcome by reformatting how an action is expressed. The detection rule looks for one specific representation while missing equivalent alternatives.
ADE1–01: Substring Manipulation
Rules often match specific strings in command lines, file paths, or other fields. Attackers can bypass these by splitting strings, using encoding, inserting characters, or leveraging case sensitivity.
Example: A rule detecting OpenProcess in PowerShell scripts can be bypassed by concatenating substrings:
$addr = Get-ProcAddress kernel32.dll $(“Open” + “Process”)
The function call still executes, but the literal string OpenProcess never appears in the script block.
ADE2: Omit Alternatives
Perhaps the most common category, these bugs arise when rules check for one method of achieving an objective while ignoring functionally equivalent alternatives.
ADE2–01: API/Function Alternatives
Operating systems and applications typically offer multiple APIs or functions that accomplish the same task. A rule targeting one API misses attacks using alternatives.
Example: Detecting credential dumping via MiniDumpWriteDump misses attacks using NtReadVirtualMemory or direct memory reads via /proc/pid/mem on Linux.
ADE2–02: Versioning
Software evolves, and so do the artifacts it generates. Rules built for one version may miss attacks on newer or older versions.
Example: A rule detecting a specific registry key used by one version of an implant fails when the implant updates its persistence mechanism.
ADE2–03: Locations
Malicious activity can often occur in multiple locations. Rules focusing on one path miss activity in alternatives.
Example: Monitoring C:\Windows\Temp for suspicious executables misses the same behavior in C:\Users\Public, %APPDATA%\Local\Temp, or even the recycle bin.
ADE2–04: File Types
The same payload can often be delivered in different file formats or extensions.
Example: Blocking .js files but not .jse (encoded JScript) allows trivial bypass.
ADE3: Context Development
These bugs involve manipulating the context in which malicious activity occurs — essentially gaming how detection systems correlate and aggregate events.
ADE3–01: Process Cloning
Detection rules often track parent-child process relationships. Attackers can break expected chains by injecting into other processes or using intermediate launchers.
Example: A rule detecting cmd.exe spawned by outlook.exe is bypassed when the attacker renames a copy ofcmd.exe to svchost.exe.
ADE3–02: Aggregation Hijacking
Rules that rely on thresholds or counts over time can be bypassed by distributing activity below detection thresholds.
Example: A rule alerting on 10+ failed logins in 5 minutes is bypassed by attempting 9 logins per 5-minute window across hours.
ADE3–03: Timing and Scheduling
Some rules have temporal assumptions that can be exploited.
Example: A rule monitoring for suspicious activity during business hours misses scheduled tasks executing at 3 AM.
ADE3–04: Event Fragmentation
A command entered via CMD can be fragmented across separate events.
Example: A rule that detects the command “findstr | lsass” by using a “contains all” condition will never hit because the pipe (|) character in CMD (when not preceded by cmd.exe /c) will split a command into separate event logs.
What ADE Is (and Isn’t)
It’s worth clarifying the framework’s scope. ADE focuses specifically on detection logic bugs — structural problems in how rules are written that cause them to miss their intended targets.
ADE does not cover:
- Data quality issues: Missing logs, unreliable telemetry, or inconsistent data sources are deployment problems, not logic bugs.
- Tuning issues: Rules that are too broad and generate excessive false positives aren’t logic bugs — they’re overly sensitive but not structurally broken.
- Coverage gaps: Attacks using completely novel techniques that no existing rule attempts to detect aren’t logic bugs in existing rules.
This focused scope is intentional. By narrowing the problem space, ADE provides actionable guidance that detection engineers can apply to individual rules.
How to Use the Framework
The ADE Framework is designed for practical application:
- Study the taxonomy. Understand the categories and subcategories, along with their characteristic patterns.
- Review your rules through an adversarial lens. For each rule, systematically walk through the ADE categories and ask: “Does this rule have this type of bug?”
- Use the Bug Likelihood Test. The framework includes a quick checklist to help identify the most likely bugs in any given rule.
- Document and iterate. When you find potential bugs, document them and update your rules or create companion rules for coverage.
The framework integrates naturally with existing detection engineering workflows. It’s particularly valuable during the “Improvement Phase” of detection engineering lifecycles, providing a structured lens for identifying rule weaknesses.
Complementing Existing Frameworks
ADE doesn’t compete with existing detection engineering resources — it fills a gap they don’t address.
MITRE ATT&CK provides a comprehensive taxonomy of adversary techniques, giving us the what to detect. But it doesn’t address how detection logic can fail.
Sigma and similar rule formats standardize how we write detection rules, enabling portability across platforms. But they don’t tell us whether our rules are logically sound.
Detection Engineering Lifecycle frameworks describe the process of building and maintaining detection capabilities. ADE provides a complementary lens for the improvement and validation phases.
ADE fills this gap by providing the first formal theory and taxonomy of detection logic failures.
Getting Started
The ADE Framework is open source and available on GitHub. The repository includes:
- Theory documentation: Foundation concepts and definitions
- Full taxonomy: All categories and subcategories with examples
- Bug Likelihood Test: Quick-start checklist for rule review
- Individual category deep-dives: Detailed guidance for each bug type
The project is actively seeking contributors to help expand the taxonomy, build static analysis tools for automated bug detection, and create a repository of documented logic bugs from real-world rulesets.
Conclusion
Detection engineering has long been a craft, learned through experience and failure. The Adversarial Detection Engineering Framework begins to turn it into a discipline with formal foundations.
By systematically cataloging how detection logic fails, ADE empowers defenders to think like attackers — proactively identifying weaknesses before they’re exploited in the wild.
The framework won’t eliminate false negatives entirely. Some attacks will always slip through. But many of the bypasses that work today succeed not because attackers are brilliant, but because defenders made predictable mistakes in their detection logic.
Those mistakes now have names. And when problems have names, they become solvable.
Resources:
- GitHub Repository: Adversarial Detection Engineering Framework
- Framework Website: adeframework.org
Interested in contributing? The project welcomes help with static analyzer development, taxonomy expansion, and documentation of real-world detection logic bugs.
Introducing the Adversarial Detection Engineering Framework: A Taxonomy for Detection Logic Bugs 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.