redsun-bluehammer-undefend-detection-pack

# Microsoft Defender XDR KQL-Erkennungen für RedSun-, BlueHammer-, UnDefend- und CVE-2026-33825-bezogene Defender-Missbrauchsverhalten.

Verifizierte Forschungs-Baseline

• Zuletzt verifiziert: 2026-05-05
• BlueHammer: CVE-2026-33825; behandeln Sie Defender Antimalware Platform 4.18.26030.3011 oder neuer als die minimale verifizierte gepatchte Baseline, die in diesem Repository dokumentiert ist.
• RedSun: Bei der Quellenprüfung vom 2026-05-05 wurde kein öffentliches Microsoft-CVE oder Herstellerpatch verifiziert. Halten Sie dieses Paket verhaltensorientiert.
• UnDefend: Bei der Quellenprüfung vom 2026-05-05 wurde kein öffentliches Microsoft-CVE oder Herstellerpatch verifiziert. Halten Sie dieses Paket verhaltensorientiert.
• Familienübergreifender Eindringkontext: Huntress dokumentierte gemeinsame beobachtete Werkzeuge, BeigeBurrow-Folgeaktivitäten und Recon-Befehle, die für Hunting und Anreicherung nützlich sind, aber für sich genommen keinen deterministischen Beweis darstellen.

Repository-Struktur

Das Repository verwendet Paketordner sowohl für Erkennungsinhalte als auch für Supportinhalte. KQL-haltige Ordner verwenden eine fortlaufende Nummerierung, die bei 01 beginnt.

Abfrage-Entwurfsmuster

Die vier Vollketten-Erkennungspakete (RedSun, BlueHammer, UnDefend und CrossFamily) folgen derselben Struktur:

1. 01_*_full_attack_chain.kql ist die zusammengesetzte Jagd. Sie führt die gesamte Stufenlogik zusammen aus und korreliert Beweise auf demselben Gerät innerhalb eines definierten Zeitfensters.
2. Nummerierte eigenständige Skripte isolieren einzelne Stufen. Diese sind für Fehlerbehebung, Baseline-Analyse, Prototyping benutzerdefinierter Erkennungen und Fehlalarmprüfung gedacht.
3. Eigenständige Skripte sollen dem entsprechenden Stufenblock in der Vollketten-Abfrage entsprechen, mit Ausnahme der reinen Anzeige-Reihenfolge am Ende, wie z. B. | order by Timestamp desc.
4. Hauptabfragen geben normalisierte Felder wie Stage, StageDescription, ProcessName, ProcessCommandLine, AccountName, Evidence, AdditionalContext und ReportRefs aus, damit die stufenübergreifende Ausgabe leichter zu überprüfen ist.
5. Konservative Kandidaten für geplante Erkennungen, sofern vorhanden, befinden sich im Unterverzeichnis production/ jedes Pakets und sind strenger als die Top-Level-Hunting-Abfragen.

Exposure ist ein Supportpaket für inventargestützte Exposure-Berichterstattung, keine Vollketten-Verhaltensjagd. ExternalTelemetry ist nur Dokumentation und enthält kein Endpunkt-KQL.

Microsoft Defender XDR-Anforderungen

Diese Abfragen sind für Microsoft Defender XDR Advanced Hunting gedacht. Sie stützen sich auf die Verfügbarkeit von Tabellen und Spalten von Defender for Endpoint und zugehöriger Defender-XDR-Telemetrie.

Häufig verwendete Tabellen umfassen:

Die Telemetrie ist nicht in allen Mandanten einheitlich. Einige Low-Level-Primitive, insbesondere rohe Oplock-, Reparse-Point-, Objektmanager-Symbolic-Link- und Dienstabfrage-Telemetrie, erscheinen möglicherweise nicht als explizite Ereignisse. Die Abfragen enthalten daher opportunistische Übereinstimmungen gegen ActionType und AdditionalFields, wo Defender XDR diese Details offenlegt.

Empfohlener Validierungs-Workflow

Vor dem Produktionseinsatz validieren Sie jedes Vollketten-Erkennungspaket in dieser Reihenfolge:

1. Führen Sie jede eigenständige Abfrage in Advanced Hunting mit einem begrenzten Lookback aus.
2. Bestätigen Sie, dass die Abfrage in Ihrem Mandanten kompiliert.
3. Überprüfen Sie das rohe Ergebnisvolumen und identifizieren Sie legitime Software- oder administrative Workflows, die übereinstimmen.
4. Fügen Sie lokale Ausschlüsse für bekannte gute Tools, Dienstkonten, Softwarebereitstellungssysteme, Backup-Produkte, EDR-Tools und Schwachstellenscanner hinzu.
5. Führen Sie die 01_*_full_attack_chain.kql-Abfrage für dasselbe Paket aus.
6. Vergleichen Sie die Vollketten-Ergebnisse mit den eigenständigen Ergebnissen und bestätigen Sie, dass korrelierte Stufen betrieblich sinnvoll sind.
7. Exportieren Sie Ergebnisse nach CSV und überprüfen Sie Prozesspfade, Befehlszeilen, Konten, Geräte und Zeitstempel.
8. Erst nach der Abstimmung sollten Sie eine Abfrage in eine geplante benutzerdefinierte Erkennungsregel umwandeln.

Das Repository-CI führt außerdem .github/scripts/validate_repository.py aus, um KQL-Header, Metadatenblöcke, Begrenzer-Balance, fortlaufende Nummerierung, Stufenausrichtung eigenständig-zu-Vollkette, README-Abdeckung, Produktionsplatzierungsregeln und IOC-Quellen-Nachvollziehbarkeitserwartungen zu bestätigen.

Produktionsbereitstellungs-Hinweise

Behandeln Sie diese Abfragen als Ausgangspunkte. Eine Produktionsbereitstellung sollte Folgendes umfassen:

• Mandantenspezifische Allowlists für bekannte gute Prozesse und Pfade.
• Getrennte Schwellenwerte für Hunting versus Alarmierung.
• Engere Lookback-Fenster für geplante Erkennungen, wo möglich.
• Dokumentierte Schweregrad-Zuordnung und Triage-Runbooks.
• Testgeräte oder Laborsimulationen zur Bestätigung erwarteter Übereinstimmungen.
• Änderungskontrolle vor der Aktivierung automatisierter Incident-Erstellung.
• Regelmäßige Überprüfung nach Defender-Sensor-Updates oder Betriebssystem-Upgrades.

Stellen Sie nicht alle Hauptabfragen ohne Abstimmung als geplante Erkennungen mit hohem Schweregrad bereit. Einige Stufen erkennen absichtlich schwache oder opportunistische Signale, die für die Korrelation nützlich, aber als eigenständige Alarme verrauscht sind.

Wo ein Paket eine production/-Abfragevariante bereitstellt, behandeln Sie diese Datei als Ausgangspunkt für geplante benutzerdefinierte Erkennungen und nicht die Top-Level-Hunting-Abfrage.

Leistungshinweise

Die Hauptabfragen sind so konzipiert, dass sie breite unbegrenzte Joins wo möglich vermeiden. Sie verwenden normalisierte Stufenzeilen, frühe Projektion und Zeitfenster-Korrelation. Die Leistung hängt jedoch weiterhin von der Mandantengröße, der Lookback-Dauer und dem Ereignisvolumen ab.

Wenn eine Abfrage die Defender-XDR-Ausführungslimits überschreitet:

• Reduzieren Sie Lookback.
• Führen Sie zuerst eigenständige Stufen aus, um die teure Stufe zu identifizieren.
• Fügen Sie engere Prozess-, Pfad-, Konto- oder Gerätefilter hinzu.
• Behalten Sie nur die erforderlichen projizierten Spalten.
• Bevorzugen Sie zusammengefasste Stufenausgabe vor dem Joinen oder Korrelieren.
• Verwenden Sie Shuffle-Hinweise, wo unterstützt und wo Gruppierung mit hoher Kardinalität erforderlich ist.

Ergebnisinterpretation

Die Abfragen sollten als Erkennungen verdächtiger Verhaltensmuster interpretiert werden, nicht als Beweis für eine Kompromittierung an sich. Eine Vollketten-Übereinstimmung ist stärker als eine eigenständige Stufenübereinstimmung, aber jedes Ergebnis erfordert dennoch eine Analystenprüfung.

Hochwertige Prüffelder:

• DeviceName und DeviceId
• FirstSeen und LastSeen
• StageCount
• Stages
• Processes
• ProcessCommandLines
• Accounts
• Evidence
• AdditionalContexts
• ReportRefs

Analysten sollten von diesen Feldern aus in die Defender-Gerätezeitachse, den Prozessbaum, die Dateizeitachse, die Registry-Zeitachse, Alarmbeweise und Identitätsaktivitäten wechseln.

Ordnerdokumentation

Jeder Erkennungs- oder Supportordner hat sein eigenes README mit paketspezifischen technischen Details:

• RedSun/README.md
• BlueHammer/README.md
• UnDefend/README.md
• CrossFamily/README.md
• Exposure/README.md
• ExternalTelemetry/README.md

Verwenden Sie das relevante Ordner-README, bevor Sie dieses Paket oder den Supportinhalt verwenden. Es beschreibt das Stufenmodell, die erwartete Telemetrie, wahrscheinliche Fehlalarme, Abstimmungspunkte und Bereitstellungsüberlegungen.

Repository-Dokumentation

Häufige Repository-Dateien:

• CONTRIBUTING.md beschreibt den Beitragsumfang, den KQL-Stil, die Validierung und Pull-Request-Erwartungen.
• CHANGELOG.md protokolliert bemerkenswerte Änderungen.
• SOURCES.md ordnet öffentliche Behauptungen, Baselines, Minderungen und IOC-Ergänzungen ihren Verifizierungsquellen zu.
• IOCS.md protokolliert beobachtete Indikatoren und ihre beabsichtigten Vertrauens- und Nutzungsgrenzen.
• MITIGATIONS.md protokolliert quellgestützte Minderungs- und Kompensationskontrollhinweise, die von diesem Repository verwendet werden.
• ATTACK_MAPPING.md protokolliert die ATT&CK-orientierte Erkennungszuordnung des Repositorys.
• DEPLOYMENT_GUIDE.md protokolliert Labor-, Pilot- und Produktions-Rollout-Hinweise, einschließlich Rollback- und Allowlist-Governance.
• CODE_OF_CONDUCT.md definiert das erwartete Verhalten für die Zusammenarbeit.
• SECURITY.md beschreibt, wie sicherheitsrelevante Repository-Probleme gemeldet werden.
• SUPPORT.md erklärt, welche Supportinformationen bei der Suche nach Hilfe bereitgestellt werden sollen.
• DISCLAIMER.md wiederholt die Position ohne Gewährleistung und auf eigenes Risiko in einem eigenen Dokument.
• LICENSE.md enthält die Bedingungen der Apache License 2.0 für dieses Repository.
• NOTICE enthält die Repository-Zuordnung und den KI-generierten Erkennungshinweis.
• ROADMAP.md listet praktische zukünftige Verbesserungen auf.
• .github/PULL_REQUEST_TEMPLATE.md bietet Pull-Request-Überprüfungsaufforderungen.
• .github/ISSUE_TEMPLATE/*.md bietet Issue-Vorlagen für Fehler, Erkennungsabstimmung und Dokumentation.

Wartungshinweise

Diese KQL-Dateien sollten immer dann neu validiert werden, wenn:

• Microsoft Defender-XDR-Tabellenschemata oder Ereignisnamen ändert.
• Das Defender for Endpoint-Sensorverhalten sich ändert.
• Windows-Feature-Updates das Dienst-, Registry-, Cloud-Files-, VSS- oder MRT-Verhalten verändern.
• Neue legitime Unternehmenssoftware beginnt, Defender-, VSS-, Cloud-Files- oder SAM-bezogene Oberflächen zu berühren.
• Abfrageschwellenwerte für die Produktionsalarmierung geändert werden.

Führen Sie ein Protokoll über mandantenspezifische Ausschlüsse und warum sie hinzugefügt wurden. Vermeiden Sie breite Ausschlüsse, die angreiferkontrollierte benutzerbeschreibbare Pfade unterdrücken.