HackTricks TrainingTwitterLinkedinSponsor

Kerberos Double Hop Problem

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Introduction

Le problème du "double saut" Kerberos survient lorsqu'un attaquant tente d'utiliser l'authentification Kerberos à travers deux sauts, par exemple en utilisant PowerShell/WinRM.

Lorsqu'une authentification se produit via Kerberos, les informations d'identification ne sont pas mises en cache en mémoire. Par conséquent, si vous exécutez mimikatz, vous ne trouverez pas les informations d'identification de l'utilisateur sur la machine même s'il exécute des processus.

Cela est dû au fait que lors de la connexion avec Kerberos, les étapes suivantes sont suivies :

  1. L'utilisateur fournit des informations d'identification et le contrôleur de domaine renvoie un TGT Kerberos à l'utilisateur.

  2. L'utilisateur utilise le TGT pour demander un ticket de service pour se connecter au Serveur1.

  3. L'utilisateur se connecte au Serveur1 et fournit le ticket de service.

  4. Le Serveur1 n'a pas les informations d'identification de l'utilisateur en cache ni le TGT de l'utilisateur. Par conséquent, lorsque l'utilisateur de Serveur1 tente de se connecter à un deuxième serveur, il ne peut pas s'authentifier.

Délégation non contrainte

Si la délégation non contrainte est activée sur le PC, cela ne se produira pas car le Serveur obtiendra un TGT de chaque utilisateur y accédant. De plus, si la délégation non contrainte est utilisée, vous pouvez probablement compromettre le contrôleur de domaine à partir de là. Plus d'informations sur la page de la délégation non contrainte.

CredSSP

Une autre façon d'éviter ce problème, qui est notablement peu sécurisée, est le Fournisseur de prise en charge de la sécurité des informations d'identification. Selon Microsoft :

L'authentification CredSSP délègue les informations d'identification de l'utilisateur de l'ordinateur local à un ordinateur distant. Cette pratique augmente le risque de sécurité de l'opération à distance. Si l'ordinateur distant est compromis, lorsque les informations d'identification lui sont transmises, les informations d'identification peuvent être utilisées pour contrôler la session réseau.

Il est fortement recommandé de désactiver CredSSP sur les systèmes de production, les réseaux sensibles et des environnements similaires en raison de problèmes de sécurité. Pour déterminer si CredSSP est activé, la commande Get-WSManCredSSP peut être exécutée. Cette commande permet de vérifier l'état de CredSSP et peut même être exécutée à distance, à condition que WinRM soit activé.

Invoke-Command -ComputerName bizintel -Credential ta\redsuit -ScriptBlock {
Get-WSManCredSSP
}

Solutions

Appeler la commande

Pour résoudre le problème du double saut, une méthode impliquant un Invoke-Command imbriqué est présentée. Cela ne résout pas le problème directement mais offre une solution de contournement sans nécessiter de configurations spéciales. Cette approche permet d'exécuter une commande (hostname) sur un serveur secondaire via une commande PowerShell exécutée à partir d'une machine d'attaque initiale ou via une session PS précédemment établie avec le premier serveur. Voici comment procéder :

$cred = Get-Credential ta\redsuit
Invoke-Command -ComputerName bizintel -Credential $cred -ScriptBlock {
Invoke-Command -ComputerName secdev -Credential $cred -ScriptBlock {hostname}
}

Enregistrement de la configuration de la session PSSession

Une solution pour contourner le problème du double saut implique l'utilisation de Register-PSSessionConfiguration avec Enter-PSSession. Cette méthode nécessite une approche différente de celle d'evil-winrm et permet une session qui ne souffre pas de la limitation du double saut.

Register-PSSessionConfiguration -Name doublehopsess -RunAsCredential domain_name\username
Restart-Service WinRM
Enter-PSSession -ConfigurationName doublehopsess -ComputerName <pc_name> -Credential domain_name\username
klist

PortForwarding

Pour les administrateurs locaux sur une cible intermédiaire, le port forwarding permet d'envoyer des requêtes vers un serveur final. En utilisant netsh, une règle peut être ajoutée pour le port forwarding, ainsi qu'une règle de pare-feu Windows pour autoriser le port redirigé.

netsh interface portproxy add v4tov4 listenport=5446 listenaddress=10.35.8.17 connectport=5985 connectaddress=10.35.8.23
netsh advfirewall firewall add rule name=fwd dir=in action=allow protocol=TCP localport=5446

winrs.exe

winrs.exe peut être utilisé pour transmettre des demandes WinRM, potentiellement comme une option moins détectable si la surveillance de PowerShell est une préoccupation. La commande ci-dessous démontre son utilisation:

winrs -r:http://bizintel:5446 -u:ta\redsuit -p:2600leet hostname

OpenSSH

L'installation d'OpenSSH sur le premier serveur permet de contourner le problème du double saut, particulièrement utile pour les scénarios de boîte de saut. Cette méthode nécessite l'installation en ligne de commande et la configuration d'OpenSSH pour Windows. Lorsqu'il est configuré pour l'authentification par mot de passe, cela permet au serveur intermédiaire d'obtenir un TGT au nom de l'utilisateur.

Étapes d'installation d'OpenSSH

  1. Téléchargez et déplacez le dernier fichier zip de la version d'OpenSSH sur le serveur cible.

  2. Décompressez et exécutez le script Install-sshd.ps1.

  3. Ajoutez une règle de pare-feu pour ouvrir le port 22 et vérifiez que les services SSH sont en cours d'exécution.

Pour résoudre les erreurs de Réinitialisation de la connexion, les autorisations peuvent nécessiter une mise à jour pour permettre à tout le monde d'avoir un accès en lecture et en exécution sur le répertoire OpenSSH.

icacls.exe "C:\Users\redsuit\Documents\ssh\OpenSSH-Win64" /grant Everyone:RX /T

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!
PreviousKerberos AuthenticationNextLAPS

Last updated