I Deployed a Honeypot in California

What are Honeypots?

Honeypots are a network-attached system used as a trap for cyber-attackers to detect, and study the tricks and types of attacks they use. It is actually isolated, monitored, and capable of blocking or analyzing the attackers.

HoneyPot Configuration

To begin my malware analysis, I used Docker built, Telekom security’s “Tpotce” as a platform for my honeypot. I decided to deploy my honeypot in the California us-west-1 region utilizing AWS. I did so by setting up my EC2 instance along with the Debian 10 Buster AMI. I selected the t2.Xlarge instance type so that it has enough storage to run the honeypots and maintain logs of the attacks. Along with the honeypot instance, I created a security key. I went to the terminal and changed the permissions of the key to only allow me to read it by running {sudo chmod 400 <KEY.NAME>}. Once I did that, I then SSH’d into the Honeypot instance and installed git and cloned the tpotce repository, cd’d into it, and ran {sudo ./install.sh — type=user}. In the installer, I provided a username, password and selected the “Standard Configuration”. I then had lost connection during the installation. The reason I had lost connection was because Tpotce remaps many ports including the default SSH port. So I then went to the upgrade the EC2 security groups for the honeypot and edited the inbound rules:

  • I removed the default ssh rule on port 22
  • I added a custom to allow traffic on ports 1–64000 from any source (0.0.0.0/0).
  • I added a custom rule to allow me using my ip to SSH using port 64295 for accessing the EC2 VM.
  • I added a custom rule to allow me using my ip to access the administrative site using port 64297.

To verify, I SSH’d into the newly assigned SSH port and viewed the web admin portal (on port 64297) and logged in. I started by uploading API keys I got from Shodan, Alienvault, VirusTotal and configuring “Spiderfoot” to enable functionality in modules, so now I can analyze the information I capture.

Attack Synopsis

After 2–3 days of running (and pausing) my honeypot, I went in the Kabana app on the web console and I saw that I had received 150,000+ different attacks.

The honeypot I decided to use first was cowrie. Cowrie is a SSH and Telnet honeypot designed to log brute force attacks and the shell interactions performed. This allows me to analyze the usernames, passwords, and exploits they were trying to use. I did so by using Kibana and filtering down the attacks to only show me cowrie attacks. I can do this by going to the dashboard and filtering for cowrie

Analyzing these attacks showed me different types of data:

  • It showed the total number of attacks and where they originated from
  • Different parts of the world from where attacks originated
  • The attempted login names and passwords used
  • Data of attackers, such as their ASN’s and IP’s

OSINT

While I was analyzing this data I noticed that IP: 212.193.30.137 had did 208 separate attacks, so I then clicked the blue link that went to “talosintellegence.com”, to check the IP’s known reputation and saw that it was coming from Czech Republic had a poor reputation.

I also had searched for the IP in a whois lookup and found the following information:

  • Org-name: Des Capital B.V.
  • Country: NL
  • Phone: +31851308338
  • Phone: +13023803902
  • E-mail: info@des.capital
  • Address: Krammer 8
    3232HE, Brielle
    NETHERLANDS

I then went to the discovery section and filtered for cowrie, and added a filter for “input.keyword — exists” so that it would filter out for traffic that had some type of commands ran.

I selected the most resent attack (which was coming from Taiwan) and sorted it to show me what type of “Input” the “Source IP” had put.

Malware Analysis

What had caught my attention was that the attacker was trying to run /bin/busybox. Busybox is a software suite that provides several unix utilities in a single executable file. Authors dubbed it “The Swiss Army knife of Embedded Linux” as the single executable replaces basic functions of more than 300 common commands.

Username and Password Analysis

For my Honeypot I used a not so casual username and password so I can prevent brute forces and to primarily preserve the machine. I checked the usernames and passwords that the attackers had attempted using, and the amount of times they used it.

Debrief

The objective of this was to analyze and investigate malicious behavior in the real world. Using this honeypot, we were able to capture and record what happened when attackers gained access to the server. A perk of tpotce is that it operates with ELK; Elasticsearch, Logstash and Kibana, which provides the user with an effortless layout to parse through copious amounts of data.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store