Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
Adversarial-Detection-Engineering-Framework — Ein Framework und eine Taxonomie zur Identifizierung, Klassifizierung und Begründung von Erkennungslogikfehlern in SIEM-, EDR- und XDR-Regeln, mit konkreten Beispielen und realen Umgehungen. | Kitploit
Tools/GitHubGitHub/adversarial-detection-engineering/adversarial-detection-engineering-framework
DefensivwerkzeugeSchwachstellenanalyseIDS/IPS-UmgehungPenetrationstestsBedrohungsanalyseLernen & BildungRed TeamingIncident ResponseKuratierte Ressourcen

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Log-Analyse
GitHubadversarial-detection-engineering/adversarial-detection-engineering-framework

Adversarial-Detection-Engineering-Framework

Ein Framework und eine Taxonomie zur Identifizierung, Klassifizierung und Begründung von Erkennungslogikfehlern in SIEM-, EDR- und XDR-Regeln, mit konkreten Beispielen und realen Umgehungen.

Repository anzeigen
5984vor 6 MonatenVon Kitploit geprüft
Teilen

Adversarial Detection Engineering (ADE) Framework

Author GitHub Last Commit GitHub License

Sei False Negatives voraus, indem du verstehst, wie Erkennungslogik versagt, bevor Bedrohungsakteure sie missbrauchen.

Besuche die Website: https://adeframework.org/

Was ist ADE?

Adversarial Detection Engineering (ADE) ist die Disziplin des Nachdenkens über False Negatives in Erkennungsregeln. Das ADE Framework bietet eine moderne Open-Source-Formalisierung von Detection Logic Bugs – Diskrepanzen zwischen dem, was eine Erkennungsregel erkennen soll, und dem, was sie tatsächlich erkennt.

Der ADE-Vorteil

Anstatt auf reale False Negatives zu warten, können Detection Engineers proaktiv fragen:

"Welche Variationen würden dazu führen, dass die Erkennungslogik dieser Regel das verpasst, was sie erkennen sollte?"

Diese gegnerische Denkweise spiegelt wider, wie Bedrohungsakteure Schwächen in der Erkennungslogik ausnutzen können.

Hauptmerkmale

  • ✅ Reproduzierbare Detection Logic Bugs identifizieren und sie den formalen ADE-Kategorien zuordnen
  • ✅ Das geistige Modell eines Angreifers einbetten in die Gestaltung und Überprüfung der Erkennungslogik
  • ✅ Strukturelle Schwächen aufdecken in Regeln, die für Jagd oder produktive MDR-Tools verwendet werden
  • ✅ Sicherheitsteams ausstatten mit umsetzbarer Intelligence zu Detection Logic Bugs
  • ✅ False Negatives voraus sein, bevor Bedrohungsakteure sie entdecken und ausnutzen

ADE-Zweck

Der Zweck von ADE ist nicht, Perfektion im Design zu erzwingen, obwohl das ein ideales Ziel ist – sondern Bewusstsein zu schaffen und Einschränkungen zu verfolgen, selbst wenn sie beabsichtigt sind:

  • ADE geht es nicht darum, perfekte Erkennungsregeln zu fordern; es geht darum, das Risiko von False Negatives sichtbar zu machen.
  • Viele Regeln enthalten absichtlich Einschränkungen aufgrund von Umfang, Signalqualität oder betrieblichen Zwängen, und diese können dennoch ADE-Fehlertypen zugeordnet werden, ohne dass sie 'falsch' sind.
  • ADE bietet eine gemeinsame Möglichkeit, diese Risiken über ein Regelwerk hinweg zu dokumentieren, zu akzeptieren, zu mindern oder zu kompensieren, anstatt einzelne Regeln isoliert zu bewerten.

ADE-Verbindung zu Detection Logic Exposures (DLE)

  • ADE liefert eine kanonische Taxonomie und Fehlerklassen für Detection Logic Bugs.
  • DLE bietet eine anerkannte Liste öffentlich offengelegter Bypässe mit ADE-Zuordnungen.

Schnellstart

Neu bei ADE? Beginne hier:

  1. Einführung - Verstehe, was ADE ist und warum es wichtig ist
  2. Grundkonzepte - Lerne die grundlegende Terminologie
  3. Schnellstart-Anleitung - Wende ADE auf deine erste Erkennungsregel an
  4. Bug Likelihood Test - Kurze Checkliste zur Bewertung von Regeln auf Fehler

Bereit für tiefere Einblicke?

  • Detection Logic Bug Theory - Formale Grundlagen
  • Taxonomie-Übersicht - Alle Fehlerkategorien
  • Beispiele - Beispiele aus der Praxis

ADE-Taxonomie der Detection Logic Bugs

Das Framework identifiziert 4 Hauptkategorien und 13 Unterkategorien von Detection Logic Bugs:

root@kitploit:~
🌳 ADE1 – Reformatting in Actions
    ├─ ADE1-01 Substring Manipulation
    └─ ADE1-02 Normalization Asymmetry

🌳 ADE2 – Omit Alternatives
    ├─ ADE2-01 Method/Binary
    ├─ ADE2-02 Versioning
    ├─ ADE2-03 Locations
    └─ ADE2-04 File Types

🌳 ADE3 – Context Development
    ├─ ADE3-01 Process Cloning
    ├─ ADE3-02 Aggregation Hijacking
    ├─ ADE3-03 Timing and Scheduling
    └─ ADE3-04 Event Fragmentation

🌳 ADE4 – Logic Manipulation
    ├─ ADE4-01 Gate Inversion
    ├─ ADE4-02 Conjunction Inversion
    └─ ADE4-03 Incorrect Expression

→ Erkunde die vollständige Taxonomie

Was das Framework bietet

1. Theorie der Detection Logic Bugs

Formale Definitionen und theoretische Grundlage:

  • Was einen Detection Logic Bug ausmacht
  • Wie Fehler False Negatives erzeugen
  • Beziehung zwischen Umfang und Erkennungslogik
  • Konzept von Rule Bypasses

2. Formale Fehlertaxonomie

Umfassende Klassifikation mit klarer Terminologie:

  • 4 Hauptkategorien
  • 13 detaillierte Unterkategorien
  • Einheitliches Bezeichnungssystem (ADE1-01, ADE2-01 usw.)
  • Zuordnung zu realen Erkennungsregeln

3. Beispiele aus der Praxis

Konkrete Beispiele aus produktiven Regelsätzen:

  • Sigma-Erkennungsregeln
  • Microsoft Sentinel-Analysen
  • Elastic Security SIEM- & EDR-Regeln

Beispielkategorien:

  • ADE1-Beispiele - String-Manipulations-Bypässe
  • ADE2-Beispiele - Ausgelassene Alternativen
  • ADE3-Beispiele - Kontextentwicklung
  • ADE4-Beispiele - Logikmanipulation

4. Praktische Werkzeuge

  • Bug Likelihood Test - Kurze Voranalyse-Checkliste
  • Schnellstart-Anleitung - Schritt-für-Schritt-Anwendungsprozess

Wie ADE bestehende Frameworks ergänzt

ADE integriert sich in bestehende Detection-Engineering-Praktiken und verbessert sie:

FrameworkSchwerpunktADE-Integration
MITRE ATT&CKAngriffstechniken & -taktikenADE erklärt, warum die Erkennung für ATT&CK-Techniken fehlschlägt
MITRE CARRepository für ErkennungsanalysenADE bietet eine Fehlertaxonomie für CAR-Analysen
Detection Engineering LifecyclePhasen des Engineering-WorkflowsADE ist das Reasoning-Framework für die Verbesserungsphase
Sigma/YARA/KQLRegelsyntax & -formatierungADE analysiert semantische Logikfehler über alle Abfragesprachen hinweg

ADE's einzigartiger Wert: Formale Klassifikation auf Logikebene der Ursachen von False Negatives

Betreuer

  • Nikolas Bielski - Framework-Autor & Hauptbetreuer
  • Daniel Koifman - Co-Betreuer

Mitwirken

Wir begrüßen Beiträge! Bereiche der aktiven Entwicklung sind:

Hohe Priorität

  • Entwicklung statischer Analysewerkzeuge - Tools zur Analyse von Erkennungsregeln auf potenzielle Logikfehler

    • Entwickelt für Detection-as-Code CI/CD-Pipelines
    • Unterstützung für IDE-Integration
  • Erweiterung des Bug-Repositorys - Kuratierte Sammlung identifizierter Fehler

    • Plattformübergreifende Regelanalyse
    • Bewertung von Anbieter-Regelsätzen
    • Von der Community eingereichte Bypässe

Allgemeine Beiträge

  • Verbesserungen der Dokumentation
  • Neue Beispiele von weiteren Anbietern/Plattformen
  • Verfeinerung der Taxonomie basierend auf neuen Techniken
  • Test-Frameworks und Validierungswerkzeuge

Details in CONTRIBUTING.md →

Anwendungsfälle

Für Detection Engineers

  1. Überprüfung vor der Bereitstellung - Wende die ADE-Taxonomie an, bevor du neue Regeln bereitstellst
  2. Systematische Verbesserung - Überprüfe vorhandene Regeln mit dem Bug Likelihood Test
  3. Dokumentation - Erfasse bekannte Einschränkungen, wenn Fehler nicht sofort behoben werden können
  4. Priorisierung - Konzentriere dich auf Fehler mit hohem Schweregrad

Für Sicherheitsforscher

  1. Bypässe formalisieren - Ordne entdeckte Umgehungen den ADE-Kategorien zu
  2. Entdeckungen beitragen - Erweitere die Taxonomie mit neuen Fehlerklassen
  3. Anbieteranalyse - Bewerte objektiv die Erkennungsfähigkeiten

Für Red Teams

  1. Realistisches Testen - Verwende ADE, um die Erkennungsfähigkeiten des Blue Teams zu testen
  2. Umsetzbares Feedback - Biete strukturierte Informationen zu Bypässen
  3. Trainingsszenarien - Entwickle Übungen zur Erkennungsumgehung

Für SOC/Threat Hunter

  1. Ursachenanalyse - Verstehe, warum Angriffe nicht erkannt wurden
  2. Abdeckungsbewertung - Identifiziere Lücken im Monitoring
  3. Anbieterbewertung - Teste Tools gegen die ADE-Taxonomie

Fahrplan

Geplante Entwicklungen:

  • 🔨 Static Analysis Tooling - Automatisierte Fehlererkennung für CI/CD
  • 📚 Erweitertes Bug-Repository - Von der Community getragene Sammlung

Lizenz

MerkmalWert
Basiert aufMIT license
VerbreitungJa
ModifikationJa
Private NutzungJa
Kommerzielle NutzungJa
HaftungNein
GarantieNein
Lizenz- und UrheberrechtshinweisJa
AutorenangabeErforderlich

Haftungsausschluss

⚠️ Wichtig: Dieses Framework ist ausschließlich für defensive Sicherheitsforschung, Detection Engineering und Risikobewertung gedacht. Sein Zweck ist es, Verteidigern zu helfen, Schwächen in der Erkennungslogik und Sicherheitsüberwachungssystemen zu identifizieren, zu analysieren und zu beheben. Die Benutzer sind allein dafür verantwortlich, dass ihre Nutzung allen geltenden Gesetzen, Vorschriften und Autorisierungsanforderungen entspricht. Die Autoren und Mitarbeiter übernehmen keine Haftung für Missbrauch, Schäden oder Beeinträchtigungen, die durch die Nutzung dieses Frameworks entstehen.

Autorisierung erforderlich: Holen Sie stets eine ausdrückliche schriftliche Genehmigung ein, bevor Sie Erkennungen, Systeme oder Kontrollen außerhalb von Umgebungen testen, die Sie besitzen oder betreiben.

Verantwortungsvolle Offenlegung: Beispiele werden unter Berücksichtigung der verantwortungsvollen Offenlegung bereitgestellt. Erkennungsregeln und Überwachungsinhalte fallen in der Regel nicht in den Rahmen von Schwachstellenoffenlegungen und Bug-Bounty-Programmen von Anbietern.

Keine Gewährleistung: Dieses Framework wird "wie besehen" ohne jegliche ausdrückliche oder stillschweigende Gewährleistung bereitgestellt.

Kontakt

  • GitHub Issues: Fehler melden oder Funktionen anfragen
  • LinkedIn: Nikolas Bielski | Daniel Koifman
Tool herunterladen