Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-04 18:40:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/kerberos-double-hop-problem.md

9.6 KiB
Raw Blame History

Kerberos Double Hop Problem

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

{% embed url="https://websec.nl/" %}

Einführung

Das Kerberos-"Double-Hop"-Problem tritt auf, wenn ein Angreifer versucht, die Kerberos-Authentifizierung über zwei Hops zu verwenden, beispielsweise mit PowerShell/WinRM.

Wenn eine Authentifizierung über Kerberos erfolgt, werden Anmeldeinformationen nicht im Speicher zwischengespeichert. Wenn Sie also mimikatz ausführen, finden Sie keine Anmeldeinformationen des Benutzers auf dem Computer, auch wenn er Prozesse ausführt.

Dies liegt daran, dass bei der Verbindung mit Kerberos die folgenden Schritte ausgeführt werden:

  1. Benutzer1 gibt Anmeldeinformationen an und der Domänencontroller sendet ein Kerberos-TGT an Benutzer1 zurück.
  2. Benutzer1 verwendet das TGT, um ein Service-Ticket anzufordern, um eine Verbindung mit Server1 herzustellen.
  3. Benutzer1 stellt eine Verbindung mit Server1 her und gibt das Service-Ticket an.
  4. Server1 hat die Anmeldeinformationen von Benutzer1 oder das TGT von Benutzer1 nicht zwischengespeichert. Daher kann sich Benutzer1 von Server1 aus nicht beim zweiten Server anmelden.

Unbeschränkte Delegierung

Wenn die unbeschränkte Delegierung auf dem PC aktiviert ist, tritt dies nicht auf, da der Server ein TGT von jedem Benutzer erhält, der darauf zugreift. Darüber hinaus können bei Verwendung der unbeschränkten Delegierung wahrscheinlich der Domänencontroller kompromittiert werden.
Weitere Informationen auf der Seite zur unbeschränkten Delegierung.

CredSSP

Ein weiterer Weg, um dieses Problem zu vermeiden, der bemerkenswert unsicher ist, ist der Credential Security Support Provider. Von Microsoft:

Die CredSSP-Authentifizierung delegiert die Benutzeranmeldeinformationen vom lokalen Computer an einen Remote-Computer. Diese Praxis erhöht das Sicherheitsrisiko des Remotevorgangs. Wenn der Remote-Computer kompromittiert ist, können die Anmeldeinformationen, wenn sie an ihn übergeben werden, verwendet werden, um die Netzwerksitzung zu steuern.

Es wird dringend empfohlen, dass CredSSP in Produktionsumgebungen, sensiblen Netzwerken und ähnlichen Umgebungen aufgrund von Sicherheitsbedenken deaktiviert wird. Um festzustellen, ob CredSSP aktiviert ist, kann der Befehl Get-WSManCredSSP ausgeführt werden. Dieser Befehl ermöglicht die Überprüfung des CredSSP-Status und kann sogar remote ausgeführt werden, sofern WinRM aktiviert ist.

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

Workarounds

Invoke Command

Um das doppelte Hop-Problem anzugehen, wird eine Methode mit einer verschachtelten Invoke-Command vorgestellt. Dies löst das Problem nicht direkt, bietet jedoch einen Workaround, ohne spezielle Konfigurationen zu benötigen. Der Ansatz ermöglicht die Ausführung eines Befehls (hostname) auf einem sekundären Server über einen PowerShell-Befehl, der von einer initialen angreifenden Maschine ausgeführt wird oder über eine zuvor eingerichtete PS-Sitzung mit dem ersten Server. So wird es gemacht:

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

Registrieren der PSSession-Konfiguration

Eine Lösung zur Umgehung des doppelten Hop-Problems besteht darin, Register-PSSessionConfiguration mit Enter-PSSession zu verwenden. Diese Methode erfordert einen anderen Ansatz als evil-winrm und ermöglicht eine Sitzung, die nicht unter der doppelten Hop-Einschränkung leidet.

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

Portweiterleitung

Für lokale Administratoren auf einem Zwischenziel ermöglicht die Portweiterleitung, Anfragen an einen endgültigen Server zu senden. Mit netsh kann eine Regel für die Portweiterleitung hinzugefügt werden, zusammen mit einer Windows-Firewallregel, um den weitergeleiteten Port zuzulassen.

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 kann zum Weiterleiten von WinRM-Anfragen verwendet werden, möglicherweise als weniger erkennbare Option, wenn die Überwachung von PowerShell ein Anliegen ist. Der folgende Befehl zeigt dessen Verwendung:

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

OpenSSH

Die Installation von OpenSSH auf dem ersten Server ermöglicht eine Umgehung des Double-Hop-Problems, besonders nützlich für Jump-Box-Szenarien. Diese Methode erfordert die CLI-Installation und Einrichtung von OpenSSH für Windows. Wenn für die Passwortauthentifizierung konfiguriert, ermöglicht dies dem Zwischenserver, ein TGT im Namen des Benutzers zu erhalten.

OpenSSH Installationschritte

  1. Laden Sie die neueste OpenSSH-Version herunter und verschieben Sie sie auf den Zielserver.
  2. Entpacken Sie das Archiv und führen Sie das Skript Install-sshd.ps1 aus.
  3. Fügen Sie eine Firewall-Regel hinzu, um Port 22 zu öffnen, und überprüfen Sie, ob die SSH-Dienste ausgeführt werden.

Um Fehler wie Verbindung zurückgesetzt zu beheben, müssen Berechtigungen möglicherweise aktualisiert werden, um allen Lese- und Ausführungszugriff auf das OpenSSH-Verzeichnis zu ermöglichen.

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

Referenzen

{% embed url="https://websec.nl/" %}

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!