Audit AD automatisé avec PowerShell : scripts de vérification, détection des failles Kerberos, ACL dangereuses et comptes à privilèges Conseils d'expert...

Collection de scripts PowerShell pour automatiser l'audit de sécurité Active Directory avec les verifications 2026. Les équipes de sécurité et les professionnels du domaine y trouveront des recommandations applicables immediatement. Cet article fournit une analyse technique approfondie des mécanismes d'attaque et des contre-mesures efficaces, basée sur des retours d'expérience terrain et les recommandations des autorités de référence comme l'ANSSI et le MITRE.

  • Techniques d'attaque documentées et vecteurs d'exploitation
  • Indicateurs de compromission (IOC) et règles de détection
  • Stratégies de remédiation et de durcissement Active Directory
  • Impact sur les architectures Zero Trust et IAM

Contexte et Enjeux

La sécurité d'Active Directory reste un enjeu majeur pour les entreprises en 2025-2026. Avec la multiplication des attaques poussées, les équipes IT doivent constamment adapter leurs defenses. Les environnements hybrides combinant AD on-premise et Entra ID (anciennement Azure AD) ajoutent une complexite supplementaire.

Pour comprendre les fondamentaux, consultez notre article sur Pass The Ticket Attaque Defense. Les techniques d'attaque evoluent rapidement, comme détaillé dans Dcshadow Attaque Defense.

Domain ControllerOU=UtilisateursOU=ServeursAdmins (Tier 0)Users (Tier 2)Tier 1GPOArchitecture Active Directory - Modele de tiering

Votre modèle de Tiering est-il réellement appliqué ou seulement documenté ?

447
PAGES
Guide Gratuit : Sécuriser Active Directory (447 pages)
Attaques, Tiering Model, durcissement, monitoring — par Ayi NEDJIMI
Télécharger le PDF →

Analyse Technique Detaillee

L'approche technique repose sur plusieurs vecteurs d'attaque complementaires. Les pentesters et red teamers utilisent ces techniques pour identifier les failles dans les configurations AD. La comprehension de la chaine d'attaque complete est essentielle pour mettre en place des defenses efficaces.

⚡

Retour terrain

Dans mes missions de hardening Active Directory, le point le plus sous-estimé est la gestion du groupe 'Opérateurs de compte' et des délégations personnalisées créées au fil des années. Pour un groupe logistique de 1 500 utilisateurs, j'ai trouvé 312 ACL personnalisées dont 89 accordaient des permissions d'écriture sur des attributs sensibles (adminCount, memberOf sur groupes privilégiés) à des comptes d'utilisateurs standards. La dette technique en sécurité AD est souvent invisible jusqu'au premier audit sérieux.

Les outils comme BloodHound, Impacket et Rubeus permettent d'automatiser la détection des chemins d'attaque. Selon les recommandations de ANSSI, la surveillance des événements critiques (Event ID 4769, 4662, 4724) est indispensable. Notre guide Kerberoasting Attaque Defense détaillé les procedures d'audit.

La complexite des environnements modernes nécessite une approche en couches. Le modele de tiering recommande par Microsoft et l'ANSSI reste la référence pour segmenter les acces privilegies.

Notre avis d'expert

Le modèle de Tiering reste la meilleure défense structurelle contre la compromission totale d'un domaine Active Directory. Sans séparation stricte des niveaux de privilèges, un attaquant ayant compromis un poste de travail peut atteindre le contrôleur de domaine en quelques heures.

Stratégies de Defense et Remediation

La remediation doit etre progressive et priorisee. Commencez par les quick wins : desactiver NTLM ou possible, activer le Protected Users group, configurer le tiering. Ensuite, abordez les chantiers de fond comme la migration vers le passwordless et le renforcement du Conditional Access.

  • Étape 1 : Audit complet avec les scripts recommandes — voir Computer Account Takeover Attaque Defens
  • Étape 2 : Remediation des configurations critiques
  • Étape 3 : Mise en place du monitoring continu
  • Étape 4 : Tests de penetration reguliers

Plusieurs outils gratuits facilitent l'audit et le durcissement d'Active Directory. PingCastle, Purple Knight et ADRecon fournissent des rapports detailles. Les références de ENISA completent ces outils avec des bonnes pratiques validees. Pour approfondir, consultez Guide Securisation Active Directory 2025.

Cas concret

La vulnérabilité PrintNightmare (CVE-2021-34527) a exposé la fragilité du service Print Spooler de Windows, permettant l'exécution de code à distance avec des privilèges SYSTEM. Son exploitation triviale a contraint des milliers d'organisations à désactiver en urgence le service d'impression sur leurs contrôleurs de domaine.

Questions frequentes

Comment securiser un environnement Active Directory ?

La sécurisation d'Active Directory repose sur plusieurs piliers : l'implementation du modele de tiering, la restriction des privileges administratifs, la surveillance des événements critiques, le déploiement du Protected Users group, la desactivation des protocoles obsoletes comme NTLM et la mise en place d'audits reguliers.

Qu'est-ce que le modele de tiering Active Directory ?

Le modele de tiering est une architecture de sécurité recommandee par Microsoft et l'ANSSI qui segmente les acces privilegies en trois niveaux : Tier 0 pour les controleurs de domaine, Tier 1 pour les serveurs membres et Tier 2 pour les postes de travail, empechant ainsi la propagation laterale des attaquants.

Pourquoi les attaques Active Directory sont-elles si frequentes ?

Les attaques Active Directory sont frequentes car AD reste le système d'authentification central de la majorite des entreprises. Les configurations par defaut sont souvent permissives, les privileges excessifs repandus et les techniques d'exploitation bien documentees, ce qui en fait une cible privilegiee pour les attaquants.

La mise en pratique de ces concepts nécessite une approche methodique et structuree. Les équipes techniques doivent d'abord evaluer leur niveau de maturite actuel sur le sujet, identifier les lacunes prioritaires et definir un plan d'action realiste. L'implementation progressive, avec des jalons mesurables, garantit une adoption durable et efficace des pratiques recommandees.

Les organisations qui reussissent le mieux dans ce domaine adoptent une culture d'amelioration continue. Cela implique des revues regulieres des processus, une veille technologique active et une formation permanente des équipes. Les indicateurs de performance doivent etre definis des le depart pour mesurer objectivement les progres realises et ajuster la stratégie si necessaire.

L'integration de ces pratiques dans les processus existants de l'organisation est un facteur cle de succes. Plutot que de creer des workflows paralleles, il est recommande d'enrichir les procedures actuelles avec les controles et les verifications necessaires. Cette approche reduit la resistance au changement et facilite l'adoption par les équipes operationnelles.

Recommandations de durcissement

La sécurisation d'un environnement Active Directory passe par une approche méthodique. Le modèle de tiering proposé par Microsoft — avec une séparation stricte des comptes administrateurs Tier 0, Tier 1 et Tier 2 — reste la fondation de toute architecture sécurisée. Pourtant, dans la majorité des audits, on constate que ce modèle n'est que partiellement appliqué.

LAPS (Local Administrator Password Solution) est un autre pilier souvent négligé. Sans LAPS, un seul mot de passe administrateur local compromis peut ouvrir la voie à un mouvement latéral massif. La documentation Microsoft détaille la mise en œuvre, mais l'implémentation sur un parc hétérogène prend du temps et de la planification.

Points de contrôle prioritaires

Les chemins d'attaque les plus courants dans un AD passent par : les délégations Kerberos non contraintes, les comptes de service avec des SPN et des mots de passe faibles (cible du Kerberoasting), les GPO mal configurées qui exposent des credentials, et les ACL permissives sur des objets sensibles comme AdminSDHolder.

BloodHound permet de cartographier ces chemins en quelques minutes. Si vous ne l'avez jamais lancé sur votre environnement de production, la découverte risque d'être instructive. La réalité est souvent plus complexe que ce que les schémas théoriques laissent supposer.

Consultez les recommandations de l'ANSSI et le référentiel MITRE ATT&CK TA0004 (Privilege Escalation) pour structurer votre approche défensive.

Contexte et enjeux actuels

Impact opérationnel

Pour approfondir ce sujet, consultez notre outil open-source kerberos-toolkit qui facilite l'analyse et le test des mécanismes Kerberos.

Les sujets techniques en cybersécurité exigent une approche rigoureuse, fondée sur l'expérimentation et la validation en conditions réelles. Les environnements de laboratoire — qu'ils soient construits avec Proxmox, VMware Workstation ou des services cloud éphémères — sont indispensables pour tester les techniques, les outils et les contre-mesures avant tout déploiement en production.

L'un des écueils les plus fréquents dans la mise en œuvre de solutions techniques de sécurité est le gap entre la documentation officielle et la réalité du terrain. Les guides de déploiement supposent souvent un environnement propre et standardisé, là où la plupart des organisations gèrent un patrimoine applicatif hétérogène, avec des dépendances croisées et des configurations héritées.

Approche méthodique recommandée

Pour chaque implémentation technique, la méthodologie suivante a fait ses preuves : audit de l'existant, définition des prérequis, déploiement en environnement de test, validation fonctionnelle et sécurité, déploiement progressif en production avec rollback plan, puis monitoring post-déploiement. Chaque étape doit être documentée.

Les référentiels MITRE ATT&CK et MITRE D3FEND fournissent un cadre structuré pour aligner les mesures techniques sur les menaces réelles. D3FEND, en particulier, cartographie les contre-mesures défensives face aux techniques d'attaque, ce qui facilite la priorisation des investissements en sécurité.

La documentation interne — runbooks, playbooks, procédures d'exploitation — est le maillon souvent manquant. Sans elle, la connaissance reste dans la tête des experts, et chaque départ ou absence crée un risque opérationnel. Avez-vous documenté vos procédures critiques de manière à ce qu'un nouveau membre de l'équipe puisse les exécuter de manière autonome ?

Sources et références : MITRE ATT&CK Privilege Escalation · ADSecurity.org

Conclusion

La sécurisation d'Active Directory est un processus continu qui nécessite une vigilance constante. Les nouvelles menaces de 2026 renforcent la nécessite d'adopter une approche proactive, combinant audit regulier, monitoring en temps reel et formation des équipes.

Article suivant recommandé

BloodHound : Cartographie des Chemins d'Attaque Active →

Kerberoasting : Technique d'attaque ciblant les Service Principal Names (SPN) dans Active Directory pour extraire et craquer hors ligne les tickets de service Kerberos.

Les techniques d'attaque Active Directory décrites nécessitent une autorisation écrite préalable. Testez uniquement sur des environnements de lab ou dans le cadre d'un audit mandaté.

Utilisez BloodHound Community Edition pour cartographier les chemins d'attaque Active Directory avant un audit. La visualisation graphique révèle des vecteurs invisibles à l'analyse manuelle.

Ayi NEDJIMI

Votre Active Directory est-il compromis ?

Audit AD complet, détection de chemins d'attaque, durcissement Tier Model — intervention sous 48h.

5 scripts PowerShell d'audit AD complets : code et explications

Ces scripts PowerShell constituent un kit d'audit Active Directory opérationnel immédiatement déployable dans tout environnement Windows Server 2016+. Chaque script cible un vecteur d'attaque spécifique documenté dans les incidents de compromission AD réels.

Script 1 : Audit des comptes inactifs avec export CSV

# AD-Audit-InactiveAccounts.ps1
# Détecte les comptes utilisateurs et ordinateurs inactifs depuis X jours
param(
    [int]$InactiveDays = 90,
    [string]$ReportPath = "C:\ADReports\InactiveAccounts-$(Get-Date -Format 'yyyyMMdd').csv"
)

Import-Module ActiveDirectory
$cutoff = (Get-Date).AddDays(-$InactiveDays)

# Comptes utilisateurs inactifs
$inactiveUsers = Get-ADUser -Filter {
    LastLogonDate -lt $cutoff -and
    Enabled -eq $true -and
    PasswordNeverExpires -ne $true
} -Properties LastLogonDate, PasswordLastSet, Description, Manager |
Select-Object @{N='Type';E={'User'}},
    SamAccountName, Name,
    @{N='LastLogon';E={$_.LastLogonDate}},
    @{N='PasswordAge';E={(New-TimeSpan -Start $_.PasswordLastSet).Days}},
    Description,
    @{N='Manager';E={(Get-ADUser $_.Manager -ErrorAction SilentlyContinue).Name}}

# Comptes ordinateurs inactifs
$inactiveComputers = Get-ADComputer -Filter {
    LastLogonDate -lt $cutoff -and Enabled -eq $true
} -Properties LastLogonDate, OperatingSystem |
Select-Object @{N='Type';E={'Computer'}},
    SamAccountName, Name,
    @{N='LastLogon';E={$_.LastLogonDate}},
    @{N='OS';E={$_.OperatingSystem}},
    Description,
    @{N='Manager';E={'N/A'}}

$allInactive = $inactiveUsers + $inactiveComputers
$allInactive | Export-Csv -Path $ReportPath -NoTypeInformation -Encoding UTF8

Write-Host "RÉSUMÉ : $($inactiveUsers.Count) utilisateurs, $($inactiveComputers.Count) ordinateurs inactifs"
Write-Host "Rapport : $ReportPath"

Script 2 : Détection des comptes Kerberoastables

# AD-Audit-Kerberoastable.ps1
# Identifie les comptes utilisateurs avec SPN (cibles Kerberoasting)
param([string]$ReportPath = "C:\ADReports\Kerberoastable-$(Get-Date -Format 'yyyyMMdd').csv")

Import-Module ActiveDirectory

$kerberoastable = Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
    -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires,
                AdminCount, MemberOf, LastLogonDate |
Where-Object {$_.ServicePrincipalName.Count -gt 0} |
ForEach-Object {
    $riskLevel = "Faible"
    if ($_.AdminCount -eq 1) { $riskLevel = "Critique" }
    elseif ($_.PasswordNeverExpires) { $riskLevel = "Elevé" }
    elseif ((New-TimeSpan -Start $_.PasswordLastSet).Days -gt 365) { $riskLevel = "Moyen" }

    [PSCustomObject]@{
        Compte         = $_.SamAccountName
        SPNs           = ($_.ServicePrincipalName -join '; ')
        AgeMotDePasse  = (New-TimeSpan -Start $_.PasswordLastSet).Days
        NeverExpires   = $_.PasswordNeverExpires
        AdminCount     = $_.AdminCount
        RisqueLevel    = $riskLevel
        DerniereConnex = $_.LastLogonDate
    }
} | Sort-Object RisqueLevel

$kerberoastable | Export-Csv -Path $ReportPath -NoTypeInformation -Encoding UTF8
$kerberoastable | Format-Table -AutoSize
Write-Host "`nCritique: $($kerberoastable | Where-Object {$_.RisqueLevel -eq 'Critique'} | Measure-Object).Count) comptes"

Script 3 : Audit des délégations Kerberos non contraintes

# AD-Audit-UnconstrainedDelegation.ps1
# Détecte les délégations non contraintes hors contrôleurs de domaine

Import-Module ActiveDirectory
$dcNames = (Get-ADDomainController -Filter *).Name

# Ordinateurs avec délégation non contrainte (hors DCs)
$unconstrained = Get-ADComputer -Filter {TrustedForDelegation -eq $true} `
    -Properties TrustedForDelegation, OperatingSystem, LastLogonDate |
Where-Object {$dcNames -notcontains $_.Name} |
Select-Object Name, OperatingSystem, LastLogonDate,
    @{N='Risque';E={"CRITIQUE - Délégation non contrainte"}}

# Comptes utilisateurs avec délégation non contrainte
$unconstrainedUsers = Get-ADUser -Filter {TrustedForDelegation -eq $true -and Enabled -eq $true} `
    -Properties TrustedForDelegation, ServicePrincipalName |
Select-Object SamAccountName, ServicePrincipalName,
    @{N='Risque';E={"CRITIQUE - User avec délégation non contrainte"}}

Write-Host "=== DÉLÉGATIONS NON CONTRAINTES ==="
Write-Host "Ordinateurs: $($unconstrained.Count)"
$unconstrained | Format-Table -AutoSize
Write-Host "Utilisateurs: $($unconstrainedUsers.Count)"
$unconstrainedUsers | Format-Table -AutoSize

# Délégations contraintes (moins risquées mais à documenter)
$constrained = Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} `
    -Properties msDS-AllowedToDelegateTo, objectClass |
Select-Object Name, objectClass,
    @{N='DelegateTo';E={($_.'msDS-AllowedToDelegateTo' -join '; ')}}

Script 4 : Membres des groupes à privilèges élevés

# AD-Audit-PrivilegedGroups.ps1
# Inventaire complet des membres des groupes à privilèges

Import-Module ActiveDirectory

$privilegedGroups = @(
    "Domain Admins", "Enterprise Admins", "Schema Admins",
    "Administrators", "Account Operators", "Backup Operators",
    "Print Operators", "Server Operators", "Group Policy Creator Owners",
    "Protected Users", "DNSAdmins", "Remote Management Users"
)

$results = foreach ($groupName in $privilegedGroups) {
    $group = Get-ADGroup -Filter {Name -eq $groupName} -ErrorAction SilentlyContinue
    if (-not $group) { continue }

    $members = Get-ADGroupMember -Identity $groupName -Recursive -ErrorAction SilentlyContinue
    foreach ($member in $members) {
        $user = Get-ADUser -Identity $member.SamAccountName `
            -Properties LastLogonDate, PasswordLastSet, Enabled, AdminCount `
            -ErrorAction SilentlyContinue
        if ($user) {
            [PSCustomObject]@{
                Groupe          = $groupName
                Compte          = $user.SamAccountName
                Nom             = $user.Name
                Actif           = $user.Enabled
                DerniereConnex  = $user.LastLogonDate
                AgePassword     = if ($user.PasswordLastSet) {(New-TimeSpan -Start $user.PasswordLastSet).Days} else {"Jamais"}
                AdminCount      = $user.AdminCount
            }
        }
    }
}

$results | Sort-Object Groupe, Compte | Format-Table -AutoSize
$results | Export-Csv "C:\ADReports\PrivilegedMembers-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

# Résumé par groupe
$results | Group-Object Groupe | ForEach-Object {
    Write-Host "$($_.Name): $($_.Count) membres"
}

Script 5 : Audit des GPO dangereuses

# AD-Audit-DangerousGPO.ps1
# Détecte les GPO avec des paramètres dangereux ou des permissions trop larges

Import-Module ActiveDirectory, GroupPolicy

$dangerousGPOs = @()

foreach ($gpo in Get-GPO -All) {
    $report = Get-GPOReport -Guid $gpo.Id -ReportType XML
    $issues = @()

    # Vérifier les scripts de démarrage/logon
    if ($report -match 'ScriptsIni|LogonScript') {
        $issues += "Scripts logon/démarrage définis"
    }

    # Vérifier la désactivation du pare-feu Windows
    if ($report -match 'EnableFirewall.*false') {
        $issues += "Pare-feu Windows désactivé"
    }

    # Vérifier les permissions GPO (qui peut modifier cette GPO ?)
    $acl = Get-GPPermissions -Guid $gpo.Id -All
    $broadEdit = $acl | Where-Object {
        $_.Permission -in @('GpoEditDeleteModifySecurity','GpoEdit') -and
        $_.Trustee.SidType -eq 'Group' -and
        $_.Trustee.Name -notmatch 'Domain Admins|SYSTEM|Enterprise Admins'
    }
    if ($broadEdit) {
        $issues += "Permissions d'édition trop larges: $($broadEdit.Trustee.Name -join ', ')"
    }

    if ($issues.Count -gt 0) {
        $dangerousGPOs += [PSCustomObject]@{
            GPOName = $gpo.DisplayName
            GUID    = $gpo.Id
            Problemes = $issues -join ' | '
            Liens   = ($gpo.GetLinks() | Measure-Object).Count
        }
    }
}

$dangerousGPOs | Format-Table -AutoSize -Wrap
Write-Host "Total GPO à risque: $($dangerousGPOs.Count)"

Planification et automatisation des audits hebdomadaires

Ces cinq scripts doivent être planifiés via le Planificateur de tâches Windows pour s'exécuter automatiquement et envoyer les résultats par email ou les pousser vers le SIEM.

Planification via PowerShell

# Créer une tâche planifiée pour l'audit hebdomadaire (lundi 6h)
$action = New-ScheduledTaskAction -Execute 'PowerShell.exe' `
    -Argument '-NonInteractive -File "C:\ADReports\Run-WeeklyAudit.ps1"'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At '06:00'
$settings = New-ScheduledTaskSettingsSet -RunOnlyIfNetworkAvailable -WakeToRun
$principal = New-ScheduledTaskPrincipal -UserId 'DOMAINudit-svc' `
    -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask -TaskName 'AD-Weekly-Audit' `
    -Action $action -Trigger $trigger `
    -Settings $settings -Principal $principal

Rapport HTML consolidé et export SIEM

Le script orchestrateur Run-WeeklyAudit.ps1 agrège les résultats de tous les scripts en un rapport HTML envoyé par email et en événements Syslog vers le SIEM :

# Run-WeeklyAudit.ps1
$reportDate = Get-Date -Format 'yyyy-MM-dd'
$reportDir = "C:\ADReports\$reportDate"
New-Item -ItemType Directory -Path $reportDir -Force

# Exécuter les scripts d'audit
. "$PSScriptRoot\AD-Audit-InactiveAccounts.ps1" -ReportPath "$reportDir\inactive.csv"
. "$PSScriptRoot\AD-Audit-Kerberoastable.ps1" -ReportPath "$reportDir\kerberoast.csv"

# Générer rapport HTML
$html = @"
<html>
<body>
$(Import-Csv "$reportDir\inactive.csv" | ConvertTo-Html -Fragment -PreContent '
Comptes Inactifs
')
$(Import-Csv "$reportDir\kerberoast.csv" | ConvertTo-Html -Fragment -PreContent '
Comptes Kerberoastables
')
</body></html>
"@
$html | Out-File "$reportDir
apport.html"

# Envoi email
Send-MailMessage -From '[email protected]' -To '[email protected]' `
    -Subject "Rapport AD Hebdomadaire - $reportDate" `
    -Body "Voir pièce jointe" -Attachments "$reportDir
apport.html" `
    -SmtpServer 'smtp.domaine.fr'

# Export SIEM via Syslog (format CEF)
$findings = Import-Csv "$reportDir\kerberoast.csv" | Where-Object {$_.RisqueLevel -eq 'Critique'}
foreach ($f in $findings) {
    $cef = "CEF:0|Domain|ADSecurity|1.0|KerberoastableAccount|Kerberoastable Critical Account|7|" +
           "account=$($f.Compte) spn=$($f.SPNs)"
    # Envoi vers SIEM Syslog UDP 514
    $udpClient = New-Object System.Net.Sockets.UdpClient
    $bytes = [System.Text.Encoding]::UTF8.GetBytes($cef)
    $udpClient.Send($bytes, $bytes.Length, 'siem.domaine.fr', 514) | Out-Null
    $udpClient.Close()
}

Audit de sécurité AD : intégration dans le SIEM et tableaux de bord

Les scripts d'audit PowerShell génèrent de la valeur uniquement si leurs résultats sont exploités dans une logique de détection continue. L'intégration dans un SIEM (Security Information and Event Management) transforme ces audits ponctuels en surveillance permanente.

Configuration de la collecte d'événements AD vers Splunk ou Elastic

Les journaux d'événements Windows critiques pour la sécurité AD doivent être collectés en temps réel vers le SIEM. La configuration recommandée des abonnements WEF (Windows Event Forwarding) couvre les événements clés :

  • 4624/4625 : Connexions réussies/échouées — détection du brute force et des mouvements latéraux
  • 4648 : Connexion avec identifiants explicites — indicateur de Pass-the-Hash
  • 4769/4770 : Requêtes Kerberos TGS — détection du Kerberoasting (RC4 sur un compte privilégié)
  • 4776 : Validation NTLM — audit de l'usage résiduel de NTLM
  • 5136 : Modification d'objet AD — détection des modifications de groupes privilégiés
  • 4662 : Opérations sur objets AD — détection DCSync (replication directory changes)
# Règle de détection Kerberoasting (Splunk SPL)
index=windows EventCode=4769
| where Ticket_Encryption_Type="0x17"  # RC4 = indicateur Kerberoasting
| where Account_Name!="*$"  # Exclure les comptes machine
| stats count by Account_Name, Service_Name, Client_Address, _time
| where count > 5  # Plusieurs tickets RC4 en peu de temps
| eval risk="HIGH - Kerberoasting probable"

Indicateurs de compromission AD avancés : DCSync et Golden Ticket

Deux techniques avancées nécessitent une détection spécifique dans le SIEM :

DCSync : l'attaquant utilise les droits "Replication Directory Changes All" pour demander la synchronisation des hashes NTLM directement au DC. Détection : événement 4662 avec AccessMask 0x100 (DS-Replication-Get-Changes) depuis un compte non-DC. La requête Splunk EventCode=4662 | where Object_Type="domainDNS" and Access_Mask="0x100" and Account_Name!="*$" détecte cette technique.

Golden Ticket : une fois le hash du compte KRBTGT compromis, l'attaquant peut forger des tickets Kerberos valides pour n'importe quel compte, y compris des comptes inexistants. Détection : événement 4769 avec un Account_Name contenant des caractères inhabituels ou un RenewTime anormalement long (Golden Tickets ont souvent une durée de vie de 10 ans). La rotation du mot de passe KRBTGT deux fois de suite invalide tous les Golden Tickets existants et doit être effectuée immédiatement lors de la suspicion d'une compromission.

Dashboard de sécurité AD : métriques hebdomadaires

Un tableau de bord de sécurité AD efficace affiche en temps réel les indicateurs clés issus des scripts d'audit et des événements SIEM : nombre de comptes Tier 0, évolution du nombre de membres Domain Admins, comptes inactifs non désactivés, échecs d'authentification par compte et par source, tickets Kerberos RC4 détectés, et score de conformité globale (pourcentage de contrôles conformes). Ce dashboard doit être revu lors du comité de sécurité hebdomadaire et les anomalies traitées dans les 48h.