Adversarial-Detection-Engineering/adeskills

What it is

Adeskills is a knowledge base implementing the "ADE" taxonomy for reasoning about detection-rule false negatives — mismatches between what a SIEM/EDR/XDR rule intends to catch and what it actually catches. It organizes 38 worked technique files under four bug categories: ADE1 Reformatting in Actions, ADE2 Omit Alternatives, ADE3 Context Development, ADE4 Logic Manipulation, each split into named subcategories (e.g., ADE1-01 Substring Manipulation, ADE3-06 Limit Saturation, ADE4-01 Gate Inversion).

How it works

Each worked technique file carries YAML frontmatter (id, ade_category, ade_subcategory, mitre_attack tags, platform, testable) and a fixed body: Summary → ADE Classification → The Technique → Vulnerable Rule → Hardened Rule → Detection Layers → Implementation Nuances → References. Summary, ADE Classification, Detection Layers, and Implementation Nuances are present in every file; Vulnerable/Hardened Rule and References are typical but not guaranteed. Some files include a "Documented instances" table naming specific affected vendor rules, grounded in analysis of real Sigma, Elastic Security, and Microsoft Sentinel rulesets.

Preconditions / Affected

Applies to rule authors/testers working directly with Sigma, Elastic Security, or Microsoft Sentinel detection content, since the bug patterns were derived from those three platforms' public rulesets. Use requires explicit written authorization before testing detections or systems not owned/operated by the user — detection/monitoring content is generally out of scope for vendor bug-bounty and vulnerability-disclosure programs, so findings should be handled under responsible-disclosure norms rather than filed as bugs.

What to do

Beyond the 38 technique files, the repo provides concrete workflow tooling:

• bug-likelihood-test.md — a fast pre-analysis heuristic to triage whether a given rule is worth deeper review
• mitigations.md — fixes organized per ADE category, with a per-platform section
• ade-checklist.md — the four false-negative "lenses" for pre-engagement scoping
• rulesets.md — where to find public rulesets and how to search them
• redamon/ — a packaged skill (ade_scoper) for scoping engagements

Each technique file's Vulnerable Rule → Hardened Rule pair is the direct artifact to copy when auditing an existing rule of that subcategory.

flowchart LR
    A[Candidate rule] --> B[bug-likelihood-test.md heuristic]
    B -->|worth reviewing| C[Match against ADE1-4 subcategories]
    B -->|low likelihood| H[Skip]
    C --> D[Compare to Vulnerable Rule pattern]
    D --> E[Apply Hardened Rule / mitigations.md]
    E --> F[Verify via Detection Layers]

Caveats

The page itself notes several sections (Vulnerable Rule, Hardened Rule, References) are "typical but not universal," so not every one of the 38 files will contain a ready-made before/after rule pair. Licensed MIT with attribution required, provided "as is" without warranty.