Honeytokens AD : comptes, SPN et objets leurres

La plupart des détections AD sont statistiques : beaucoup de requêtes 4769 en RC4, plus d'échecs d'ouverture de session que d'habitude, une modification de groupe à une heure inhabituelle. Elles demandent du réglage et produisent des faux positifs qui habituent les analystes à les ignorer. La tromperie inverse ce modèle. Vous placez des objets qu'aucun utilisateur, service ou script légitime ne touche jamais, puis vous traitez toute interaction avec eux comme un incident. Un honeytoken bien placé transforme le Kerberoasting, l'AS-REP roasting, le password spraying et la reconnaissance LDAP en signaux quasi certains.

Ce guide construit cinq leurres : un compte administrateur leurre, un SPN leurre, un leurre vulnérable à l'AS-REP roasting, un faux mot de passe Group Policy Preferences et un objet leurre dont la lecture est auditée. Il couvre ensuite les alertes, la vérification et les exclusions nécessaires pour que vos propres outils ne les déclenchent pas. Il suppose en place les fondations de stratégie d'audit et de SACL décrites dans l'article pilier sur l'audit et la détection.

Principes de conception

Un leurre ne fonctionne que s'il est attractif, inerte et surveillé :

• Attractif. Il apparaît dans l'énumération que les attaquants lancent déjà : collecte BloodHound, listage des SPN, requêtes adminCount=1, recherches dans SYSVOL. Les noms, descriptions et dates doivent se fondre dans votre convention de nommage. svc-sql-backup fonctionne. honeypot01, non.
• Inerte. Il n'accorde rien. Aucune appartenance réelle à des groupes disposant de droits, aucune délégation, aucun droit d'ouverture de session, et un mot de passe aléatoire d'au moins 64 caractères qui n'est consigné nulle part.
• Surveillé. Chaque leurre dispose d'une règle de détection testée de bout en bout avant que vous ne comptiez dessus.

Tenez un registre des leurres (nom, SID, objectif, identifiant de règle et responsable) en dehors d'AD, dans la documentation de votre SOC. Moins il y a de personnes qui savent quels comptes sont des leurres, mieux c'est. Cela inclut la plupart des administrateurs du domaine.

Mesurer : ce que les attaquants voient aujourd'hui

Regardez votre domaine comme le font les outils de reconnaissance, afin que les leurres s'intègrent au paysage :

# SPN utilisateur existants (ce que liste un outil de Kerberoasting)
Get-ADUser -Filter 'servicePrincipalName -like "*"' -Properties servicePrincipalName, pwdLastSet, description |
  Select-Object SamAccountName, @{n='SPN';e={$_.servicePrincipalName -join ';'}},
    @{n='PwdLastSet';e={[datetime]::FromFileTime($_.pwdLastSet)}}, Description

# Comptes marqués adminCount=1 (ce que listent les requêtes de « comptes privilégiés »)
Get-ADUser -LDAPFilter '(adminCount=1)' | Select-Object SamAccountName, DistinguishedName

Reproduisez le nommage, le placement dans les UO et le style de description que vous constatez. Les vrais comptes vulnérables au Kerberoasting doivent être corrigés, pas simplement entourés de leurres. Voir la défense contre le Kerberoasting.

Construire les leurres

Créez tous les leurres dans une UO d'apparence normale, pas dans une UO « Leurres » dédiée. Appliquez Deny log on locally, Deny log on through Remote Desktop Services et Deny access to this computer from the network à un groupe qui les contient. Configurez-les via une GPO sous Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Compte administrateur leurre

Un leurre qui ressemble à un administrateur oublié :

# Windows PowerShell 5.1 : System.Web est disponible sur .NET Framework
Add-Type -AssemblyName System.Web
function New-DecoyPassword {
  ConvertTo-SecureString ([System.Web.Security.Membership]::GeneratePassword(64,10)) -AsPlainText -Force
}
New-ADUser -Name 'adm-jmorel' -SamAccountName 'adm-jmorel' -Path 'OU=Admins,OU=Corp,DC=corp,DC=example,DC=com' `
  -Description 'Infra admin - legacy' -AccountPassword (New-DecoyPassword) -Enabled $true -AccountNotDelegated $true

Placez-le dans un groupe nommé comme un groupe d'administration mais sans aucun droit, ou donnez-lui adminCount=1 pour qu'il apparaisse dans les requêtes de comptes « privilégiés ». Ne l'ajoutez pas à Domain Admins ni à un véritable groupe Tier 0 : le leurre deviendrait un vrai compte Tier 0.

SPN leurre

Associez un SPN crédible à un compte de service leurre. Tout 4769 pour ce SPN signifie que quelqu'un demande un ticket pour un service qui n'existe pas :

New-ADUser -Name 'svc-sqlrpt' -SamAccountName 'svc-sqlrpt' -Path 'OU=Service Accounts,OU=Corp,DC=corp,DC=example,DC=com' `
  -AccountPassword (New-DecoyPassword) -Enabled $true -Description 'SQL Reporting Services'
Set-ADUser 'svc-sqlrpt' -ServicePrincipalNames @{ Add = 'MSSQLSvc/sqlrpt01.corp.example.com:1433' }

Assurez-vous qu'aucun enregistrement DNS ni aucun hôte nommé sqlrpt01 n'existe, pour qu'aucun client ne tente jamais de le joindre par accident.

Leurre vulnérable à l'AS-REP roasting

L'AS-REP roasting cible les comptes pour lesquels Do not require Kerberos preauthentication est activé. Un leurre portant cet indicateur produit un 4768 avec PreAuthType 0 lorsque quelqu'un tente de le « roaster » :

New-ADUser -Name 'svc-scanlegacy' -SamAccountName 'svc-scanlegacy' -Path 'OU=Service Accounts,OU=Corp,DC=corp,DC=example,DC=com' `
  -AccountPassword (New-DecoyPassword) -Enabled $true -Description 'Legacy scanner (Unix)'
Set-ADAccountControl -Identity 'svc-scanlegacy' -DoesNotRequirePreAuth $true

Avec un mot de passe aléatoire de 64 caractères, le hash obtenu est inexploitable hors ligne. La requête elle-même constitue l'alerte.

Faux mot de passe GPP

Les attaquants cherchent encore des valeurs cpassword dans SYSVOL. Supprimer les vrais mots de passe GPP passe en premier. Ensuite, un fichier Groups.xml leurre dans une GPO non liée, dont le cpassword se déchiffre en un mot de passe crédible mais erroné pour le compte administrateur leurre, vous offre deux points d'alerte :

1. L'événement 5145 (Audit Detailed File Share) pour l'accès à ce chemin Groups.xml précis sur le partage SYSVOL, si vous pouvez absorber le volume sur les DC.
2. Les événements 4771, 4776 ou 4625 lorsque l'attaquant essaie le mot de passe déchiffré sur le compte leurre.

Utilisez une GPO liée nulle part, afin qu'aucun client ne la traite jamais. Ne réutilisez pas un schéma de mot de passe de votre environnement réel.

Objet leurre à lecture auditée

La reconnaissance LDAP, par exemple avec BloodHound ou ADExplorer, lit tous les objets. Une SACL qui audite les lectures sur un objet leurre transforme ce balayage en événement 4662 :

$dn   = 'CN=adm-jmorel,OU=Admins,OU=Corp,DC=corp,DC=example,DC=com'
$acl  = Get-Acl "AD:\$dn"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]'S-1-1-0',
    [System.DirectoryServices.ActiveDirectoryRights]'ReadProperty',
    [System.Security.AccessControl.AuditFlags]'Success')
$acl.AddAuditRule($rule)
Set-Acl -Path "AD:\$dn" -AclObject $acl

Cela nécessite DS Access > Audit Directory Service Access (succès) sur les contrôleurs de domaine. Limitez la SACL à cet objet unique : auditer les lectures sur un objet très sollicité inonde le journal. Pour savoir comment lire ce type de graphe d'attaque d'un point de vue défensif, voir la gestion des chemins d'attaque.

Placement et cycle de vie

Les leurres vieillissent comme de vrais comptes. Un compte de service dont le pwdLastSet date d'aujourd'hui et qui n'a jamais ouvert de session semble posé là. Créez les leurres, puis laissez-les reposer quelques semaines avant de compter dessus. Échelonnez leurs dates de création et évitez de tous les créer dans un même changement qui apparaîtrait dans une même rafale de 4720.

Répartissez les leurres là où les attaquants regardent : au moins un dans chaque domaine de la forêt, un dans l'UO où se trouvent vos vrais administrateurs et un parmi les comptes de service. Dans les grands environnements, un leurre par UO de grande entité métier aide à déterminer de quelle partie du réseau provient la reconnaissance, puisque le champ IpAddress des 4768 et 4769 indique l'hôte source.

Passez les leurres en revue deux fois par an. Confirmez qu'ils existent toujours, qu'ils ont encore leurs SACL et leurs SPN, et qu'ils déclenchent toujours leurs règles. Un projet de nettoyage d'objets qui supprime vos leurres est une façon silencieuse de perdre de la couverture.

Appliquer : les règles d'alerte

Écrivez une règle par leurre, fondée sur le SID lorsque l'événement le porte et sur le nom sinon :

Un contrôle local pour les tests, ou pour les petits environnements sans SIEM :

$decoys = 'adm-jmorel','svc-sqlrpt','svc-scanlegacy'
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4768,4769,4771,4776; StartTime=(Get-Date).AddHours(-1) } |
  Where-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    ($d | Where-Object { $_.Name -in 'TargetUserName','ServiceName' }).'#text' | Where-Object { $_ -in $decoys }
  } | Select-Object TimeCreated, Id, MachineName

Acheminez ces alertes vers l'astreinte, pas vers une file de revue quotidienne. Si vous utilisez Microsoft Defender for Identity, marquez aussi chaque leurre comme honeytoken sous Settings > Identities > Entity tags > Honeytoken, afin que le capteur lève sa propre alerte même si votre règle SIEM ne fonctionne plus. L'entrée du glossaire honeytoken résume le concept pour les parties prenantes.

Les comptes leurres ne valent que par la couverture d'événements qui les soutient. Toutes les règles ci-dessus dépendent de l'arrivée dans le SIEM des événements de tous les DC, ce qu'apporte Windows Event Forwarding.

Vérifier

Testez chaque leurre depuis un poste de travail joint au domaine ordinaire, en tant qu'utilisateur standard, après un ticket de changement. Prévenez d'abord le SOC, ou menez le test comme un exercice purple team planifié :

# SPN leurre : demander un ticket de service, puis confirmer qu'un 4769 est arrivé dans le SIEM
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'MSSQLSvc/sqlrpt01.corp.example.com:1433'
klist

# Administrateur leurre : une ouverture de session Kerberos échouée produit un 4771 sur le DC
runas /user:CORP\adm-jmorel cmd.exe   # saisir un mot de passe erroné

Pour l'objet à lecture auditée, ouvrez-le dans Utilisateurs et ordinateurs Active Directory avec l'éditeur d'attributs, puis confirmez la présence d'un 4662 avec votre utilisateur comme SubjectUserName. Mesurez pour chaque leurre la latence de bout en bout, de l'action jusqu'à l'alerte. Répétez le test chaque trimestre et après toute modification du SIEM ou du collecteur.

Ce que cela casse

Les leurres ne modifient pas le comportement de la production, mais ils entrent en collision avec les outils légitimes qui lisent ou touchent tous les objets :

• Entra Connect et les autres moteurs de synchronisation lisent tous les objets de leur périmètre. Placez les leurres à lecture auditée dans une UO hors du périmètre de synchronisation, ou excluez le compte de synchronisation de la règle 4662 par son SID.
• Les outils d'évaluation et d'inventaire (PingCastle, collecte BloodHound lancée par votre propre équipe, connecteurs CMDB, capteurs Defender for Identity) déclenchent les SACL de lecture et peuvent demander des tickets de service. Excluez explicitement leurs comptes de service et documentez l'exclusion, en sachant que des attaquants pourraient tenter de se cacher derrière ces mêmes comptes.
• La protection contre le password spraying et le verrouillage. Qu'un leurre se verrouille sous l'effet d'une activité malveillante ne pose pas de problème, mais assurez-vous qu'aucune automatisation du support ne le déverrouille ni ne réinitialise son mot de passe.
• Les scripts de nettoyage de comptes qui désactivent les comptes inactifs depuis 90 jours désactiveront vos leurres. Excluez-les par SID dans le script, et non par un motif de nommage qu'un attaquant pourrait découvrir.
• Les auditeurs et les pentesteurs les déclencheront. C'est voulu, mais convenez du processus de réponse avec eux avant la mission.

Pour aller plus loin : la référence des ID d'événements de sécurité AD explique chaque champ utilisé ci-dessus, la défense contre le Kerberoasting supprime les vrais comptes vulnérables parmi lesquels se trouvent les leurres, et la thématique audit, journalisation et détection liste le reste de la série.