Categories
Security

Project Honeypot

I haven’t had much time to focus on Capture the Flag exercises recently, but I decided to setup a SSH honeypot for a few days to see what data I could capture. From the outset, I presumed most of the traffic would be botnets so I wanted to see if there was any targetted activity I could identify.

I was also curious to see where most of the attacks would originate from, if there were any patterns in the data, and generally remind myself how much of a cesspit the internet is. This blog post details my findings.

Summary of steps

  • Download and install Cowrie.
  • Configure Cowrie to write logs to an SQL database
  • Configure userdb.txt to accept a few common usernames/passwords. I tweaked this throughout the process once I learnt more about my attackers.
  • Download and install Kippo-Graph to analyse data (originally made for an older honeypot tool called Kippo which has been abandoned. Cowrie is a fork of Kippo so the Kippo-Graph tool continues to work).

Data

Start Time (UK Time)End Time (UK Time)
Monday, 22-Jun-2020, 09:28 AMThursday, 25-Jun-2020, 15:53 PM

Much to my surprise, there wasn’t as much volume to the honeypot as I was initially expecting. Over the 3-4 day period, there were 24743 login attempts, from 822 different IP addresses.

You can download the data collected during the honeypot experiment below. I have intentionally redacted the IP addresses that hit the honeypot, but you will find details on AS Numbers, along with other interesting data collected.

DataDescriptionDownload Link
Full Database (SQL Format)Full database download. IP addresses from session table has been redacted. This contains all commands executed, the SSH fingerprints captured, session timing and more.Download

Pew Pew Map

I didn’t know what a ‘Pew Pew Map’ was until I started my own honeypot. Thumbs up to whoever thought of the name! This Pew Pew Map represents the 65 countries where attacks originated from.

Arrow ColourDescription
GreenLess than 10 distinct IP addresses from country attacked honeypot
YellowMore than 10 distinct IP addresses from country attacked honeypot
RedMore than 100 distinct IP addresses from country attacked honeypot

Botnets and behaviour observed

Inevitably, most of the traffic to the honeypot was going to be from botnets. It is hard to distinguish which are botnets and which aren’t – but I am fairly confident most of the activity I saw was automated in some way. Here is a summary of some of the botnets and other activity observed during my experiment.

1) Raspberry Pi Botnet

A botnet which seemed to be targetting Raspberry Pi’s was the first one to access the honeypot, and was seen many times throughout the week. The botnet seemed to use stock/common Raspberry Pi passwords to guess its way into SSH. Once connected, it copied a bash script to the machine via SCP, and attempted to execute it. Googling this bash script suggests it has been around for quite a long time. It is not clear if this is just a new variant of the original malware, or if it is the same malware that is just perpetuating.

What surprised me was just how simple this bash script was – yet, it is clearly effective, due to the amount of times this botnet hit my honeypot. A copy of the malicious shell script can be found here. Download at your own risk and whatever you do, do not run this on your environment.

Summary of Malware steps:

  • Killed several processes on the machine. I don’t know why it does this, but I believe this is some form of cryptocurrency mining malware, and is attempting to kill off competing malware?
  • Maps 127.0.0.1 to bins.deutschland-zahlung.eu in /etc/hosts – this is odd. The domain does exist according to WHOIS, but doesn’t actually resolve anywhere.
  • Modifies user passwords and adds a root SSH key, presumably in case access is required at a later date.
  • Adds 8.8.8.8 as a nameserver in /etc/resolv.conf
  • Generates a random string based on the MD5SUM of the output from uname -a.
  • Uses the randomly generated string as a username to login to the Undernet IRC server, and connects to the #biret channel – perhaps this channel is used as a command and control server, and issues commands to the infected machines.
  • Uses apt-get to install zmap and sshpass.
  • Uses zmap to generate a file containing 100,000 IP addresses saving the output into a file.
  • Loops all IP addresses in the file and attempts to propagate itself onto other machines, and presumably repeat the same steps when it reinfects another host.

My thoughts

  • In some ways, this script is really clever in just how simple it is. They’ve managed to use bash to connect to an IRC server, all within a few simple lines of code. They didn’t need to use Python or any other language to achieve this.
  • In other ways, this script is really stupid. The script appears to generate a random username (for connecting to IRC) based on the output from ‘uname -a’. Given they are targetting Raspberry Pi devices, I can’t imagine they are going to get many distinct usernames generated and there will likely be collisions when infected hosts connect to IRC. This is far from ideal if they are using IRC as their command and control server, and rely on successful IRC connections to issue commands.
  • Every compromised host is going to connect to the specific IRC channel on Undernet. I wonder if you could automate the abuse notifications to the ISP’s based on the IP addresses connecting to this channel? Probably.

2) Generic Trojan

I also noticed a few sessions which attempted to connect to a few IP addresses using wget and download malware. The commands run by each of the sessions were identical so this indicates this is likely automated activity / a botnet. Both IP addresses belonged to AS53850 GorillaServers, Inc.

I’ll refrain on providing links to the actual malware, but the SSH connections which were made were from the same IP address used in the wget command to download the malware. The malware information can be found here: https://urlhaus.abuse.ch/url/393777/.

3) GCHQ Activity

For those of you who don’t know, GCHQ is an intelligence and security organisation within the UK (Government Communications Headquarters). Over the course of the experiment, I had several connections from various IP addresses downloading a shell script called deivater.sh – this shell script (when executed) would then download several other shell scripts, which in turn seemed to download some form of malware. I couldn’t really see what this malware was doing, but I did dig a bit deeper into the URLs where they were downloading the malware from.

Interestingly, one of the connections downloaded malware from a website that had this message on the front page:

I’ll admit – this did make me laugh. They could have put a bit more effort in if they genuinely wanted people to believe this was under GCHQ control.

Visit the URL at your own risk. It may contain malicious content.
c2 . gov . uk . nova . dashki . pw

Besides, no doubt GCHQ already have a backdoor built into the Linux Kernel.

GCHQ, you may want to take a look at this.

4) Human or bot?

Looking at the logs and activity, it can be quite difficult identifying what activity is from automated bots, and what is human based activity. What you can do though is retrieve the terminal window size of the user who is connecting to SSH. In the case of automated scripts/bots, the terminal size is typically null as there is no terminal window open. In the case of humans, there is generally a terminal size provided in the connection details.

There were two IP addresses in total which had terminal sizes specified during the honeypot experiment. I can’t tell if they are bots or not really but they did try to stop the iptables service after realising their wget command wasn’t working which makes me believe this was actually a confused human falling straight into my honeypot trap. Busted!


Overall, creating a honeypot was generally quite interesting. I will likely do this again in the future as it’s interesting to get a feel for the botnets currently spreading around the world. If you are a researcher looking into some of these botnets, please get in touch as I would love to hear from you.

Until next time.

Categories
News Opinions Privacy

eBay is port scanning your system when you visit their website

Something that caught my attention on The Register today – eBay appears to be port scanning computers of their users when they connect to the website.

Potentially, they are doing this to try and prevent those with malware from using their service in an attempt to decrease fraud? It does raise some concerns though. Is what they are doing legal? I know that if I started port-scanning eBay, it definitely would not be considered legal, so why can they do it?

When you visit their website, JavaScript code is executed within your browser which attempts to probe various ports on your system. This JavaScript is executed locally within your browser, so bypasses any restrictions you have in your router firewall. Not only are they testing these ports without consent of their users, but the test being executed is ran locally on a users machine (from within the users network), so is potentially revealing network services that are not even exposed to the outside-world.

In the article written by The Register, it appears they are testing at least 13 different ports. This data then appears to be sent to ThreatMetrix, who are no doubt helping collate this information for eBay.

If you haven’t got a JavaScript blocking plugin installed in your browser (such as NoScript), now is definitely the time to consider installing one. There is no legitimate reason they should be doing this. This is a step too far.