Detecting ssh tunnelling through a proxy server

Why tunnel SSH through a proxy server?

An attacker could use this technique as an initial reverse connection or to enhance their capability once they have a foothold on a system. It allows an attacker to create an outbound connection using secure-shell (SSH) protocol utilising a proxy server to bypass firewall restrictions that would prevent native ssh port (TCP Port 22) reaching the Internet. Once an outbound connection via SSH is established a reverse tunnel can be created to provide the attacker access back into the environment using a graphical interface such as RDP or VNC.

Tunnel out using a proxy server

Setup the tunnel

The Squid Proxy is configured to use the CONNECT method for HTTPS (SSL/TLS) only by default as it could not otherwise relay the encrypted protocol. The use of the CONNECT method is considered unsafe and generally the only port it would be configured for is 443

So one thing the attacher must do, is to configure the end point SSH server to listen on port 443.

Creating the outbound connection using putty (or plink if command line is desired) to use the proxy server is a simple affair. Just set the destination port to 443 to trick the proxy into forwarding the traffic

Then enter and proxy details in putty as shown here.

Once the session is configured add a reverse tunnel of your choice. It can be useful to allow the attacker to use a graphical access program such as VNC or RDP remotely through the tunnel.

In this example I'm just accessing a local web server running remotely on the compromised host in the lab.

The tunnel permits the attacker to create a connection back to the compromised host bypassing inbound firewall rules.

Creating the Reverse tunnel is done in the Tunnels section under Connection in putty. Select the port to redirect from the attacker machine to the compromised host.

Connect via the proxy server

Once all that is done just connect to the external host (attacker machine), and if all goes well you have an outbound ssh session connection bypass outbound firewall rules using the proxy server.

Check the proxy logs to verify.

I use the ELK stack (Elasticsearch/Logstash/Kibana) to store and analyse my Squid proxy logs, also check out SOF-ELK from Phil Hagen and the nice people at SANS. The log entry shows that we did create a connection from the compromised host via the proxy to the attackers machine out on the Internet.

"forwarded_to": "159.65.28.223",
"source": "/var/log/squid/access_custom.log",
"type": "squid",
"response_size": 5081,
"src_ip": "172.31.254.23",
"http_method": "CONNECT",

The source address shown in the proxy log is the compromised host on the internal network but there is nothing inherent within the proxy logs that gives any clue regarding if this connection is maliciousness or not. It looks like every other SSL/TLS connection from the inside of the network to the Internet.

Reverse Tunnel

Now I can check the reverse tunnel works from the attackers machine.

The reverse tunnel works and now the attacker can bypass inbound rules on the firewall as well. It should be noted that although the example of access a web server on the compromised host is a trivial one, the attacker can make use of this capability effectively pivot inside the network with no firewall restrictions whatsoever.

Detection

So if the proxy logs do not give any clues, what else is there? How we can identify the fact that this particular connection via the proxy is malicious?

Bro

I've used Bro many times and blogged about its awesome capabilities before, and as ever, it provides some great intelligence about what is going on in the network.

I'm using ROCK NSM here which takes an all-in-one appliance approach to Network Security Monitoring (NSM) and puts Bro logs straight into its own ELK stack.

A simple search shows the SSH connection being used over port 443 coming from the proxy server. It also identifies the internal Squid Proxy as the source address of the connection. That's OK as the Squid proxy log examined earlier shows the source address of the host making the request (172.31.254.23) so it's possible to find the outbound malicious connection using Bro and trace the original request using the proxy logs.

Moloch

There is also Moloch which I wrote about in my previous post. I am often astonished at the high quality of Open Source projects and Moloch is an outstanding example.

A simple couple of searches in Moloch not only locates the ssh over proxy and the originating host.

First I search for protocols == ssh && port.dst == 443 which locates any session where SSH is using port 443. The results shows the connection from the Squid Proxy (172.31.254.90) to 159.65.28.223. Note that Moloch like Bro is able to identify the protocol without reference to the port that it is running on. Ordinarily SSH runs over TCP Port 22; but port independent decode ensures that Moloch knows SSH when it sees it no matter what strange port it's using.

Then I can simply search for ip.dst == 172.31.254.90 && port.dst == 3128 && host.http == 159.65.28.223:443 to find the source IP that initiated the ssh connection via the proxy server.

The source address is identified as being 172.31.254.23 (as seen in the Proxy logs). It's still a two step process to identify it but at least you can do the whole thing without leaving Moloch.

But Moloch doesn't stop there. I can retrieve the packets from Moloch for further analysis and use it create a Snort signature.

Moloch even provides a visual representation of the traffic flows.

Snort

I have been a long time fan of Security Onion it's great for deploying Snort/Suricata signatures to support your SIEM. The signature I created here is really simple and just looks for sources on the internal network using SSH over port 443 going to the external network.

The signature will fire whenever an SSH connection is outbound on port 443. Once the alert fires, run the last search on Moloch substituting the new host.http address identified by the signature.

Comments

Popular posts from this blog

Squid Proxy with SOF-ELK Part 1

Netflow analysis with SiLK - Part 1 Installation

CI/CD Pipeline Security & Shifting Left