Windows Pentest : Double Hop

Acces Denied ? Vraiment ?

Posté par Matthieu le 4 mai 2020

Introduction

Lors d’un pentest récent sur un domaine Windows je me suis retrouvé face à un problème que je n’avais encore jamais rencontré par manque d’expérience. Un simple sondage Twitter m’a permis de vérifier que ce problème n’était en réalité pas très connu (par mes abonnés tout du moins) :

Le problème étant aussi que les articles traitant de sécurité Windows en français sont très rares (je ne peux évidemment m’empêcher de citer le blog de Pixis qui est pour moi le meilleur blog français traitant de sécurité Windows). Nous allons donc ici essayer de traiter ce sujet qui peut s’avérer complexe quand on essaye de le comprendre en profondeur.

Il s’agit ici de mon premier article sur de l’Active Directory, je vais donc essayer de traiter le sujet au mieux.

Dans un premier temps, nous allons voir le problème d’un niveau purement pratique. Nous allons ensuite nous intéresser à la gestion des mots de passe par Windows et enfin trouver des solutions pour contourner le problème.

Quel est le problème ?

Rapide mise en contexte : via une exploitation de type « DCSync » (qui est hors sujet mais pourrait être traitée prochainement), nous avons pu nous approprier le hash NTLM de l’Administrateur de domaine. Ce moment fatidique où le pentester sait que la mission est accomplie : il va enfin pouvoir se connecter en tant qu'Administrateur de Domaine et ainsi prendre la main sur tout le parc. C’est donc ce que nous avons fait : on a utilisé l’outil « Evil-WinRM » afin d’y déposer une charge Cobalt Strike et ainsi récupérer un joli accès au DC (Domain Controller).

A partir de ce moment-là vous n’êtes pas sans savoir que l’Administrateur de domaine est généralement tout puissant sur le domaine (sauf GPO en vigueur mais ce n’était pas le cas) et qu’il est maintenant aisé pour moi d’obtenir des accès sur toutes les machines du domaine. Cobalt strike permet de faire cela très simplement via sa commande «jump » :

	jump psexec64 CIBLE LISTENER

Mais …. Voilà :

Déception ! Comment se fait-ce que je ne puisse pas pivoter via PsExec alors que je suis DA (Domain Admin).

Le problème ne vient pas de PsExec car les conditions sont :

  • Être admin local de la machine avec un compte de domaine
  • Qu’un partage SMB soit disponible en écriture

Les deux conditions étaient bien évidemment remplies…

Bon alors ... D’où vient le problème ? Je vous propose tout d’abord de voir comment sont gérés les mots de passe par Windows.

Gestion des mots de passe par Windows

Token et Logon Session

A chaque authentification réussie, Windows crée ce qu’on appelle une « Logon Session » qui contiendra les credentials, cette même session disparaitra lorsque l’utilisateur se déconnectera. En plus de cette session, des informations sont envoyées à LSA (Local Security Authority) qui sera chargé de créer un token pour le nouvel utilisateur, ce token sera lié à la « Logon Session ». Si un Thread ou un Process veut agir au nom d’un certain utilisateur ou utiliser ses credentials, il devra utiliser un token.

Pour faire simple, lors d’une authentification réussie deux éléments sont importants pour nous :

  • La logon session qui contiendra les credentials afin d’être potentiellement réutilisés par Windows
  • Un token lié a la Logon Session qui contiendra certaines informations sur l’utilisateur (SID, listes des privilèges, etc)

Logon Session Type

Les logon session possèdent des packages d’authentification (Authentification Packages) qui enregistrent les mots de passes dans LSASS.exe. Pour votre information : c’est typiquement comme ça que Mimikatz est capable de récupérer ces mots de passe.

Cependant, il existe plusieurs types de « Logon Session » mais seulement deux nous sont intéressantes :

  • Network Logon (Session Type 3) : Créée lors d’une authentification réseau où le client prouve qu’il possède le secret mais n’envoie jamais le secret (le principe du challenge-response). Aucune structure de mot de passe n'est stockée en mémoire dans cette condition-là (il y a bien sur des exceptions, par exemple pour le HTTP Basic).
  • Non-Network Logon : qu’on appelle aussi interactive, où le client envoie son mots de passe au serveur, c’est par exemple le cas quand on se connecte a une machine par RDP en tapant son mot de passe directement dans cette session.

Démonstration

Nous pouvons vérifier cela très simplement sur mon petit lab Active Directory via Mimikatz.

Dans un premier temps, on se connecte avec Evil-WinRM sur le contrôleur de domaine en tant qu'Administrateur de domaine :

Nous avons correctement réussi à nous identifier sur le contrôleur de domaine via le hash NT de l’Administrateur de domaine.

Regardons la structure de ses credentials de plus près avec Mimikatz :

Nous voyons clairement que nos mots de passe ne figurent pas dans la Logon Session. En effet, comme nous l'avons expliqué, Evil-WinRM effectuant une authentification de type 3 (via NTLM), aucun secret n'est transmis au contrôleur de domaine.. Maintenant si nous essayons d’accéder a un share d’une autre machine du domaine nous avons le droit à un jolie « Accces Denied » alors que nous sommes DA :

Résolution du souci

Bon, si vous avez bien suivi l’article, normalement la solution s’avère être simple : il nous suffit d’ajouter des credentials dans notre Logon Session ! Si nous reprenons le contexte introduit au début de l’article, nous sommes en la possession du hash de l'Administrateur, nous pouvons donc simplement utiliser ce hash pour faire un Pass-The-Hash en local, ce qui aura pour conséquence d’ajouter le hash dans LSASS.exe.

Problème résolu ! Maintenant que nous avons notre hash en mémoire notre poste est en mesure de le réutiliser afin d’accéder à d’autres ressources du domaine.

Conclusion

Nous avons ici pu voir en détails le problème du « Double-Hop ». Ce que j’ai pu remarquer au fil du temps est que les problèmes rencontré en pentest Active Directory sont souvent simples à résoudre mais il manque souvent de la bonne documentation.

Dans cet exemple, j’étais littéralement à une commande de pouvoir me répandre sur le domaine … Cependant, n’ayant aucune idée d’où pouvait provenir le problème, je n’ai pas été en mesure de la résoudre sans l’expérience de certains amis plus avisés.

J’espère que cet article aura pu éclairer vos connaissances sur la façon dont Windows gère les credentials !

Happy Hacking !

54 Coeur(s)