A l’aide des notions abordées précédemment, nous avons tous les éléments en main pour expliquer le principe de l’attaque Kerberoasting, basée sur la demande de tickets de service et sur les attributs SPN de comptes d’Active Directory.

Principe

L’article sur le fonctionnement de kerberos a permis de comprendre comment un utilisateur demandait un ticket de service auprès du contrôleur de domaine. La réponse KRB_TGS_REP est composée de deux parties. Une première partie est le ticket de service dont le contenu est chiffré avec le secret du service demandé, et une deuxième partie est une clé de session qui sera utilisée entre l’utilisateur et le service. Le tout est chiffré avec le secret de l’utilisateur.

Un utilisateur de l’Active Directory peut demander un ticket de service pour n’importe quel service auprès du KDC. En effet, ce dernier n’a pas pour rôle de vérifier les droits du demandeur. Il a seulement pour rôle de fournir les informations de sécurité liées à l’utilisateur (via le PAC). C’est le service qui doit vérifier les droits de l’utilisateur en lisant son PAC dont une copie est fournie dans le ticket de service.

Ainsi, il est possible d’effectuer des demandes de tickets de service en indiquant des SPN arbitraires, et si ces SPN sont enregistrés dans l’Active Directory, le KDC fournira un morceau d’information chiffré avec la clé secrète du compte exécutant le service. L’attaquant peut, avec cette information, tenter de trouver le mot de passe en clair du compte via une attaque par exhausitivité (brute force).

Heureusement, la plupart des comptes qui exécutent les services sont les comptes machines (sous la forme NOMDEMACHINE$) et leurs mots de passe sont très longs et aléatoires, donc ils ne sont pas vraiment vulnérables à ce type d’attaque. Il existe cependant des services qui sont exécutés par des comptes de services avec des mots de passe choisis par des humains. Ce sont ces comptes qui sont bien plus simples à compromettre via des attaques de type brute-force, donc ce sont ces comptes qui seront visés dans une attaque Kerberoast.

Afin de lister ces comptes, un filtre LDAP peut être utilisé afin d’extraire les comptes de type utilisateur possédant un attribut servicePrincipalName non vide. Ce filtre est le suivant :

&(objectCategory=person)(objectClass=user)(servicePrincipalName=*)

Voici alors un script simple en PowerShell qui permet de récupérer les utilisateurs avec au moins un SPN :

$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$search.filter = "(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))"
$results = $search.Findall()
foreach($result in $results)
{
	$userEntry = $result.GetDirectoryEntry()
	Write-host "User : " $userEntry.name "(" $userEntry.distinguishedName ")"
	Write-host "SPNs"        
	foreach($SPN in $userEntry.servicePrincipalName)
	{
		$SPN       
	}
	Write-host ""
}

Dans le lab, un faux SPN a été placé sur l’utilisateur “support account”.

Ainsi, lors de la recherche LDAP, voici ce que ça donne :

Bien entendu, il existe plusieurs outils permettant d’automatiser cette tâche. Je citerai ici l’outil Invoke-Kerberoast.ps1 de @Harmj0y, outil qui s’occupe de lister les comptes utilisateurs avec un ou plusieurs SPN, effectuer des demandes de tickets de service pour ces comptes et extraire la partie chiffrée dans un format qui peut être cracké (par John par exemple).

Invoke-Kerberoast -domain adsec.local | Export-CSV -NoTypeInformation output.csv
john --session=Kerberoasting output.csv

On espère alors trouver des mots de passe, ce qui dépend de la politique de mot de passe de l’entreprise pour ces comptes.

Protection

Pour se protéger de ce type d’attaque, il faut éviter d’avoir des SPN sur des comptes utilisateurs, au profit des comptes machines.

Si c’est vraiment nécessaire, alors il faut utiliser la fonctionnalité “Managed Service Accounts” (MSA) de Microsoft qui permet de faire en sorte que le mot de passe du compte soit robuste et changé régulièrement et automatiquement. Pour cela, il suffit d’ajouter un compte de service (seulement via PowerShell) :

New-ADServiceAccount sql-service

Puis il convient de l’installer sur la machine

Install-ADServiceAccount sql-service

Enfin, il faut assigner cet utilisateur au service.

Conclusion

L’attaque Kerberoast permet de récupérer de nouveaux comptes au sein d’un Active Directory pour une tentative de mouvement latéral. Les comptes alors compromis peuvent avoir des droits plus élevés, ce qui est parfois le cas sur la machine qui héberge le service. Il est alors important d’un point de vue défensif de maîtriser l’attribut SPN des comptes de domaine pour éviter que des comptes à mot de passe faible soient vulnérables à cette attaque.