As cyber threats continue to evolve, organizations are looking for new ways to improve their security. One approach that has gained a lot of popularity in recent years is the use of honeypots.

A honeypot, as the name itself implies, is a decoy system that is designed to attract and detect attackers. By setting up a honeypot in your cloud infrastructure, you can gain valuable insights into the tactics, techniques, and procedures used by attackers, and use this information to improve your overall security.

In this article, we'll provide a step-by-step guide to setting up a honeypot in your cloud environment. We'll cover everything from choosing the right type of honeypot to configuring logging and alerts, and show you how to use the data collected to improve your organization's security posture.

Choose a type of honeypot

To build a honeypot for your cloud infrastructure, you first need to choose a type of honeypot. There are several options to choose from, including low-interaction, medium-interaction, and high-interaction honeypots.

  • Low-interaction honeypots are easier to set up and maintain, but provide less information about the attacker's activities. They can be used to simulate services and passively log connections.
  • Medium-interaction honeypots can simulate services and are capable of responding to the attacker in an expected manner.
  • High-interaction honeypots are more complex, but provide more detailed information by simulating the entire system. You should also consider the type of service or application you want to simulate, such as a web, SSH, or email server.

Based on the unique requirements and objectives of your organization, you should choose the most adequate type of honeypot for your business. While choosing a honeypot type, keep the following things in mind:

  1. Intention: Set up a honeypot objective first before anything else. Are you trying to detect, monitor, or analyze attacks? Or do you want to gather information on certain attack types or attackers? Your goals will aid in determining the best sort of honeypot to use.
  2. Resources: Take into account the financial, human, and other resources you have at your disposal. While some varieties of honeypots are more complicated and demand more resources to set up and administer, others are simpler and need less work.
  3. Technology: Your company's technological stack should be compatible with the honeypot type you select. For instance, if the majority of the computers in your business are Linux-based, you might want to think about using a Linux-based honeypot.
  4. Threat Profile: Think about the dangers that worry you the most. If your business is in the banking sector, for instance, you might be particularly worried about assaults that target financial data. You might wish to pick a honeypot that imitates financial services in this case.
  5. Compliance: Take into account any regulations that your organization must comply with. You need to select a honeypot that conforms with your organization’s policy.
Set up the honeypot

Once you've chosen a type of honeypot, you'll need to set it up in your cloud environment. This involves creating a virtual machine or container, installing the necessary software and services, and configuring the honeypot to simulate a legitimate system or service.

Configure logging and alerts

To monitor the activity of the honeypot, you'll need to configure logging and alerts. This involves setting up a separate logging server, configuring log rotation and retention policies, and setting up alerts to notify you of any suspicious activity..

Monitor and analyze activity

Once the honeypot is up and running, you'll need to monitor its activity and analyze any data that is captured. This involves reviewing logs, analyzing network traffic, and identifying any patterns or anomalies that may indicate an attack.

Use the information to improve security

The information collected from the honeypot can be used to improve your organization's security posture. For example, you may use the data to identify vulnerabilities in your infrastructure, refine your incident response plan, or enhance your threat intelligence.

Cowrie - mid to high interaction level SSH/Telnet honeypot

For this tutorial, we’ve decided to use AWS EC2, hosting an Ubuntu virtual machine with an installation of Cowrie honeypot mocking an SSH/Telnet server.

Cowrie will be capturing SSH brute force attack attempts and the commands executed by an attacker upon successful login.

For installing Cowrie, you can follow the official tutorial. Have in mind that in order for your honeypot to serve its purpose, it needs to be accessible from the internet. If that’s not already the case, you need to figure out what type of network setup you have. Depending on that, you should undertake adequate steps to enable the forwarding of the ports you want to use.

If you’ve followed the official tutorial as we did, you should be able to run Cowrie with this command (from the directory where you cloned it with Git):

cowrie@ip-172-31-40-59:~/cowrie$ bin/cowrie start

To verify that your honeypot is up and running, you can execute this command, which will show you the latest log entries:

cowrie@ip-172-31-40-59:~$ tail -f /home/cowrie/cowrie/var/log/cowrie/cowrie.log

If everything is in perfect order, you should see something along these lines:

2023-03-13T14:55:19.942805Z [-] Cowrie Version 2.5.0
2023-03-13T14:55:19.946051Z [-] Loaded output engine: jsonlog
2023-03-13T14:55:19.947198Z [twisted.scripts._twistd_unix.UnixAppLogger#info] twistd 22.10.0 (/home/cowrie/cowrie-env/bin/python3 3.8.10) starting up.
2023-03-13T14:55:19.947302Z [twisted.scripts._twistd_unix.UnixAppLogger#info] reactor class: twisted.internet.epollreactor.EPollReactor.
2023-03-13T14:55:19.954489Z [-] CowrieSSHFactory starting on 22
2023-03-13T14:55:19.955127Z [cowrie.ssh.factory.CowrieSSHFactory#info] Starting factory <cowrie.ssh.factory.CowrieSSHFactory object at 0x7fc20fa8b9d0>
2023-03-13T14:55:20.009708Z [-] Ready to accept SSH connections
2023-03-13T14:55:20.013185Z [-] HoneyPotTelnetFactory starting on 23
2023-03-13T14:55:20.013572Z [cowrie.telnet.factory.HoneyPotTelnetFactory#info] Starting factory <cowrie.telnet.factory.HoneyPotTelnetFactory object at 0x7fc20fa8ba90>
2023-03-13T14:55:20.014547Z [-] Ready to accept Telnet connections

Notice that we’ve got our SSH honeypot running on port 22 and our Telnet honeypot running on port 23. Initially, upon installing Cowrie, Telnet will be disabled by default and SSH will run on port 2222. 

What we did to make the bait more credible and increase the likelihood of being attacked is change the VM SSH port to another port number and place the honeypot SSH port number to 22 instead. We also enabled Telnet to widen up the attack vector and changed its port number to 23 instead of 2223 (which was set by default).

You can do it as well by following the optional step 7 of the official Cowrie tutorial. We had some difficulty following the official steps, so just in case you run into the same problem, here are the steps that worked for us:

Change your regular SSH port to another port number

If you are using SSH to connect to your Cowrie host machine, it is important to assign another port number to the SSH daemon (sshd). We recommend you choose a number between 49152 and 65535, as these ports are highly unlikely to interfere with any other services that might be running on your machine.

If you are operating this machine locally through bash, you can skip this step, just make sure that your SSH daemon is disabled to avoid interference. You can change the SSH port in a few simple steps:

Step 1: Open your SSH config file as sudo using nano text editor:

cowrie@ip-172-31-40-59:~$ sudo nano /etc/ssh/sshd_config

Step 2: In sshd_config look for the line that says “#Port 22”, remove the hash symbol, replace the 22 with the desired port number, and save the changes.

Change the Cowrie config

Again, if you followed the same installation procedure that we did, you should be able to edit the configuration parameters using this command:

cowrie@ip-172-31-40-59:~$ sudo nano /home/cowrie/cowrie/etc/cowrie.cfg

This is how your file should look:

[ssh]
enabled = true
listen_endpoints = tcp:22:interface=0.0.0.0,authbind=true

[telnet]
enabled = true
listen_endpoints = tcp:23:interface=0.0.0.0,authbind=true

Grant permissions to Cowrie

To grant permission to the user cowrie to bind to ports below 1024 using authbind, you need to execute these 5 commands in this exact order:

cowrie@ip-172-31-40-59:~$ sudo apt-get install authbindcowrie@ip-172-31-40-59:~$ sudo touch /etc/authbind/byport/22
cowrie@ip-172-31-40-59:~$ sudo touch /etc/authbind/byport/23
cowrie@ip-172-31-40-59:~$ sudo chown cowrie:cowrie /etc/authbind/byport/{22,23}
cowrie@ip-172-31-40-59:~$ sudo chmod 755 /etc/authbind/byport/{22,23}

Apply changes

Now, all that’s left to do is run a simple reboot command and restart Cowrie once the system boots, as it doesn’t autorun on startup by default.

To verify that the procedure went smoothly, we recommend you run the tail command on the Cowrie log file again and check that it’s listening on ports 22 and 23, as it shows in our cowrie.log above.

Analyze

Now, let’s run a simple test to figure out how to analyze the logs.

Here we try to connect to our SSH honeypot as the user root with password “1234”, and this is what the logs show:

2023-03-13T18:33:25.583229Z [HoneyPotSSHTransport,0,95.168.120.51] login attempt [b'root'/b'1234'] succeeded
2023-03-13T18:33:25.583732Z [HoneyPotSSHTransport,0,95.168.120.51] Initialized emulated server as architecture: linux-x64-lsb
2023-03-13T18:33:25.584099Z [cowrie.ssh.userauth.HoneyPotSSHUserAuthServer#debug] b'root' authenticated with b'password'
2023-03-13T18:33:25.584508Z [cowrie.ssh.transport.HoneyPotSSHTransport#debug] starting service b'ssh-connection'
2023-03-13T18:33:25.663789Z [cowrie.ssh.connection.CowrieSSHConnection#debug] got channel b'session' request
2023-03-13T18:33:25.664217Z [cowrie.ssh.session.HoneyPotSSHSession#info] channel open
2023-03-13T18:33:25.664561Z [cowrie.ssh.connection.CowrieSSHConnection#debug] got global b'no-more-sessions@openssh.com' request
2023-03-13T18:33:25.867947Z [twisted.conch.ssh.session#info] Handling pty request: b'xterm-256color' (49, 104, 640, 480)
2023-03-13T18:33:25.868267Z [SSHChannel session (0) on SSHService b'ssh-connection' on HoneyPotSSHTransport,0,95.168.120.51] Terminal Size: 104 49
2023-03-13T18:33:25.869050Z [twisted.conch.ssh.session#info] Getting shell

As seen in the logs, our login attempt from 95.168.120.51 was successfully captured. This means we’re fully set and ready to hunt!

Extra: Build a Canary Trap

If you aren’t already familiar, a “canary trap” is a technique for detecting information leaks by spreading different false information to multiple people, then using it to determine who’s the mole in the (i.e. intelligence) community.

Cowrie provides us with that possibility as well!

Being able to log in with a null password or guessing the correct one in the first try would definitely seem sketchy from the attacker’s point of view. Luckily, you can configure Cowrie SSH to accept only a specific set of passwords and usernames. We’ve defined a list of accepted passwords by editing a userdb.txt file.

You can do this using this command:

cowrie@ip-172-31-40-59:~$ nano cowrie/etc/userdb.txt

Using nano text editor, you can predefine acceptable credentials in this manner:

suspectMike:x:canarypass1
suspectSteve:x:canarypass2
suspectTom:x:canarypass3

In the first entry “suspectMike” stands for username, “x”  is a currently unused value, and “canarypass1” would be the pass given out to the suspect.

Have in mind that after saving the file you need to restart Cowrie for these changes to be applied. Overall, Cowrie appears to be more of a high-interaction than a mid-interaction honeypot, as it emulates the filesystem almost perfectly to the point of remembering changes done to it until it gets restarted.

You will be able to analyze every command that the attacker used in their attempt to exploit your SSH/Telnet server and prepare for that kind of attack being performed on your real servers, compromising your business and profiting from your lack of awareness. At the end of the day, Cowrie’s capabilities only depend on the way you set it up and use it.

Subscribe to be updated on the new content!

Subscription Form (#4)