Active Directory est l’un des actifs informatiques les plus importants et une cible fréquente des pirates ; sa sécurisation est donc une priorité absolue pour les équipes informatiques et de sécurité. Vérifier qu’Active Directory n’a pas été compromis fait également partie de cette mission.
Entre Active Directory pour Windows et Azure, Microsoft domine le marché des outils de gestion des identités et des accès (IAM) avec une part de marché supérieure à 50 %, notamment auprès d’environ 95 % des entreprises du Fortune 1000, ce qui en fait une cible particulièrement intéressante pour les pirates.
Nous allons voir ici comment vérifier plusieurs composants critiques d’Active Directory afin d’y déceler des signes de compromission, une étape importante à ajouter à vos bonnes pratiques de sécurité d’Active Directory.
Voir les principaux outils de sécurité d’Active Directory
Vous cherchez à améliorer la détection des compromissions d’AD ? Le sponsor de cet article, Semperis, a développé Purple Knight et Forest Druid pour détecter les indicateurs d’exposition et de compromission dans AD, Azure AD/Entra ID, Okta et le périmètre de niveau 0. Découvrez comment ces outils gratuits simplifient l’ensemble de l’audit !
Rechercher les signes d’une attaque
Les acteurs malveillants suffisamment habiles pour atteindre votre environnement Active Directory peuvent également être assez compétents pour y parvenir sans laisser de traces, ce qui rend impossible de déterminer si Active Directory a été compromis.
Un pirate pourrait, par exemple, rejoindre le groupe Domain Admins, mener des activités de piratage, puis quitter le groupe. Si la surveillance est activée, vous pouvez vérifier l’appartenance aux groupes privilégiés en les surveillant. Si vous découvrez un membre appartenant à un groupe privilégié mais ne figurant pas sur la liste des administrateurs désignés, vous pouvez soit supprimer l’administrateur, soit rechercher comment cet utilisateur est devenu membre du groupe privilégié.
Beaucoup de choses dépendent de la rapidité et des capacités de l’attaquant. Un attaquant peut mettre en œuvre des stratégies qui empêcheraient l’enregistrement de tout événement dans les journaux d’événements. Pour rechercher les signes d’une attaque, il est impossible de vérifier en permanence les journaux d’événements de chaque ordinateur joint au domaine ou contrôleur de domaine. Vérifier l’état des composants critiques d’Active Directory doit être la première étape de votre stratégie visant à déterminer si Active Directory a été compromis.
Notez que les adversaires tenteront d’attaquer des composants d’Active Directory qui ne sont pas facilement connus ni manipulés par les administrateurs d’Active Directory. Vous devez vérifier que chacun de ces composants est dans son état par défaut et déterminer si certains ont été modifiés. Malgré le grand nombre de composants à examiner, cet article se concentre uniquement sur les composants « critiques ». Nous examinerons AdminSDHolder, les objets de stratégie de groupe par défaut, les PrimaryGroupIDs et les contrôleurs de domaine. Bien que cette liste ne suffise pas à déterminer si votre Active Directory a été compromis, les éléments mentionnés ci-dessus sont typiquement ceux qu’un attaquant tenterait de modifier pour accéder à Active Directory.
Objet AdminSDHolder et comptes privilégiés
Chaque domaine Active Directory contient un conteneur unique appelé AdminSDHolder sous le conteneur System. Lors du déploiement du premier contrôleur de domaine d’un domaine Active Directory, le conteneur AdminSDHolder est également créé. Le maintien des autorisations qui seront utilisées par les comptes privilégiés relève de la responsabilité du conteneur AdminSDHolder.
Le processus SDProp copie les autorisations du conteneur AdminSDHolder vers tous les comptes privilégiés après avoir vérifié les autorisations appliquées au conteneur. Un utilisateur ordinaire n’interagit pas avec l’objet AdminSDHolder. Cependant, un attaquant disposant de privilèges suffisants peut modifier les autorisations définies pour AdminSDHolder et accéder à Active Directory.
Pour vérifier si le conteneur AdminSDHolder a été modifié, vous pouvez consulter son attribut « WhenChanged » dans l’Éditeur d’attributs, comme illustré dans la capture d’écran ci-dessous :
Le conteneur AdminSDHolder a été créé le 23/03/2023 (lors du déploiement du contrôleur de domaine) et modifié le 28/05/2023, comme le montre la capture d’écran ci-dessus. Lorsqu’une personne l’a modifié, elle a très probablement ajouté des autorisations dans l’onglet Sécurité, que vous pouvez vérifier puis supprimer si elles ne sont plus nécessaires. Les administrateurs n’ont pas besoin de toucher à l’objet AdminSDHolder une fois le domaine Active Directory déployé.
Objets de stratégie de groupe : une cible privilégiée des pirates
Vous devez savoir que les attaquants ciblent désormais principalement les GPO (objets de stratégie de groupe). Une GPO est un objet Active Directory puissant. Comme elle comporte de nombreux paramètres, un pirate qui y accède peut les modifier et les appliquer à l’ordinateur cible, ou exécuter du code malveillant au moyen d’une tâche planifiée sur les ordinateurs cibles. Vos ordinateurs cibles peuvent être les comptes d’utilisateurs, les contrôleurs de domaine ou les comptes d’ordinateurs.
Notez qu’Active Directory implémente deux objets de stratégie de groupe par défaut : Default Domain Policy et Default Domain Controllers Policy. Ces deux GPO ne sont pas modifiées après leur déploiement, à l’exception de Default Domain Policy. Les exigences de votre entreprise en matière de stratégie de mots de passe peuvent vous obliger à modifier les stratégies de compte dans Default Domain Policy, mais cette modification sera également effectuée de manière permanente.
En règle générale, vous créez une nouvelle GPO si vous souhaitez appliquer des paramètres propres à l’organisation ou des paramètres de sécurité aux utilisateurs et aux comptes d’ordinateurs de votre environnement. En consultant l’Éditeur d’attributs ou en utilisant la commande PowerShell ci-dessous, vous pouvez toujours vérifier l’heure de modification de la stratégie de domaine par défaut et de la stratégie des contrôleurs de domaine par défaut. Cette commande PowerShell répertorie toutes les GPO du domaine ainsi que leur heure de modification :
$AllGPOs = Get-GPO -All -Server $ThisDomain | Select-Object DisplayName, ModificationTime$AllGPOsSi la date de déploiement d’Active Directory et l’heure de modification de la stratégie de domaine par défaut et de la stratégie des contrôleurs de domaine par défaut diffèrent, quelqu’un a peut-être modifié ces GPO pour accéder à Active Directory.
PrimaryGroupID : une cible plus facile
De nos jours, l’attaque exploitant PrimaryGroupID est de plus en plus courante, car elle demande moins de travail avant qu’un attaquant puisse prendre le contrôle d’Active Directory.
Tous les comptes d’utilisateurs Active Directory sont initialement affectés au groupe de sécurité par défaut « Domain Users », qui devient le PrimaryGroupID de l’utilisateur. Les PrimaryGroupID des comptes d’utilisateurs sont 513, ceux des comptes d’ordinateurs sont 515 et celui du contrôleur de domaine est 516.
Le PrimaryGroupID d’un utilisateur ou d’un ordinateur peut être modifié par un attaquant, qui peut alors changer le comportement par défaut d’Active Directory. Par exemple, modifier le PrimaryGroupID d’un utilisateur afin qu’il appartienne au groupe Domain Admins accorderait à l’attaquant un accès privilégié à Active Directory.
Vous devez utiliser un script PowerShell pour vérifier tous les comptes d’utilisateurs, d’ordinateurs et de contrôleurs de domaine afin de vous assurer que leurs PrimaryGroupID n’ont pas été modifiés. Si vous constatez des changements, cela signifie que quelqu’un a tenté de modifier l’appartenance par défaut des objets afin d’accéder à Active Directory.
Contrôleurs de domaine et emplacement par défaut
Une fois déployés, les contrôleurs de domaine restent situés à leur emplacement par défaut, « OU=Domain Controllers, DC=Domain>, DC=local> ».
En raison de son emplacement par défaut dans Active Directory, le contrôleur de domaine est assuré de recevoir les paramètres de stratégie de groupe issus de la stratégie de groupe Default Domain Controllers, conçus spécifiquement pour protéger les contrôleurs de domaine.
Les contrôleurs de domaine ne recevront pas ces paramètres s’ils sont déplacés de leur emplacement par défaut ; ils peuvent à la place recevoir des paramètres provenant d’un autre objet de stratégie de groupe. Par exemple, s’il dispose des autorisations nécessaires, un attaquant peut transférer un ou plusieurs contrôleurs de domaine vers une autre unité organisationnelle à laquelle est appliquée une autre GPO, et cette GPO peut contenir une tâche planifiée qui exécutera du code malveillant. Vous devez toujours exécuter un bref script PowerShell ou utiliser les outils d’évaluation de sécurité afin de vérifier que chaque contrôleur de domaine se trouve dans son unité organisationnelle par défaut.
Voici un petit script PowerShell qui peut vous aider à vérifier l’emplacement de tous les contrôleurs de domaine d’une forêt Active Directory. Le script récupère tous les contrôleurs de domaine de la forêt Active Directory, puis vérifie un par un l’emplacement de leur compte d’ordinateur dans Active Directory. Le résultat s’affiche à l’écran si l’un des contrôleurs de domaine ne se trouve pas dans son unité organisationnelle par défaut.
$ComputersList = "C:\Temp\DCList.TXT"
Remove-Item $ComputersList -ErrorAction SilentlyContinue
$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName
foreach ($Item in $R)
{
$ThisDC = $Item.HostName
Add-Content $ComputersList $ThisDC
}
Foreach ($ComputerItem in Get-Content "$ComputersList")
{
$NameOne, $NameTwo = $ComputerItem.Split(".")
$Error.Clear()
$RNow = Get-ADComputer $NameOne -Server $ComputerItem
$DCName = $RNow.DistinguishedName
$CurLocName = $DCName
$RemovedComma = $CurLocName.replace(",", " ")
$DCT1, $DCT2, $DCT3 = $DCName.split(",")
IF ($DCT2 -eq "OU=Domain Controllers")
{
}
else
{
Write-Host "WARNING: Domain Controller is not located in its default OU"
}
}En résumé : protéger Active Directory contre les pirates
Vérifier régulièrement l’état des composants critiques d’Active Directory afin de rechercher des signes de compromission devrait faire partie des bonnes pratiques de tout administrateur. Nous avons abordé l’emplacement par défaut du compte d’ordinateur du contrôleur de domaine, le conteneur AdminSDHolder, les objets de stratégie de groupe par défaut et le PrimaryGroupID, ainsi que les techniques de détection d’une compromission, mais d’autres composants et bonnes pratiques d’Active Directory seront traités dans de prochains articles.
À lire également :