Creating and analyzing Debian based T-POT honeypot on AWS
What is a Honeypot?
Honeypot is a decoy computer system that mimics the real computer system and baits attackers to waste time and resources exploring the honeypot system instead of the actual live, production system. An attacker becomes bogged down in the honeypot system trying to escalate privileges or attempting to pivot onto other systems in the network.
And this is where an immense second benefit of a honeypot comes in — we can actually observe, log and analyze all of the actions of the attacker, studying their Tactics, Techniques ( or Tools), and Procedures (TTPs). We can learn a great deal from the enemy, and apply the knowledge to strengthen our defenses and counter future attacks.
Setting up a Honeypot on AWS
So, let’s go ahead and setup an actual Honeypot on AWS so we can create an actual public facing system that can replicate an production system that we would spin up on AWS.
As we will be installing T-POT that uses the ELK to monitor the attacks and the many honeypots running in docker containers, we will need to get at least t2.Xlarge instance to support T-POT’s pretty heft system requirements:
At LEAST 8GB of RAM
128GB SSD as less space can limit the capability of storing event logs.
Before we launch our Honeypot, let’s harden the security on the AWS side so our Honeypot is not taken over and used against us. That would be bad!
In our security group for this particular EC2 instance we are going edit Inbound Rules to open up ports up to 64000 and use ports 64297 and 64295 for WebAdmin login and SSHing into our machine. We will also restrict the access administration ports to our IP only for additional security.
After the system is launched, let’s bring Debian up to the latest version
sudo apt update && apt upgrade
We are also installing Git
sudo apt install git
After we get Git (get it?), let’s clone T-POT and run the installation script
git clone https://github.com/telekom-security/tpotce.git
sudo ./install.sh –type=user
The setup is pretty straightforward:
After the successful installation we should be able to use our username and password created earlier to login into T-POT’s web admin page using
https://<your AWS instance public IPv4 address>:64297
Done!
Let the Honeypot sit there and attract attackers for a while.
Ok, after letting Honeypot sit in a public facing environment for some time let’s start looking at data and analyzing what type of attacks were logged on our T-POT.
First, we will take a look at Cowrie — a medium to high interaction SSH and Telnet honeypot designed to log brute force attacks and the shell interaction performed by the attacker. Since SSH and Telnet, along with RDP, are ones of the most common attacks, it makes sense to start here.
Immediately we notice the username and password list that was used by attacking bots:
What I have noticed is that username:password lists for attacks seem to be geographically dependent.
Since I spun up my AWS instance in Mumbai, India, logs were slightly different then what I have observed from other security researchers who had their Honeypots located in Japan and North America. I find it interesting that scanning and attacking bots are programmed to use wordlists based on victim’s machine IP location!
Cowrie also breaks down attacks by signature:
CVE type:
And attackers and scanners providers and IPv4 addresses:
Cowrie also logs files uploaded by the attacker:
And creates a hash value for the file that we can go ahead and examine
As we can see two sandboxes identified the file that was posing as DOTA game file as malicious.
Conclusion:
As we can see exposing any system to the internet without security hardening first is extremely risky. According to our Honeypot the attackers are Bots, or Internet robots, are also known as spiders, crawlers, and web bots. While they may be utilized to perform repetitive jobs, such as indexing a search engine, they often come in the form of malware. Malware bots are used to gain total control over a computer and are used to search for openings before an actual human attacker would try to gain access of the machine based on bot’s findings. From the list of attempted credentials, we can see that bots go for “low-hanging fruit” first. There are no sophisticated 0-day attacks being wasted, but simple brute-forcing of default credentials. Our findings are mimicking the recent Joint Cybersecurity Advisory (https://media.defense.gov/2022/May/17/2002998718/-1/-1/0/CSA_WEAK_SECURITY_CONTROLS_PRACTICES_EXPLOITED_FOR_INITIAL_ACCESS.PDF ) that weak security controls are first to be exploited. I highly recommend following best practices to protect any public facing system:
Best Practices to Protect Your Systems
· Control access.
· Harden credentials.
· Establish centralized log management.
· Use antivirus.
· Employ detection tools.
· Operate services exposed on internet-accessible hosts with secure configurations.
· Keep software updated.
Have a safe and secure day!
