My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

SSH Honeypots (Ab)used as Proxy

Published: 2016-03-13. Last Updated: 2016-03-14 08:23:10 UTC
by Xavier Mertens (Version: 1)
10 comment(s)

I’m operating a small group of SSH honeypots (located in Belgium, Canada & France) and I’m of course keeping an eye on it every day. Collected data are sent to DShield and to my Splunk instance. A small reminder: if you’ve a spare Raspberry Pi lying around, why not deploy a honeypot and help us to collect more data? Johannes posted a script to automate the setup and is looking for beta testers!
 
Cowrie is a wonderful honeypot. Not only, it tracks login attempts and, when the attacker successfully connected, it also simulates a real server with a fake file system and commands. But it can also simulate "Direct-TCP" requests. This is a nice feature offered by SSH servers that allow a user to create TCP sessions inside the SSH tunnel. This feature is called "Port Forwarding". It is used by many people who need to access a service not directly reachable from their current location. Example: you have a web interface to manage an appliance that is not available but you have a SSH server in the same subnet. Just do this:  (The appliance is 192.168.254.10, the SSH server is 192.168.254.2)
$ ssh -L 8443:192.168.254.10:443 user@192.168.254.2
Then point your browser to https://127.0.0.1:8443/.
More interesting: To surf the web anonymously, you can use dynamic port forwarding with the '-D' flag:
$ ssh -D 8080 user@192.168.254.10
Then, configure your browser to use 127.0.0.1:8080 as a SOCKS proxy and you will surf the web with a source IP address of 192.168.254.10.
Note: This feature is enabled by default in OpenSSH and can be disabled by adding 'AllowTcpForwarding No' to your sshd_config. With SSHv2, you can also only permit some users or groups to use this feature.
 
If it's so easy and useful for good people, you can imagine that it's even more interesting for attackers that could then hide their IP address. A few days ago, I detected an unusual amount of events generated by some of my honeypots. Regarding my honeypots, there was an huge increase of “Direct-TCP” requests over the past 7 days:
 
Event Hits
cowrie.direct-tcp.request 24242
cowrie.direct-tcp.data 22967
cowrie.log.open 15130
cowrie.log.closed 14679
cowrie.session.connect 13882
cowrie.session.closed 13877
cowrie.command.success 11563
cowrie.client.version 9019
cowrie.login.success 8652
cowrie.command.failed 3948
 
A closer look to the "Direct-TCP" requests shows clear a peak of activity for the last days:
 
 
The most affected honeypots are the ones located in France (Paris) and Canada (Ontario). The top attackers were located in the following countries:
 
Country Hits
Germany 22405
Russia 1295
United States 267
Argentina 76
France 51
Switzerland 35
Netherlands 26
Ukraine 20
India 16
Iran 16
 
Germany came in first place just with two distinct IP addresses. And what about the destination? Here is the top-10:
 
 
The attackers tried to use the honeypot mainly for mail and web traffic, based on this top-10 destination ports:
 
TCP Ports Hits
80 31431
25 1428
587 383
443 271
465 160
110 30
143 13
1101 4
1102 4
89 1

If we analyze the relations between the honeypots, sources and destinations, we see that some destinations (blue) were targeted by more than one attacker (green) connected on different honeypots (red):

About the web traffic, the top destinations  were:
  • www.google-analytics.com
  • tags.tagcade.com (an ads tag management system)

Some people trying to abuse those services? Feel free to share your findings if you also detected such kind of activity!

To conclude: attackers are not only scanning the Internet to find vulnerable hosts and turn them in bots. They are also looking for ways to hide themselves to perform (maybe) more complex or dangerous attacks.

And keep in mind that if you allow users to SSH to systems that can access the Internet, they can be used as a solution to bypass classic controls in place!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

10 comment(s)
My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

Comments

Hi,

is it possible disable Port Forwarding in cowrie?
Searching into my logs... I guess they are using me for spam attacks?!

# Port dst
6828 25
1735 587
790 465
352 80
237 25000
...

Should I use iptables to block outgoing requests?

Thank you very much,
Al
I don't think, that that ssh trick for anonymous surfing works as described.

If I connect to a computer via a private ip address - as shown in the example - and use this computer as a proxy, I don't surf the web with that computers private, but with it's public ip address.

If I could surf showing a private IP address only, that would indeed be an absolutely anonymous surfing. Unfortunately an absolutely unroutable surfing as well..

But surfing under the public address of a third server is more like surfing under a false flag. Since someone is the owner of this proxy and this owner will be able to trace back my surfing session to my computer. Or, if I'm the owner of this server byself, I haven't won anything.
I'm not aware of such configuration flag but cowrie is a honeypot. Connections are NOT initiated to the outside world.
They are intercepted and logged. No need to prevent them with your local firewall.
Don't disable them, log them and enjoy :)
Of course, you will browse the web based on the remote infrastructure (maybe also trough a proxy), I could have give more details. The owner of the compromized box (or an incident handler) will be able to get your IP address.
But:
- If such SSH server is badly configured, I doubt that logs will be collected (and reviewed!) (IMHO)
- SSH does NOT log TCP forwarding events by default, you'll have to correlate multiple sources to get the attacker's IP. A starting incident could be: "Why is this server sending HTTP requests to Facebook?"

For most of the script kiddies, it is safe enough to abuse SSH servers!
I've been seeing those in my Cowrie for some time now :-)

Source IP statistics:

# Attacker IP
13353 193.169.52.221
7121 193.169.52.214
4882 193.169.52.213
2315 193.169.52.220
621 193.169.52.211
78 193.169.52.212
47 193.169.52.210
17 193.201.225.84
9 193.201.227.200
2 136.243.55.198
1 199.255.137.120

Destination TCP port statistics:

# Target port
22835 25
2575 587
1061 465
1025 80
522 443
293 25000
48 2525
31 26
16 3535
7 143
5 8025
5 6125
5 1025
4 53
3 8800
3 165
2 7777
2 5050
2 250
2 2025
Thanks for sharing Bjorn! It's interesting to see that the port/applications are the same (mail, web).
I've been briefly blogging about these observations as well, also trying out some different visualizations. In chronological order:

http://bl0gg.ruberg.no/2016/02/honeynet-outbound-probes/
http://bl0gg.ruberg.no/2016/02/visualizing-honeypot-activity/
http://bl0gg.ruberg.no/2016/03/visualizing-honeypot-activity-part-ii-tree-maps/

The sheer number of attempts makes relationship maps difficult with data for more than a few days. I've found drill-down treemaps useful for this kind of focused activity.
Which log in Cowrie are you looking at to see the outbound connections? I've just started playing with it and the only one I've been monitoring is the cowrie.log.
Enable the output engine: jsonlog.
A 'cowrie.json' log will be created.
They aren't abusing anything.

Look at the referred tag. I've been doing a very intense study of this and have found that folks using socks proxying in this matter browse pretty much one thing; Porn. And lots of it.

Zach W.

Diary Archives