Kerberos Double Hops Issue
This section of the module make us aware of the double hop problem that arise when using Kerberos authentication and try to access resources over two hops or more.
In the following scenario, we can establish a session to Hop A using Powershell/WinRM, which use Kerberos authentication. However, authentication failed when from Hop A, we try to execute command on Hop B. This is due to the fact that, unlike NTLM hash, Kerberos tickets are not cached in memory and sent along with user requests. Hop A can not retrieve the user authentication details from memory and then access resources on Hop B on the behalf of the user.
In others words, the TGS is used to establish a remote session from the attacker box to Hop A. However, the attacker's TGT is not sent along to the remote session, so further requests made from Hop A to access resources on Hop B stayed unauthenticated.
Exception: If Unconstrained Delegation is enabled on the target Hop A, this will circumvent the issue since the TGT will be transferred to the remote session. Contraint Delegation is the solution proposed by Microsoft to overcome Double Hop issue.
See this article on the Double Hop issue. Here.
Overcome the Double Hop issues
The module showcases two solution to overcome the Double Hop issue. The first solution can be applied if we have established a remote session over WinRM. The second solution can only apply if we are working from a Windows attack box with a GUI.
PSCredential
The first solution is as simple as passing along the credentials on Hop A by creating a credential object.
Then, we can use this credential object to make further requests on others hosts in the network.
Register PSSession Configuration
This second option will only works if we are working from a Windows attack host machine with a GUI. This methods require an elevated PowerShell terminal and a GUI to enter the credentials.
From our Windows local machine register a new PS Session Configuration.
Then, restart the Win-RM service
Finally, Enter a new PowerShell session on the jump host, but using the PowerShell configuration set above. Our local machine will impersonate the DEV01 host in the context of the backupadm
user and all requests made will be redirect directly to the DC01 host (or others host in the network).
Last updated