Un script PowerShell pour réduire les risques de sécurité liés à Active Directory

Les cyberattaquants utilisent fréquemment des technologies héritées dans le cadre de leurs stratégies d’attaque, en ciblant les organisations qui n’ont pas encore mis en œuvre de mesures de protection ou mis à niveau leurs composants obsolètes. Dans un environnement Active Directory, les protocoles hérités constituent l’un de ces composants, et les attaquants peuvent les utiliser pour accéder à Active Directory.

Bien que l’application de correctifs (ou même l’application virtuelle de correctifs) puisse contribuer à résoudre le problème des composants obsolètes, la plupart des composants hérités ont été minutieusement évalués par les adversaires afin de déterminer s’il convient de les remplacer par une version plus récente ou de les désactiver complètement. C’est le cas des protocoles hérités d’Active Directory. Pour vous aider à sécuriser votre environnement Active Directory, nous avons donc créé un script qui vous permet de vérifier que les protocoles hérités sont désactivés.

Votre objectif prioritaire, lorsque vous sécurisez l’infrastructure Active Directory, est de réduire la surface d’attaque. De nombreux autres problèmes doivent être pris en compte pour réduire la surface d’attaque d’Active Directory, mais les protocoles hérités constituent un élément important récemment identifié. Nous allons expliquer ce que sont les protocoles hérités dans Active Directory, puis voir comment vérifier s’ils sont désactivés ou non sur tous les contrôleurs de domaine d’une forêt Active Directory.

À lire aussi : Comment savoir si Active Directory a été compromis

Quels protocoles hérités d’AD doivent être désactivés

Le vol d’identifiants reste relativement facile à réaliser si l’exposition aux protocoles hérités n’est pas réduite, car la plupart des attaquants tenteront d’exploiter les vulnérabilités associées aux protocoles hérités et à leurs composants. Microsoft recommande de désactiver les protocoles hérités suivants dans les nouvelles versions des systèmes d’exploitation :

• TLS version 1.1
• NTLM version 1.1 ou LAN Manager
• SMB version 1

Points à prendre en compte avant de désactiver les protocoles hérités

Il est important de comprendre que les applications Active Directory utilisent ces protocoles. Veillez donc à évaluer soigneusement les applications Active Directory qui les utilisent avant de désactiver l’un d’entre eux. Si une application importante utilise encore l’un de ces protocoles, ne le désactivez pas tant que vous n’en comprenez pas les conséquences. Avant de désactiver la prise en charge des protocoles hérités, vous devez également mettre à niveau tous les appareils et toutes les applications afin qu’ils utilisent des versions plus récentes des protocoles. Nous expliquons ci-dessous comment procéder.

Désactivation de TLS version 1.1

TLS est un protocole vieux de près de deux décennies, qui a été identifié comme vulnérable à des attaques telles que les mécanismes BEAST et POODLE. Le protocole TLS 1.1 présente plusieurs inconvénients :

• Comme tous les protocoles hérités, TLS 1.1 prend en charge une cryptographie faible, ce qui constitue un risque de sécurité, car des outils permettent de déchiffrer les paquets protégés par une cryptographie faible.
• TLS 1.1 ne contribue pas non plus à sécuriser correctement les connexions modernes.
• TLS 1.0 présente le défaut de prendre en charge une cryptographie insuffisante. TLS 1.2 a supplanté TLS 1.1 dans la plupart des implémentations logicielles, ce qui rend ce dernier relativement rare. Toutefois, du point de vue d’un attaquant, toute utilisation de TLS 1.1 devient une arme potentielle dans son arsenal.

Astuce Azure : Il convient de noter que Microsoft a déjà désactivé la prise en charge du protocole TLS 1.1 par PowerShell. Si vous tentez d’exécuter un script PowerShell pour vous connecter à Azure, un message d’erreur indiquera que le protocole TLS 1.1 doit être désactivé avant l’exécution du script. Vous trouverez plus d’informations sur l’instruction de désactivation de TLS ici : Activer la prise en charge de TLS 1.2, car TLS 1.0/1.1 d’Azure AD est obsolète – Active Directory | Microsoft Learn.

Identifier les appareils et les applications qui utilisent encore TLS version 1.1

Il est difficile de déterminer quelles applications .NET utilisent le protocole TLS 1.1 dans votre environnement, sauf si vous combinez plusieurs techniques, comme l’activation de la journalisation de Secure Channel sur le contrôleur de domaine, l’utilisation d’un outil de capture de paquets ou, très probablement, l’utilisation de Wireshark.

Pour déterminer si certaines de vos applications .NET utilisent encore le protocole TLS 1.1 dans votre environnement au moyen de la méthode Secure Channel, activez la journalisation de Secure Channel sur les contrôleurs de domaine. Après avoir activé cette journalisation, recherchez l’ID d’événement 36880, qui consignera la version du protocole utilisée pour établir la connexion. Pour connaître l’adresse IP du client qui a tenté de négocier la version inférieure du protocole TLS 1.1, vous devrez corréler plusieurs événements.

Dans la plupart des cas, vous pouvez demander au fournisseur de l’application si celle-ci utilise encore le protocole TLS 1.1. Si l’application a été développée en interne, demandez à l’équipe de développement de désactiver la prise en charge de TLS 1.1 et d’utiliser la version plus récente afin d’améliorer la sécurité.

Désactivation de NTLM version 1.1 ou de LAN Manager

Lorsque je réalise des évaluations de la sécurité d’Active Directory pour des clients, je constate souvent qu’ils utilisent encore le protocole hérité NTLM version 1 pour leurs applications, ou qu’ils l’ont simplement laissé activé même si les applications de leur environnement n’utilisent pas du tout le protocole NTML version 1.0.

Le protocole NTLM est principalement utilisé par les appareils et les applications exécutés dans vos environnements Active Directory. Notez que NTLM a été conçu pour effectuer une authentification fondée sur un système d’authentification par défi/réponse, dans lequel un client envoie le nom d’utilisateur en clair au contrôleur de domaine. Lorsque le contrôleur de domaine reçoit le nom d’utilisateur en clair du client, il génère un nombre aléatoire appelé « défi » et le renvoie au client. Le client utilise le hachage du mot de passe pour chiffrer le défi et le renvoie au contrôleur de domaine sous la forme d’une « réponse ».

Le problème est que, lorsqu’un client utilise NTLM 1.1, il reprend tel quel le « défi » reçu du serveur, y ajoute le nombre aléatoire du client, le chiffre à l’aide de l’algorithme DES, puis le renvoie au serveur. En revanche, si le client utilise NTML version 2.0, il ajoute d’autres paramètres, tels que le nombre aléatoire du client + le nombre aléatoire du serveur + l’horodatage + le nom d’utilisateur + la cible. La différence entre NTML version 1 et NTLM version 2 réside dans les paramètres utilisés lors du renvoi de la réponse au contrôleur de domaine. Ces paramètres supplémentaires peuvent contribuer à protéger les échanges entre un client et un serveur.

Le contrôleur de domaine interroge la base de données SAM et compare le « défi » stocké dans la base de données à celui reçu du client. Si les données correspondent, le client est autorisé à s’authentifier.

Identifier les appareils et les applications qui utilisent encore NTLM version 1.0

Pour vérifier si certains de vos appareils et applications utilisent encore le protocole NTLM version 1.0 dans votre environnement, recherchez sur les contrôleurs de domaine l’ID d’événement 4624 – Un compte a ouvert une session avec succès. Ouvrez l’événement et recherchez la section « Informations détaillées sur l’authentification », dans laquelle vous trouverez le « package d’authentification » utilisé. Si le « nom du package » indique « LM ou NTLM v1 », cela signifie que l’appareil ou l’application qui s’est authentifié auprès du contrôleur de domaine a utilisé le protocole NTLM version 1.0. Cet appareil ou cette application doit être mis à niveau vers NTML version 2.0 afin d’améliorer la sécurité.

Désactivation de SMB version 1.0

Un autre protocole hérité qui doit être désactivé dans un environnement Active Directory est SMB version 1.0. SMB 1.0 est un ancien protocole conçu pour permettre aux appareils de communiquer entre eux sur différentes couches réseau. Pour accéder à des partages SMB, par exemple, un client SMB peut se connecter à un serveur exécutant SMB.

Il est toutefois important de noter que SMB 1.0 est un protocole vieux de 30 ans, qui a connu de nombreuses améliorations au sein de la famille de protocoles SMB. Nous disposons désormais de SMB 3.0, qui prend en charge le chiffrement et la signature à l’aide de méthodes de hachage faibles. Face à l’augmentation des cybermenaces et au fait qu’Active Directory constitue la cible principale des attaquants, il est recommandé de désactiver complètement SMB 1.0 sur les contrôleurs de domaine et d’utiliser SMB 2.0 ou une version ultérieure. Avant de désactiver SMB 1.0, il faut toutefois identifier les appareils qui communiquent encore via ce protocole.

Identifier les appareils et applications qui utilisent encore le protocole SMB 1.0

Vous devez examiner les sessions SMB sur tous vos contrôleurs de domaine afin de déterminer la version utilisée par le client lorsqu’il se connecte aux contrôleurs de domaine via SMB. La version de SMB utilisée entre le client et le contrôleur de domaine (serveur) sera la version la plus récente prise en charge par les deux. Par exemple, si une machine Windows 8 communique avec un serveur Windows 2012, le protocole SMB 3.0 sera utilisé, tandis que si un client Windows d’une version antérieure communique avec un serveur Windows et que SMB 1.0 est activé, le protocole SMB 1.0 sera utilisé. Connectez-vous au contrôleur de domaine, puis exécutez la commande Get-SmbConnection pour vérifier les sessions SMB. Toutes les connexions et le « dialecte » seront répertoriés par la commande Get-SmbConnection. Le champ « Dialect » indique si les clients demandent des connexions via SMB 1.0, SMB 2.0 ou SMB 3.0.

Script PowerShell pour vérifier les protocoles hérités sur les contrôleurs de domaine

Le script PowerShell ci-dessous permet de vérifier que tous les protocoles mentionnés précédemment sont désactivés sur les contrôleurs de domaine. Une fois le script PowerShell terminé, il génère un fichier CSV indiquant l’état de tous les contrôleurs de domaine pour chaque protocole, dans la colonne correspondant à ce protocole.

Conditions requises pour le script : Veuillez vous assurer que vous remplissez toutes les conditions requises ci-dessous avant d’exécuter le script.

1. Exécutez le script avec un compte d’administrateur de domaine, car il se connectera à chaque contrôleur de domaine d’un domaine Active Directory pour vérifier les entrées de registre, puis signaler l’état des protocoles.
2. Vérifiez que l’ordinateur est joint au domaine.
3. Vérifiez que le répertoire C:\Temp existe sur l’ordinateur sur lequel le script est exécuté.

$ResultFile = "C:\Temp\LegacyProtocolsStatus.CSV"
Remove-Item $ResultFile -ErrorAction SilentlyContinue
$STR = "Domain Controller, Connection Status, TLS 1.1 Status, SMB 1 Status, NTLM Status"
Add-Content $ResultFile $STR

$GDCList = "C:\Temp\AllDCs.TXT"
Remove-Item $GDCList -ErrorAction Continue

$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName, Domain, Forest, IPv4Address, Site
foreach ($Item in $R)
{
     Add-Content $GDCList $Item.HostName
}

Foreach ($ItemName in Get-Content "$GDCList")
{
   $TLStatus = "Unknown"
   $SMBStatus = "Unknown"
   $NTLMStatus = "Unknow"
   Write-Host "Checking Connection for Domain Controller: $ItemName"

   $Error.Clear()
   $ConnectionCheck = Get-WMIObject Win32_Service -computer $ItemName
   IF ($Error.Count -ne 0)
   {
      $STR = $ItemName + ",Connection Error" + $TLStatus + "," + $SMBStatus + "," + $NTLMStatus
      Add-Content $ResultFile $STR
   }
   else
   {
      Write-Host "Connection Success!

      Write-Host "Checking TLS 1.1. Status..."
      $result = Invoke-Command -ComputerName $ItemName -ScriptBlock {
         $supported = [Net.ServicePointManager]::SecurityProtocol
         [PsCustomObject]@{
            SystemDefault = [bool]($supported -eq 0)
            Tls11 = [bool]($supported -band 768)
            }
      }
      $TLStatus = $result.Tls11

      Write-Host "Checking SMB 1.0 Status..."
      $ThisRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\LANManServer\Parameters"
      $ThisRegEntry = "SMB1"
      $Error.Clear()
      $dbs = Invoke-Command -ComputerName $ItemName -ScriptBlock { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LANManServer\Parameters' -Name "SMB1" }
      IF ($Error.Count -eq 0)
      {
         $CheckValue = $dbs.SMB1
         IF ($CheckValue -ne "0")
         {
            $SMBStatus = "Enabled"
         }
         else
         {
            $SMBStatus = "Disabled"
         }
      }
      else
      {
         IF ($Error.Exception.Message -match "Property SMB1" -or $Error.Exception.Message -match "Cannot find path")
         {
            $SMBStatus = "Enabled"
         }
         else
         {
            $SMBStatus = "ConnectionError"
         }
      }

      Write-Host "Checking NTLM Status..."
      $ThisRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\Lsa"
      $ThisRegEntry = "LmCompatibilityLevel"
      $Error.Clear()
      $dbs = Invoke-Command -ComputerName $ItemName -ScriptBlock { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Lsa' -Name "LmCompatibilityLevel" }
      IF ($Error.Count -eq 0)
      {
         $CheckValue = $dbs.LmCompatibilityLevel
         IF ($CheckValue -ne "5")
         {
            $NTLMStatus = "Enabled"
         }
         else
         {
            $NTLMStatus = "Disabled"
         }
      }
      else
      {
         IF ($Error.Exception.Message -match "Property LmCompatibilityLevel" -or $Error.Exception.Message -match "Cannot find path")
         {
            $NTLMStatus = "Enabled"
         }
         else
         {
            $NTLMStatus = "ConnectionError"
         }
      }

      $STR = $ItemName + ",Connection Ok" + $TLStatus + "," + $SMBStatus + "," + $NTLMStatus
      Add-Content $ResultFile $STR
   }
}

Lorsque le script ci-dessus est terminé, vous verrez un fichier de rapport à l’emplacement « C:Temp LegacyProtocolsStatus.CSV », contenant l’état de tous les protocoles, comme illustré dans la capture d’écran ci-dessous.

N’oubliez pas que si l’un des protocoles est activé, vous devez vérifier les contrôleurs de domaine et prendre les mesures nécessaires pour désactiver le protocole afin de réduire les risques de sécurité dans votre forêt Active Directory.

En résumé : désactiver les protocoles hérités dans Active Directory est essentiel

Active Directory et Azure Active Directory (désormais Microsoft Entra ID) représentent environ 60 % du marché de la gestion des identités et des accès (IAM) et constituent la cible principale des pirates. Le renforcement de la sécurité d’Active Directory est donc essentiel pour protéger les actifs d’une organisation. La désactivation des protocoles hérités est une étape importante vers une meilleure sécurité d’Active Directory. Les pirates recherchent ces vulnérabilités : vous devriez en faire autant.

Pour aller plus loin :

• Principaux outils de sécurité pour Active Directory
• Attaques Living Off the Land : définition et prévention des attaques LOTL
• Des agences de cybersécurité publient des recommandations pour sécuriser PowerShell