Du Code à la Couverture (Partie 2) : Le Cauchemar des Espaces Blancs
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
L’article explique comment les filtres LDAP produits par les outils Impacket sont normalisés par Active Directory d’une manière qui introduit des espaces incohérents dans ID d’événement 1644 les journaux. Ces changements de formatage peuvent compromettre les détections qui s’appuient sur une correspondance exacte des chaînes, même lorsque la logique sous-jacente du filtre est identique. L’auteur montre pourquoi la logique de base « contient » est fragile et explique comment créer des détections Sigma résilientes en utilisant des expressions régulières qui tolèrent les différences d’espacement, les changements de casse et les variations d’opérateurs.
Enquête
Pour valider le problème, l’auteur a examiné de véritables enregistrements d’événements 1644 en production et a documenté plusieurs permutations de l’espace blanc du même filtre LDAP bit à bit (par exemple, des variantes de userAccountControl&524288 avec des espacements, des placements de parenthèses et des formats différents). Plusieurs approches de détection ont été essayées—en commençant par des vérifications de chaînes statiques et en progressant vers des motifs regex de plus en plus flexibles—jusqu’à ce que la règle corresponde de manière fiable à toutes les représentations observées sans surdéclenchements.
Atténuation
Adoptez des détections basées sur des regex qui autorisent les espaces optionnels, supportent la correspondance insensible à la casse et prennent en compte à la fois les styles d’opérateurs AND/OR. Pour maintenir des performances raisonnables, pré-filtrez sur le nom d’attribut cible avant d’appliquer la logique regex plus coûteuse. Enfin, validez continuellement les détections par rapport à un corpus « mur de la honte » qui capture chaque variante d’espacement et de formatage observée sur le terrain.
Réponse
Lorsqu’un filtre LDAP suspect est déclenché, avertissez le SOC pour évaluer toute activité potentielle d’énumération liée à la découverte ou à l’escalade de privilèges. Corrélez l’événement avec l’hôte/source IP, l’utilisateur demandant et d’autres attributs LDAP pour déterminer l’intention et la portée. En cas de faux positifs, ajustez les seuils et les conditions des règles tout en conservant la couverture pour les variantes de formatage connues.
Flux d’attaque
Nous continuons de mettre à jour cette partie. Inscrivez-vous pour être notifié
Me notifierDétections
Énumération possible de délégation via userAccountControl (via service de répertoire)
Voir
Énumération possible de Kerberoasting via l’exclusion de compte désactivé (via service de répertoire)
Voir
Détection d’opérations bit à bit de la couche de service LDAP avec variations de l’espace blanc [Journal des événements de sécurité Windows Microsoft]
Voir
Exécution de la simulation
Prérequis : La vérification pré-vol de la télémétrie et de la ligne de base doit avoir été réussie.
Raisonnement : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTPs identifiés et viser à générer la télémétrie exacte attendue par la logique de détection.
-
Récit d’attaque & Commandes :
Un adversaire avec des informations d’identification à faible privilège de domaine souhaite localiser des comptes privilégiés pour un mouvement latéral. Ils élaborent un filtre LDAP qui effectue un ET binaire suruserAccountControlpour isoler les comptes avec ledrapeau ADMINISTRATOR (valeur 524288). Pour échapper à la correspondance simple de chaînes, ils ajoutent des espaces supplémentaires et des parenthèses exactement comme le règle Sigma l'exige.flag (value 524288). To evade simple string matching, they add extra whitespace and parentheses exactly as the Sigma rule expects.- Construire la chaîne de filtre LDAP avec des variations d’espace.
- Exécuter la recherche LDAP en utilisant
ldapsearch(via PowerShell) contre le contrôleur de domaine. - Vérifiez que le journal des événements de sécurité enregistre l’événement 1644 contenant le filtre élaboré.
-
Script de test de régression :
# -------------------------------------------------------------- # Simulez un filtre binaire LDAP qui devrait déclencher la règle Sigma # -------------------------------------------------------------- # Paramètres $DomainController = "dc01.example.com" $BaseDN = "DC=example,DC=com" $Filter = "( userAccountControl & 524288 )" $Attributes = "distinguishedName,samAccountName,userAccountControl" # Exécuter la requête LDAP try { $result = [ADSI]"LDAP://$DomainController/$BaseDN" $searcher = New-Object System.DirectoryServices.DirectorySearcher($result) $searcher.Filter = $Filter $searcher.PropertiesToLoad.AddRange($Attributes.Split(',')) $searcher.PageSize = 1000 $entries = $searcher.FindAll() foreach ($entry in $entries) { $dn = $entry.Properties["distinguishedname"][0] $sam = $entry.Properties["samaccountname"][0] $uac = $entry.Properties["useraccountcontrol"][0] Write-Output "Found: $sam ($dn) – UAC=$uac" } } catch { Write-Error "La requête LDAP a échoué : $_" } -
Commandes de nettoyage :
# Aucune modification persistante n'a été faite ; fermez seulement la connexion ADSI. Write-Output "Nettoyage terminé."