redsun-bluehammer-undefend-detection-pack

# Détections KQL Microsoft Defender XDR pour les comportements d'abus Defender liés à RedSun, BlueHammer, UnDefend et CVE-2026-33825.

La revue des sources vérifiée le 2026-05-05 associe BlueHammer à CVE-2026-33825. Les données de plateformes affectées de NVD et les notes de version de Microsoft Defender identifient les versions de la plateforme Microsoft Defender Antimalware antérieures à 4.18.26030.3011 comme affectées. Aucun CVE Microsoft public ni correctif fournisseur n'a été vérifié pour RedSun ou UnDefend lors de cette revue ; Huntress a signalé que les deux restaient non corrigés au 2026-04-20. Ce dépôt détecte les comportements et la télémétrie Defender ; il ne détermine pas à lui seul la conformité des correctifs.

Référentiel de recherche vérifié

• Dernière vérification : 2026-05-05
• BlueHammer : CVE-2026-33825 ; considérez la plateforme Defender Antimalware 4.18.26030.3011 ou ultérieure comme le référentiel de correctifs vérifié minimal documenté dans ce dépôt.
• RedSun : aucun CVE Microsoft public ni correctif fournisseur n'a été vérifié lors de la revue des sources du 2026-05-05. Conservez ce pack axé sur les comportements.
• UnDefend : aucun CVE Microsoft public ni correctif fournisseur n'a été vérifié lors de la revue des sources du 2026-05-05. Conservez ce pack axé sur les comportements.
• Contexte d'intrusion inter-familles : Huntress a documenté des outils observés partagés, une activité de suivi BeigeBurrow et des commandes de reconnaissance utiles pour la chasse et l'enrichissement, mais ne constituant pas en soi une preuve déterministe.

Structure du dépôt

Le dépôt utilise des dossiers de packs pour le contenu de détection et le contenu de support. Les dossiers contenant du KQL utilisent une numérotation séquentielle commençant à 01.

Modèle de conception des requêtes

Les quatre packs de détection de chaîne complète (RedSun, BlueHammer, UnDefend et CrossFamily) suivent la même structure :

1. 01_*_full_attack_chain.kql est la chasse composite. Elle exécute toute la logique des étapes ensemble et corrèle les preuves sur le même appareil dans une fenêtre temporelle définie.
2. Les scripts autonomes numérotés isolent les étapes individuelles. Ils sont destinés au dépannage, à l'analyse de référence, au prototypage de détections personnalisées et à la revue des faux positifs.
3. Les scripts autonomes doivent correspondre au bloc d'étape correspondant de la requête de chaîne complète, à l'exception du tri final uniquement destiné à l'affichage comme | order by Timestamp desc.
4. Les requêtes principales émettent des champs normalisés tels que Stage, StageDescription, ProcessName, ProcessCommandLine, AccountName, Evidence, AdditionalContext et ReportRefs afin de faciliter la revue des résultats inter-étapes.
5. Les candidats conservateurs de détection planifiée, lorsqu'ils existent, se trouvent dans le sous-répertoire production/ de chaque pack et sont plus stricts que les requêtes de chasse de niveau supérieur.

Exposure est un pack de support pour les rapports d'exposition basés sur l'inventaire, et non une chasse de comportement de chaîne complète. ExternalTelemetry est une documentation uniquement et ne contient pas de KQL de point de terminaison.

Exigences Microsoft Defender XDR

Ces requêtes sont destinées à Microsoft Defender XDR Advanced Hunting. Elles reposent sur la disponibilité des tables et colonnes de Defender for Endpoint et de la télémétrie Defender XDR associée.

Les tables couramment utilisées incluent :

La télémétrie n'est pas uniforme dans tous les locataires. Certaines primitives de bas niveau, en particulier la télémétrie brute des oplocks, points d'analyse, liens symboliques du gestionnaire d'objets et requêtes de service, peuvent ne pas apparaître comme événements explicites. Les requêtes incluent donc une correspondance opportuniste avec ActionType et AdditionalFields lorsque Defender XDR expose ces détails.

Flux de validation recommandé

Avant toute utilisation en production, validez chaque pack de détection de chaîne complète dans cet ordre :

1. Exécutez chaque requête autonome dans Advanced Hunting avec une fenêtre de recherche limitée.
2. Confirmez que la requête compile dans votre locataire.
3. Examinez le volume brut des résultats et identifiez les flux de travail logiciels ou administratifs légitimes qui correspondent.
4. Ajoutez des exclusions locales pour les outils connus, les comptes de service, les systèmes de déploiement logiciel, les produits de sauvegarde, les outils EDR et les scanners de vulnérabilités.
5. Exécutez la requête 01_*_full_attack_chain.kql pour le même pack.
6. Comparez les résultats de la chaîne complète avec les résultats autonomes et confirmez que les étapes corrélées ont un sens opérationnel.
7. Exportez les résultats en CSV et examinez les chemins de processus, lignes de commande, comptes, appareils et horodatages.
8. Ce n'est qu'après réglage que vous devez convertir une requête en règle de détection personnalisée planifiée.

Le CI du dépôt exécute également .github/scripts/validate_repository.py pour confirmer les en-têtes KQL, les blocs de métadonnées, l'équilibre des délimiteurs, la numérotation contiguë, l'alignement des étapes autonomes-vers-chaîne complète, la couverture README, les règles de placement en production et les attentes de traçabilité des sources IOC.

Recommandations de déploiement en production

Considérez ces requêtes comme des points de départ. Un déploiement en production devrait inclure :

• Des listes d'autorisation spécifiques au locataire pour les processus et chemins connus.
• Des seuils séparés pour la chasse par rapport à l'alerte.
• Des fenêtres de recherche plus étroites pour les détections planifiées lorsque c'est possible.
• Un mappage de sévérité documenté et des runbooks de triage.
• Des appareils de test ou des simulations en laboratoire pour confirmer les correspondances attendues.
• Un contrôle des changements avant d'activer la création automatisée d'incidents.
• Une revue périodique après les mises à jour des capteurs Defender ou les mises à niveau du système d'exploitation.

Ne déployez pas toutes les requêtes principales comme détections planifiées à haute sévérité sans réglage. Certaines étapes détectent intentionnellement des signaux faibles ou opportunistes utiles pour la corrélation mais bruyants en tant qu'alertes autonomes.

Lorsqu'un pack fournit une variante de requête production/, considérez ce fichier comme le point de départ des détections personnalisées planifiées plutôt que la requête de chasse de niveau supérieur.

Notes de performance

Les requêtes principales sont conçues pour éviter autant que possible les jointures larges non bornées. Elles utilisent des lignes d'étapes normalisées, une projection précoce et une corrélation par compartiments temporels. Cependant, les performances dépendent toujours de l'échelle du locataire, de la durée de recherche et du volume d'événements.

Si une requête dépasse les limites d'exécution de Defender XDR :

• Réduisez Lookback.
• Exécutez d'abord les étapes autonomes pour identifier l'étape coûteuse.
• Ajoutez des filtres plus étroits sur les processus, chemins, comptes ou appareils.
• Conservez uniquement les colonnes projetées requises.
• Préférez une sortie d'étapes résumée avant de joindre ou corréler.
• Utilisez des indices de lecture aléatoire (shuffle hints) lorsque pris en charge et lorsqu'un regroupement à haute cardinalité est requis.

Interprétation des résultats

Les requêtes doivent être interprétées comme des détections de modèles de comportement suspects, et non comme une preuve de compromission en soi. Une correspondance de chaîne complète est plus forte qu'une correspondance d'étape autonome, mais chaque résultat nécessite toujours une revue par un analyste.

Champs de revue à haute valeur :

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

Les analystes doivent pivoter depuis ces champs vers la chronologie de l'appareil Defender, l'arborescence des processus, la chronologie des fichiers, la chronologie du registre, les preuves d'alerte et l'activité d'identité.

Documentation des dossiers

Chaque dossier de détection ou de support possède son propre README avec des détails techniques spécifiques au pack :

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

Consultez le README du dossier concerné avant d'utiliser ce pack ou ce contenu de support. Il décrit le modèle d'étapes, la télémétrie attendue, les faux positifs probables, les points de réglage et les considérations de déploiement.

Documentation du dépôt

Fichiers courants du dépôt :

• CONTRIBUTING.md décrit le périmètre des contributions, le style KQL, la validation et les attentes concernant les pull requests.
• CHANGELOG.md consigne les changements notables.
• SOURCES.md associe les affirmations publiques, référentiels, atténuations et ajouts IOC à leurs sources de vérification.
• IOCS.md consigne les indicateurs observés et leurs limites prévues de confiance et d'utilisation.
• MITIGATIONS.md consigne les notes d'atténuation et de contrôle compensatoire adossées aux sources utilisées par ce dépôt.
• ATTACK_MAPPING.md consigne le mappage de détection orienté ATT&CK du dépôt.
• DEPLOYMENT_GUIDE.md consigne les recommandations de déploiement en laboratoire, pilote et production, y compris la gouvernance de restauration et de liste d'autorisation.
• CODE_OF_CONDUCT.md définit le comportement attendu pour la collaboration.
• SECURITY.md décrit comment signaler les problèmes de sécurité sensibles du dépôt.
• SUPPORT.md explique quelles informations de support fournir lors d'une demande d'aide.
• DISCLAIMER.md répète la position d'absence de garantie et d'utilisation à vos propres risques dans un document dédié.
• LICENSE.md contient les termes de la licence Apache 2.0 pour ce dépôt.
• NOTICE contient l'attribution du dépôt et l'avis de détection générée par IA.
• ROADMAP.md liste les améliorations futures pratiques.
• .github/PULL_REQUEST_TEMPLATE.md fournit les invites de revue des pull requests.
• .github/ISSUE_TEMPLATE/*.md fournit les modèles de problèmes pour les bogues, le réglage des détections et la documentation.

Notes de maintenance

Ces fichiers KQL doivent être revalidés à chaque fois que :

• Microsoft modifie les schémas de tables Defender XDR ou les noms d'événements.
• Le comportement du capteur Defender for Endpoint change.
• Les mises à jour de fonctionnalités Windows modifient le comportement des services, du registre, de Cloud Files, de VSS ou de MRT.
• Un nouveau logiciel d'entreprise légitime commence à toucher les surfaces liées à Defender, VSS, Cloud Files ou SAM.
• Les seuils de requête sont modifiés pour l'alerte en production.

Conservez un enregistrement des exclusions spécifiques au locataire et des raisons de leur ajout. Évitez les exclusions trop larges qui suppriment les chemins inscriptibles par l'utilisateur contrôlés par un attaquant.