Active Directory hardening¶

Active Directory est la racine opérationnelle de la plupart des environnements Windows. Un poste peut être réinstallé, un serveur membre peut être reconstruit, mais un annuaire compromis remet en cause les identités, les tickets Kerberos, les GPO, les certificats et les droits d'administration.

Le durcissement AD ne consiste pas à empiler des réglages isolés. Il consiste à réduire les chemins qui permettent de devenir administrateur du domaine sans l'être explicitement : mauvaises ACL, délégations trop larges, comptes de service faibles, protocoles LDAP non signés, DCs exposés et hygiène KRBTGT oubliée.

Pourquoi durcir Active Directory¶

Un attaquant n'a pas toujours besoin d'exploiter une faille système. Dans un domaine AD, il peut souvent progresser par abus de configuration :

• un compte de service avec SPN et mot de passe faible ;
• une délégation Kerberos non contrainte ;
• une ACL qui donne des droits de réplication à un groupe trop large ;
• un administrateur de domaine qui ouvre une session sur un poste utilisateur ;
• un DC qui expose des services inutiles ;
• une CA ADCS qui émet des certificats d'authentification trop librement.

Le durcissement doit donc combiner trois angles :

AdminSDHolder et SDProp¶

AdminSDHolder est un objet spécial qui sert de modèle de sécurité pour les comptes et groupes protégés. Le processus SDProp recopie périodiquement son descripteur de sécurité sur les objets membres de groupes protégés, comme Domain Admins, Enterprise Admins ou Administrators.

Ce mécanisme protège les objets sensibles contre des délégations OU trop larges. Il peut aussi masquer un problème : une ACL ajoutée sur AdminSDHolder se propage ensuite aux objets protégés.

Contrôles à effectuer¶

# Requires the Active Directory module
Get-ADObject -LDAPFilter "(adminCount=1)" `
    -Properties adminCount, distinguishedName |
    Select-Object Name, ObjectClass, DistinguishedName |
    Sort-Object ObjectClass, Name

$domainDN = (Get-ADDomain).DistinguishedName
$adminSdHolder = "CN=AdminSDHolder,CN=System,$domainDN"

Get-Acl "AD:\$adminSdHolder" |
    Select-Object -ExpandProperty Access |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited |
    Sort-Object IdentityReference

Prévention DCSync¶

Une attaque DCSync abuse des droits de réplication AD pour demander les secrets du domaine comme le ferait un contrôleur de domaine. Les droits critiques sont notamment :

• Replicating Directory Changes ;
• Replicating Directory Changes All ;
• Replicating Directory Changes In Filtered Set.

Ces droits doivent rester limités aux DCs et aux services explicitement prévus, par exemple certains outils de synchronisation d'identité.

# Requires the Active Directory module and the AD: provider
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationRights = @{
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" = "Replicating Directory Changes"
    "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" = "Replicating Directory Changes All"
    "89e95b76-444d-4c62-991a-0facbeda640c" = "Replicating Directory Changes In Filtered Set"
}

$acl.Access |
    Where-Object { $replicationRights.ContainsKey($_.ObjectType.ToString()) } |
    Select-Object IdentityReference, ActiveDirectoryRights,
        @{N="ReplicationRight";E={$replicationRights[$_.ObjectType.ToString()]}},
        AccessControlType, IsInherited

Contrôles complémentaires :

• alerter sur les événements de réplication inhabituels depuis une machine qui n'est pas DC ;
• limiter les comptes de synchronisation à une OU ou un besoin précis quand l'outil le permet ;
• retirer les droits de réplication aux groupes historiques devenus inutiles ;
• protéger les comptes de synchronisation comme des comptes Tier 0.

Kerberoasting et AS-REP Roasting¶

Kerberoasting cible les comptes avec SPN. Un utilisateur authentifié peut demander un ticket de service, puis tenter de casser hors ligne le secret du compte de service associé.

AS-REP Roasting cible les comptes dont l'option Do not require Kerberos preauthentication est activée. Dans ce cas, un attaquant peut obtenir une donnée chiffrée exploitable hors ligne sans connaître le mot de passe.

Get-ADUser -LDAPFilter "(servicePrincipalName=*)" `
    -Properties servicePrincipalName, PasswordLastSet, Enabled |
    Select-Object SamAccountName, Enabled, PasswordLastSet, ServicePrincipalName

Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true } `
    -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, Enabled, PasswordLastSet, DoesNotRequirePreAuth

gMSA pour les services¶

Les group Managed Service Accounts réduisent le risque des comptes de service classiques. Le mot de passe est long, géré par AD et changé automatiquement. L'usage est limité aux machines autorisées.

# Requires a KDS root key already present in the forest
New-ADServiceAccount -Name "gmsa-webapp01" `
    -DNSHostName "gmsa-webapp01.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-WebApp01-Servers" `
    -KerberosEncryptionType AES128,AES256

Install-ADServiceAccount gmsa-webapp01
Test-ADServiceAccount gmsa-webapp01

Délégation Kerberos : constrained, RBCD et unconstrained¶

La délégation Kerberos permet à un service d'agir pour le compte d'un utilisateur vers un autre service. Mal maîtrisée, elle devient un chemin d'escalade.

Get-ADComputer -Filter { TrustedForDelegation -eq $true } `
    -Properties TrustedForDelegation |
    Select-Object Name, DistinguishedName, TrustedForDelegation

Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo

Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
    Where-Object { $_."msDS-AllowedToActOnBehalfOfOtherIdentity" } |
    Select-Object Name, DistinguishedName

Rotation KRBTGT¶

Le compte krbtgt signe les tickets Kerberos du domaine. Après une compromission de secrets AD, sa rotation est indispensable pour invalider des tickets forgés.

La rotation doit se faire en deux changements de mot de passe, espacés de manière contrôlée, afin de laisser les tickets légitimes expirer entre les deux.

Get-ADUser krbtgt -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Séquence opérationnelle :

1. Vérifier la santé AD : réplication, DCs hors ligne, sauvegardes, supervision Kerberos.
2. Changer le mot de passe krbtgt une première fois.
3. Attendre au moins la durée de vie maximale des tickets Kerberos, selon la politique du domaine.
4. Changer le mot de passe krbtgt une deuxième fois.
5. Surveiller les erreurs Kerberos et les services sensibles.

LDAP Signing et Channel Binding¶

LDAP signing empêche les échanges LDAP non signés. LDAP channel binding renforce LDAPS contre certains scénarios de relais en liant l'authentification au canal TLS.

Événements utiles côté DC :

Print Spooler sur les contrôleurs de domaine¶

Le service Print Spooler n'a généralement pas de raison d'être actif sur un contrôleur de domaine. Il a déjà été impliqué dans des chaînes d'attaque et augmente inutilement la surface exposée des DCs.

Get-ADDomainController -Filter * |
    ForEach-Object {
        Invoke-Command -ComputerName $_.HostName -ScriptBlock {
            Stop-Service Spooler -Force
            Set-Service Spooler -StartupType Disabled
        }
    }

Tiering model¶

Le modèle de tiering sépare les identités et les machines selon leur niveau de contrôle. L'objectif est d'empêcher un privilège Tier 0 de circuler vers un poste ou serveur moins sensible.

Contrôles pratiques :

• interdire l'ouverture de session des admins Tier 0 sur les postes Tier 1 et Tier 2 ;
• utiliser des comptes distincts pour chaque tier ;
• dédier des postes d'administration protégés aux tâches Tier 0 ;
• journaliser les ouvertures de session privilégiées ;
• supprimer les droits locaux hérités des groupes trop larges.

Synthèse et checklist¶