Notions de base de la reconnaissance LDAP avec PowerShell

Dans le billet d'introduction de cette série, nous avons examiné ce qu'est un compte de service Active Directory (AD), expliqué pourquoi ces comptes privilégiés représentent un risque de sécurité sérieux et promis de détailler 4 types d'attaques sur les comptes de service dans les prochains articles. Cet article explore la première de ces attaques : la reconnaissance LDAP, que les attaquants peuvent utiliser pour découvrir des comptes de service dans un environnement informatique tout en évitant d'être détectés.

Plus précisément, dans cet article, nous allons explorer comment un attaquant sans permissions spéciales, telles que les droits d'Admin de Domaine ou même d'administrateur local, peut utiliser de simples requêtes PowerShell pour trouver des comptes de service, sans avoir à installer ou apprendre des outils spécialisés comme Bloodhound.

Trouver des comptes privilégiés

Active Directory offre de nombreux avantages en matière de sécurité et de gestion, mais peut également faciliter un peu trop les choses pour un attaquant curieux. En raison de l'architecture d'AD, une fois qu'un attaquant a infiltré un ordinateur joint au domaine, il peut interroger l'annuaire et ses objets. Et parce que par défaut Active Directory ne fournit pas de mécanisme pour auditer et alerter sur les activités suspectes, ils peuvent souvent éviter d'être détectés.

Voici quelques-unes des méthodes qu'un attaquant peut utiliser pour découvrir des comptes de service en interrogeant LDAP.

Découverte du Service Principal Name (SPN)

Les comptes de service utilisent des SPNs pour prendre en charge l'authentification Kerberos. Bien que cela améliore la sécurité, cela laisse également une trace précise de l'endroit où ces comptes sont utilisés et à quoi ils servent. Ces informations peuvent être facilement exploitées par un attaquant. Les SPNs sont couramment utilisés pour exécuter des services afin de soutenir des applications comme Microsoft SQL Server et SharePoint.

Dans un autre blog post, nous montrons comment réaliser une reconnaissance AD avancée ; cependant, il existe des méthodes plus simples pour obtenir les informations dont nous avons besoin ici. En utilisant la requête LDAP simple suivante, un attaquant peut obtenir une liste des comptes AD qui ont des SPN enregistrés, ainsi que les ordinateurs, applications et données auxquels ils donnent accès :

      #Build LDAP filters to look for users with SPN values registered for current domain
$ldapFilter = "(&(objectclass=user)(objectcategory=user)(servicePrincipalName=*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
#Execute Search
$results = $search.FindAll()
#Display SPN values from the returned objects
foreach ($result in $results)
{
    $userEntry = $result.GetDirectoryEntry()
    Write-Host "User Name = " $userEntry.name
    foreach ($SPN in $userEntry.servicePrincipalName)
    {
        Write-Host "SPN = " $SPN      
    }
    Write-Host ""   
}
      

Les valeurs SPN dans les résultats révéleront où chaque compte est enregistré et pour quel service il est enregistré sur ce système. Par exemple, voici la valeur SPN pour un compte de service SQL :

Découverte de comptes de service en utilisant des attributs d'objets génériques

Bien que les SPN soient très fiables et informatifs, ils ne produiront pas une liste exhaustive des comptes de service car de nombreux comptes ne s'intègrent pas à Kerberos via les SPN et n'auront donc aucune valeur SPN définie. Cependant, les attaquants sans droits de domaine peuvent souvent encore découvrir les comptes de service par d'autres moyens. En particulier, la plupart des organisations utilisent des conventions de nommage, telles que le début du nom de tous les comptes de service par « SVC » ou quelque chose de similaire, et les comptes de service sont généralement placés dans leurs propres unités organisationnelles (UO) ou groupes.

Trouver des comptes de service basés sur les conventions de nommage des comptes

Voici un script PowerShell qui trouvera tous les comptes contenant « svc » dans le nom :

      #Build LDAP filter to find service accounts based on naming conventions
$ldapFilter = "(&(objectclass=Person)(cn=*svc*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"

#Add list of properties to search for
$objProperties = "name"
Foreach ($i in $objProperties){$search.PropertiesToLoad.Add($i)}

#Execute Search
$results = $search.FindAll()
#Display values from the returned objects
foreach ($result in $results)
{
    $userEntry = $result.GetDirectoryEntry()
    Write-Host "User Name = " $userEntry.name
    Write-Host ""   
}
      

Trouver des comptes de service en fonction de l'OU

Et voici un filtre LDAP qui peut être substitué dans le script précédent pour trouver toutes les OU qui contiennent « Service » ou « svc » dans le nom :

      $ldapFilter = "(&(objectClass=organizationalUnit)(|name=*Service*)(name=*svc*)))"

The attacker can then search those OUs for all user objects to find your service accounts. This script focuses on one OU with “Service” in its name:

$search = New-Object System,DirecoryServices.DirectorySearcher
$search.SearchRoot = "LDAP://OU=Service Accounts,OU=JEFFLAB,DC=local"
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
      

Découverte des comptes de service via le contrôle de compte utilisateur

Une autre manière sournoise de rechercher des comptes de service dans Active Directory consiste à examiner les paramètres de contrôle des comptes, car les comptes de service ont souvent des paramètres différents de ceux des comptes d'utilisateurs ordinaires. Le meilleur exemple en est le paramètre « password never expires » — les comptes de service peuvent avoir des mots de passe configurés pour ne jamais expirer parce que l'acte de les réinitialiser peut être fastidieux et entraîner des interruptions d'application ou de service.

Avec PowerShell, il est possible de trouver tous les comptes avec cette valeur activée, en utilisant un filtre LDAP légèrement plus compliqué :

      $ldapFilter = "(&(objectclass=user)(objectcategory=user)(useraccountcontrol:1.2.840.113556.1.4.803:=65536))"
      

Découverte des accès privilégiés

Bien que cet article se soit concentré uniquement sur les moyens de trouver des comptes de service sans exploiter de privilèges, si un attaquant trouve un compte qui dispose de privilèges sur un ou plusieurs systèmes au sein du réseau, il existe de nombreuses autres méthodes efficaces pour découvrir des comptes de service. Elles incluent :

• Énumération des services sur les points de terminaison et extraction du compte startname
• Recherche de chaînes de connexion dans web.config, scripts et autres emplacements où les comptes de service peuvent être codés en dur
• Exploration de la politique locale pour les utilisateurs disposant du droit « Se connecter en tant que service »
• Extraction des journaux d'événements pour les types de connexion non interactive
• Trouver des comptes de service d'application pool et d'autres applications web

Exploitation des comptes découverts

Une fois qu'un adversaire a une liste de comptes de service, son étape suivante est de les exploiter. Découvrez certaines de leurs options dans les articles suivants :

• Extraction des mots de passe des comptes de service avec Kerberoasting
• Exploitation ciblée de comptes de service avec des Silver Tickets
• Exploitation du compte de service KRBTGT pour les Golden Tickets

Découvrez-en plus sur la reconnaissance LDAP et d'autres techniques d'attaque dans le Netwrix attack catalog.