Search K
Appearance
Appearance
The Kerberos "Double Hop" problem appears when an attacker attempts to use Kerberos authentication across two hops, for example using PowerShell/WinRM.
When an authentication occurs through Kerberos, credentials aren't cached in memory. Therefore, if you run mimikatz you won't find credentials of the user in the machine even if he is running processes.
This is because when connecting with Kerberos these are the steps:
If unconstrained delegation is enabled in the PC, this won't happen as the Server will get a TGT of each user accessing it. Moreover, if unconstrained delegation is used you probably can compromise the Domain Controller from it.
More info in the unconstrained delegation page.
Another way to avoid this problem which is notably insecure is Credential Security Support Provider. From Microsoft:
CredSSP authentication delegates the user credentials from the local computer to a remote computer. This practice increases the security risk of the remote operation. If the remote computer is compromised, when credentials are passed to it, the credentials can be used to control the network session.
It is highly recommended that CredSSP be disabled on production systems, sensitive networks, and similar environments due to security concerns. To determine whether CredSSP is enabled, the Get-WSManCredSSP
command can be run. This command allows for the checking of CredSSP status and can even be executed remotely, provided WinRM is enabled.
Invoke-Command -ComputerName bizintel -Credential ta\redsuit -ScriptBlock {
Get-WSManCredSSP
}
To address the double hop issue, a method involving a nested Invoke-Command
is presented. This does not solve the problem directly but offers a workaround without needing special configurations. The approach allows executing a command (hostname
) on a secondary server through a PowerShell command executed from an initial attacking machine or through a previously established PS-Session with the first server. Here's how it's done:
$cred = Get-Credential ta\redsuit
Invoke-Command -ComputerName bizintel -Credential $cred -ScriptBlock {
Invoke-Command -ComputerName secdev -Credential $cred -ScriptBlock {hostname}
}
Alternatively, establishing a PS-Session with the first server and running the Invoke-Command
using $cred
is suggested for centralizing tasks.
A solution to bypass the double hop problem involves using Register-PSSessionConfiguration
with Enter-PSSession
. This method requires a different approach than evil-winrm
and allows for a session that does not suffer from the double hop limitation.
Register-PSSessionConfiguration -Name doublehopsess -RunAsCredential domain_name\username
Restart-Service WinRM
Enter-PSSession -ConfigurationName doublehopsess -ComputerName <pc_name> -Credential domain_name\username
klist
For local administrators on an intermediary target, port forwarding allows requests to be sent to a final server. Using netsh
, a rule can be added for port forwarding, alongside a Windows firewall rule to allow the forwarded port.
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
can be used for forwarding WinRM requests, potentially as a less detectable option if PowerShell monitoring is a concern. The command below demonstrates its use:
winrs -r:http://bizintel:5446 -u:ta\redsuit -p:2600leet hostname
Installing OpenSSH on the first server enables a workaround for the double-hop issue, particularly useful for jump box scenarios. This method requires CLI installation and setup of OpenSSH for Windows. When configured for Password Authentication, this allows the intermediary server to obtain a TGT on behalf of the user.
Install-sshd.ps1
script.To resolve Connection reset
errors, permissions might need to be updated to allow everyone read and execute access on the OpenSSH directory.
icacls.exe "C:\Users\redsuit\Documents\ssh\OpenSSH-Win64" /grant Everyone:RX /T