This post will cover some quick and dirty work-arounds to overcome the dreaded double-hop issue when conducting red team activities on Windows environments. Methods covered in this post also bleed into general Windows lateral movement techniques - not just double-hopping solutions.

If you’ve had to move laterally or conduct general systems administration on Windows environments then you’ve probably come across this obstacle - specifically with Powershell Remoting/WinRM. If you’re unsure what the double-hop issue is, it’ll be briefly covered below. Otherwise checkout this Microsoft article to get a better idea.

This post will follow a scenario (from the viewpoint of a red teamer) when your attacking box has internal network access, but is NOT joined to the domain. It’s also assuming you as the attacker just have CLI access, with Local Admin creds - also WinRM is enabled throughout the domain.

WinRM Double-hop Blues

Here’s a classic example of the problem. On the left is a PowerShell remote session from the attackers box into the first target hop (bizintel). The right side is direct terminal access to bizintel. Both running the dir command on remote target secdev.

Below is another example which shows a PS remote session on bizintel then an attempt at another PS remote session into secdev. Similar to a jump box situation.

Would be nice if PS remoting functioned the same as hopping around via SSH on Linux wouldn’t it? Nope, not allowed to be easy!

Solutions from Microsoft

This issue is by design(Kerberos) and Microsoft has provided solutions to overcome this hurdle. Although, on a pentest one may not have access or authority to make some of these changes, especially the most secure solution of resource-based delegation.

Relative to this blog post, here’s a somewhat recent post from MS providing solutions. The recommended higher security method mentioned is Resource Based Constrained Delegation. Since this is a red team post and we don’t have Domain Admin yet, we’ll avoid covering this. Also, the CredSSP technique won’t be covered here.

Invoke Command

This method is sort of “working with” the double hop issue, not necessarily solving it. It doesn’t rely on any configurations, and you can simply run it from your attacking box. It’s basically a nested Invoke-Command.

This’ll run hostname on the third server secdev.

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

Clunky, but can be scripted of course.

You could also have a PS-Session established with bizintel and simply run the Invoke-Command with $cred from there instead of nesting it. Although, running it from your attacking box centralizes tasking.

PortProxy

Since we have Local Administrator on the intermediate target bizintel: 10.35.8.17, you can add a port forwarding rule to send your requests to the final/third server secdev: 10.35.8.23.

Can quickly use netsh to rip out a one-liner and add the rule.

netsh interface portproxy add v4tov4 listenport=5446 listenaddress=10.35.8.17 connectport=5985 connectaddress=10.35.8.23

So bizintel is listening on port 5446 and will forward requests hitting 5446 off to secdev port 5985 (aka WinRM).

Then punch a hole in the Windows firewall, which can also be done with a swift netsh one-liner.

netsh advfirewall firewall add rule name=fwd dir=in action=allow protocol=TCP localport=5446

Now establish the session, which will forward us to secdev.

winrs.exe

Portforwarding WinRM requests also seems to work when using winrs.exe. This may be a better option if you’re aware PowerShell is being monitored. The below command brings back “secdev” as the result of hostname.

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

Like Invoke-Command, this can be easily scripted so the attacker can simply issue system commands as an argument. A generic batch script example winrm.bat:

OpenSSH

This method requires installing OpenSSH on the intermediary box (aka bizintel). Installing OpenSSH for Windows can be done completely via CLI and doesn’t take much time at all - plus it doesn’t flag as malware!

Of course in certain circumstances it may not be feasible, too cumbersome or may be a general OpSec risk.

This method may be especially useful on a jump box setup - with access to an otherwise inaccessible network. Once the SSH connection is established, the user/attacker can fire-off as many New-PSSession’s as needed against the segmented network without blasting into the double-hop issue.

When configured to use Password Authentication in OpenSSH (not keys or Kerberos), the logon type is 8 aka Network Clear text logon. This doesn’t mean your password is sent in the clear - it is in fact encrypted by SSH. Upon arrival it’s unencrypted into clear text via its authentication package for your session to further request juicy TGT’s!

This allows the intermediary server to request & obtain a TGT on your behalf to store locally on the intermediary server. Your session can then use this TGT to authenticate(PS remote) to additional servers.

OpenSSH Install Scenario

Download the latest OpenSSH Release zip from github onto you attacking box and move it over (or download it directly onto the jump box).

Uncompress the zip to where you’d like. Then, run the install script - Install-sshd.ps1

Lastly, just add a firewall rule to open port 22. Verify the SSH services are installed, and start them. Both of these services will need to be running for SSH to work.

If you receive a Connection reset error, update permissions to allow Everyone: Read & Execute on the root OpenSSH directory.

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

Now putting it all together.

Detect Malicious Use

Besides having a system in place to monitor powershell activity, there are a few configurations you can check locally or remotely that may potentially point to malicious double-hop usage (or other security issues).

Detect Port Forwarding

A quick local check to list all forwarded ports, use netsh.exe. By default there should not be any ports being forwarded.

netsh interface portproxy show all

Otherwsie, check remotely via PS remoting - which can also be scripted to encompass an entire domain.

Invoke-Command -ComputerName bizintel -Credential ta\redsuit -ScriptBlock {
    netsh interface portproxy show all
}

If WinRM is disabled thoughout your domain, but you’d still like to check forwarded ports remotely you can utilize wmic.exe

wmic /node:bizintel /user:ta\redsuit /password:2600leet process call create 'cmd.exe /c netsh interface portproxy show all'

CredSSP

Another method which is notably insecure is Credential Security Support Provider. Enabling CredSSP has been a solution mentioned on various forums throughout the years. 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.”

If you find CredSSP enabled on production systems, sensitive networks, etc it’s recommended they be disabled. A quick way to check CredSSP status is by running Get-WSManCredSSP. Which can be executed remotely if WinRM is enabled.

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

Detect Server Delegation

Another configuration that may be worth checking is kerberos delegation. As mentioned previously, configuring constrained/unconstrained delegation are solutions provided by Microsoft to overcome the double-hop problem.

An attacker would need more than just local admin to configure kerberos computer delegation, so if malicious delegation settings are discovered, you may have bigger problems.

You can use PowerView modules to quickly discover hosts with unconstrained (bad!) or constrained delegation.

Get-DomainComputer -Unconstrained
Get-DomainComputer -TrustedToAuth

Summary

Remember, if you administer Windows networks, make sure to follow MS best pratice guidlines and not this post.

If you’ve found this post useful and want to get some remote lab hands-on, be sure to checkout the available ranges. If you specifically want to practice WinRM/PS-remoting, it’s enabled in the final domain on TheSprawl lab range - including bizintel & secev as discussed in this post. Although be advised, TheSprawl is not recommended for beginners.

Sources

MS article, out of date but useful: https://docs.microsoft.com/en-us/archive/blogs/ashleymcglone/powershell-remoting-kerberos-double-hop-solved-securely

Win32 API Logon: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-logonusera?redirectedfrom=MSDN

SSH Network Logon Types blurb: https://www.bitvise.com/ssh-server-guide-logon-type

CredSSP: https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/enable-wsmancredssp?view=powershell-7

More on CredSSP security: https://adsecurity.org/?p=2362

PowerView Tips: https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993