# SSH Tunneling in Action: Direct-TCP Requests
As part of my SANS degree program curriculum, I had the opportunity to set up a honeypot to monitor log activities mimicking a vulnerable server. The goal was to observe and analyze potential threats from attackers who attempt to breach the system.
I chose the AWS free tier EC2 instance as the base for my honeypot setup, located in Japan. Within this setup, I deployed Cowrie, a SSH and Telnet honeypot designed to log brute force attacks and shell interaction performed by an attacker. To facilitate easier access to all logs from a single platform, I purchased a separate virtual private server and installed ELK SIEM (Elasticsearch, Logstash, Kibana). The setup instructions were provided by my ISC mentor, Guy Bruneau.
## Setting Up the Honeypot
Upon setting up the honeypot sensor and deploying Cowrie, one of the interesting observations in logs was direct-tcp connection requests. Over 1000 different IPs within a month made these requests, with more than 75% targeting a single destination IP. In this post, I'll delve into how and why these connections are set up, and where the destination IP points to.
## Direct-TCP Connection Requests
Sample log of direct-tcp connection request seen in honeypot logs:
The sample log indicates that the request originated from 127.0.0.1 (the local loopback interface), but when looking at the source.ip in Kibana, the actual source IPs were different external addresses.
Using the source IP 125.20.251.66, I analyzed the traffic before the direct-tcp connection and examined PCAP traffic.
Figure 1. Logs from 125.20.251.66 at the time of the direct-tcp connection request showing source port of 32069 in a red box
Figure 2. PCAP and TCP stream for traffic from 125.20.251.66
## Analysis
The entire stream showed the connection using the source port of 42948, which was indeed the source port for the initial SSH connection as seen in Figure 1 above.
The SSH banner "SSH-2.0-OpenSSH_7.4" was also observed in Figure 1 and the TCP Stream at the bottom of Figure 2.
All these signs suggested that the traffic was being forwarded or proxied to help obscure the real source IP.
## Proxy Connections
After successfully obtaining valid SSH credentials, the SSH tunnel would usually be set up within the second.
The majority of IPs that had direct-tcp connection requests were proxying to the destination IP of 77.88.21.158 at port 25.
77.88.21.158 port 25 seems to be the SMTP server for Yandex Mail, based in Russia, which is a common blocked location for many countries.
## Conclusion
Direct-tcp connections are usually a form of proxy connection that uses the honeypot server as an intermediary to either mask origin IPs or bypass traffic rules.
Establishing a SSH tunnel does not require root and can easily be set up as long as you have a valid user's credentials to login to the SSH server (honeypot, in this case).
However, once your server is compromised and successfully used as a proxy, it may be susceptible to various attacks.
---
# References
[1] https://github.com/bruneaug/DShield-SIEM [2] https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/ [3] https://www.imperva.com/learn/performance/time-to-live-ttl/ [4] https://search.censys.io/hosts/77.88.21.158 [5] https://www.sans.edu/cyber-security-programs/bachelors-degree/