Creating a Simple Honeypot Project on Kali Linux: A Step-by-Step Guide with Attack Simulation

In cybersecurity, honeypots are powerful tools that attract and capture malicious activity. Honeypots are ‘fake’ systems designed to look like real targets for hackers. When attackers try to break in, the honeypot collects information about what they do. This way, we can learn from their actions and see how they might attack a real system. They act as decoys, allowing us to observe and analyze attacker behavior. In this guide, we’ll set up a basic honeypot on Kali Linux using Cowrie, an SSH honeypot. After setting it up, we’ll simulate an attack using Kali Linux to prove it’s working.

Note: While the attacks we perform in this guide are part of a simulation, real attacks on a honeypot can be much more complex. Attackers might try different techniques to discover or bypass the honeypot’s protections. Before running a honeypot, it’s important to carefully check all settings and permissions to avoid potential security issues. This setup is mainly for learning and should be used in a secure, controlled environment.

What is Cowrie?

Cowrie is a honeypot designed to emulate an SSH and Telnet server, logging any login attempts and commands attackers try. For this project, we’ll set up Cowrie as a vulnerable SSH server, and then test it by launching an attack simulation.

Prerequisites
To start, will need:
- Kali Linux installed and updated
- Kali Purple installed for attack simulation

Before we beginningwe need to change to the root user

sudo su

Step 1: Updating the System
First,we need to update our Kali Linux system

sudo apt update && sudo apt upgrade -y

Step 2: Installing Cowrie
Cowrie isn’t in Kali’s default repository, so we’ll download it from GitHub.

1. Clone the Cowrie repository:

git clone https://github.com/cowrie/cowrie.git /home/kali/Honeypot

List content

ls

Step 3: Setting Up Python Virtual Environment

Cowrie requires a Python 3 virtual environment to run smoothly. Let’s set that up.

1. Installing the Python virtual environment package

Cowrie requires a Python 3 virtual environment to run smoothly

sudo apt install python3-venv -y

2. Creating a virtual environment within the Honeypot directory:

python3 -m venv cowrie-env

3. Activating the virtual environment:

source cowrie-env/bin/activate

Step 4: Installing Dependencies

Installing all the Python packages that Cowrie needs to function.

We should see (cowrie-env) in our command prompt

pip install -r requirements.txt

Step 5: Configure Cowrie

Once the dependencies are installed, we need to configure Cowrie:

1. Copying the sample configuration file:

We need to copy the file because cowrie.cfg.dist to cowrie.cfg because Cowrie needs this specific file (cowrie.cfg) to run. This copied file allows us to make any changes we want, like adjusting settings, without affecting the original template file. In short, it’s just setting up a configuration file Cowrie can use to work properly.

cp etc/cowrie.cfg.dist etc/cowrie.cfg

List content

ls etc/ 

We can an open the configuration file using text editor like nano to adjust settings if needed

In this file,we can customize various settings, like SSH port, logging preferences, and more. For a basic setup, you can keep the default settings.

nano etc/cowrie.cfg

Now we will Chang the hostname and SSH settings

The key reasons for that is :

1. Deceiving Attackers: Setting a hostname that looks real, like ssh_server022, creates the illusion that this is a genuine server. When attackers see a server name like this, they might believe it’s important and try harder to log in or execute commands. This gives us more data to analyze their behavior.
2. Making It Look More Real: By changing the default SSH settings (like using a different port instead of the usual port 22), we hide the fact that this is a honeypot (a trap for attackers). This makes the setup more believable, increasing the chance that attackers will take it seriously and interact with it in various ways, not just using simple automated attacks.
3. Better Log Analysis: Proper hostname and SSH port settings make it easier to understand the logs. You can quickly tell the difference between automated (bot) attacks and human-led attacks. For example, a unique hostname can help identify attacks aimed at certain types of servers.
4. Avoiding Detection by Automated Tools: Some automated tools are designed to detect honeypots with standard configurations. By changing the default settings, we reduce the chance that these tools will recognize our honeypot. This means attackers might spend more time trying to interact with it, giving us more data to collect.

Scroll down and change the host name

to

hostname = ssh_server022

Ctrl+W Look for telnet

[telnet] 

Change enabled = false

to

enabled = true

Save ( Ctrl+O) enter and Exit (Ctrl+X)

Step 6: Setting up Cowrie to listen on port 22

Cowrie, the fake SSH server (honeypot), listens by default on port 2222, not the usual SSH port, 22.

Most real SSH servers use port 22, so attackers usually try that port first. By making Cowrie look like it’s listening on port 22, we trick attackers into thinking it’s a real server.

But since Cowrie is set to listen on port 2222, we use a command to redirect traffic. This command sends anything coming to port 22 over to port 2222 where Cowrie is actually listening.

So, when an attacker connects to port 22, they’re secretly connecting to Cowrie on port 2222 without realizing it! This setup helps capture more realistic attacks.

iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

· iptables: This is the tool used to create rules for managing network traffic.

· -t nat: Specifies the NAT (Network Address Translation) table, used for traffic redirection.

· -A PREROUTING: Adds a rule to alter the packet before it reaches its destination.

· -p tcp: Indicates that this rule applies to TCP traffic (which SSH uses).

· — dport 22: The port we want to redirect (22, the default SSH port).

· -j REDIRECT: Tells the system to forward the traffic.

· — to-port 2222: Specifies the new port to which the traffic will be sent.

Redirection is like a ‘traffic detour’ on a road. Here, we’re using it to send all connection attempts on port 22 (common for SSH) to Cowrie’s actual port 2222. This way, it looks to attackers like they’re connecting to a real SSH server.

Optional — For Telnet

If we want to redirect Telnet traffic (port 23) to Cowrie’s Telnet port 2223

iptables -t nat -A PREROUTING -p tcp --dport 23 -j REDIRECT --to-port 2223

Tip: Using Different Ports for Testing

In the configuration, you can choose to set Cowrie to listen on different ports besides the common port 22. This can help make the honeypot look more realistic or test how attackers respond to different setups. For example, using unusual ports might attract attackers who scan for less common configurations, giving you more data for research. Changing ports also adds flexibility, allowing you to simulate different types of servers without needing to set up a new honeypot each time.

Step 7: Setting up permissions

Changing Ownership

/var/run: Temporary, runtime data, usually PID files and other temporary information needed for the application’s active session.

chown -R kali:kali /home/kali/Honeypot/var/run

Changing Ownership

/var/lib/cowrie: Persistent data specific to Cowrie, which may include configuration files, logs, or data created by Cowrie.

chown -R kali:kali /home/kali/Honeypot/var/lib/cowrie

Setting Permissions

chmod -R 755 /home/kali/Honeypot/var/run

Verifying Ownership

ls -l /home/kali/Honeypot/var/lib/cowrie
ls -l /home/kali/Honeypot/var/run

2. Changing to the non root user

su kali

Step 8: Starting the Honeypot

Running Cowrie to start capturing any attempted connections:

bin/cowrie start

Cowrie has started without showing any errors regarding permissions or multiple instances. The deprecation warnings about TripleDES are not critical issues and can be ignored, as they are related to older encryption algorithms that will eventually be removed in future updates.

4. Check Active Processes

ps aux | grep cowrie

ps aux: This command lists all running processes on your system.

• a shows processes for all users, not just the current user.
• u displays the user who owns each process.
• x includes processes not attached to a terminal (background processes, like services).

| (Pipe): The pipe takes the output of ps aux and sends it to the next command (grep cowrie).

grep cowrie: This part searches the output for any lines that contain the word “cowrie.” This filters out the list so that only processes with “cowrie” in their description are shown.

The Cowrie honeypot is running. The output shows a Cowrie process with the twistd command, which is used to start Cowrie, along with the relevant path and parameters.

5. Viewing the Logs

To confirm that Cowrie is capturing activity, we will check the logs for any login attempts or other interactions

tail -f var/log/cowrie/cowrie.log

Logs are records of everything that happens in Cowrie — like login attempts or commands attackers try. Reading the logs helps us to see what attackers are doing and understand their behavior. The tail command below will show you the latest entries in the logs

The log output:

• CowrieSSHFactory starting on 2222: This means Cowrie is ready to accept SSH connections on port 2222.
• HoneyPotTelnetFactory starting on 2223: Cowrie is also set up to accept Telnet connections on port 2223.

Step 9: Simulating an Attack

Setting Up the Attack from Another Instance (Kali Purple)

1. In the 2 machines checking for the IP address

ip a

On the Left (Kali) has IP 192.168.19.12

On the Right (Kali Purple) has IP 192.168.19.14

Now we need to check concoction using ping

ping <Machine_ip>

Once we confirm that both machines can communicate, we can proceed to simulate the attack

2. To simulate attacks in this environment, we will set up a few common penetration testing techniques to see how the honeypot responds

Open a terminal on the attacker machine (Kali Purple).

2.1 Attempting to connect Cowrie honeypot using an SSH client.

This will allow to simulate an interaction with the target system and observe how it responds to login attempts.

ssh <username>@<Target_IP>
ssh kali@192.168.19.12

Monitoring the Logs on Cowrie

tail -f var/log/cowrie/cowrie.log

The logs shows what happend

Login Attempts:

The log shows that someone (in this case, from the IP address 192.168.19.14) is trying to log in to the Cowrie honeypot using the username kali.

Password Failure:

• Each time the person tries to log in, they enter a password. The log records that the password they used is incorrect:
• For example, the log says failed auth b’password’, meaning the password they tried did not work.
• When you see Permission denied, please try again., it means the login attempt was unsuccessful because the password was wrong.

Multiple Attempts:

• The logs show that the person kept trying to enter the password but failed each time. This is useful information because it shows that someone is actively trying to access your server but does not have the correct password.

Capture of Attacker Behavior:

The logs are showing that someone is trying to connect to the Cowrie honeypot but is failing because they are entering the wrong password.

2.2 Attempting a Brute-Forcing SSH Logins Attack with Hydra

• Hydra: Hydra is fast and works well for trying to break into many types of services, like SSH, FTP, and others. It’s a good choice if you want a quick test or if you’re working on a smaller system with fewer resources.

If testing with a small number of passwords, Hydra is a simple and fast choice.

hydra -l kali -P /usr/share/wordlists/rockyou.txt ssh://<Target_IP> -t 4
hydra -l kali -P /usr/share/wordlists/rockyou.txt ssh://192.168.19.12 -t 4

Monitoring the Logs on Cowrie

tail -f /home/kali/Honeypot/var/log/cowrie/cowrie.log

• Hydra is actively trying to guess the password for the kali user using the specified wordlist.

This setup provides a clear picture of how attackers interact with our honeypot, and the logs will help us to analyze their behavior.

2.3 Attempting a Brute-Forcing Logins Attack with Medusa

• Medusa: Medusa is known for being able to handle larger-scale attacks because it runs multiple attempts at once, making it great for testing many usernames or passwords at the same time. It’s best for cases where you have more data or want to simulate attacks on a bigger system.

If testing with a larger number of passwordsor trying more complex tests, Medusa is more powerful and efficient.

medusa -h <Target_IP> -u kali -P /usr/share/wordlists/rockyou.txt -M ssh -n 22
medusa -h 192.168.19.12 -u kali -P /usr/share/wordlists/rockyou.txt -M ssh -n 22

· medusa: This is the name of the tool you are using. Medusa is a fast, parallel, and modular login brute-forcer, which is commonly used for penetration testing.

· -h <Target_IP>: This option specifies the target IP address of the system you are attempting to connect to. In this case, it’s the IP address of your Cowrie honeypot.

· -u kali: This option specifies the username you are attempting to log in as. Here, you are using kali as the username. You can change this to any other username if you want to test different accounts.

· -P /usr/share/wordlists/rockyou.txt: The -P option specifies the path to the password list you want to use for the brute-force attack. In this example, you are using the popular rockyou.txt wordlist, which contains a large number of common passwords.

· -M ssh: This option specifies the module to use. In this case, ssh indicates that you are attempting to brute-force an SSH login.

· -n 22: This option specifies the port number to connect to. You are using port 22, which is the default port for SSH connections. However, in your Cowrie setup, you should actually use port 2222 because that’s where Cowrie is listening after the redirection.

Monitoring the Logs on Cowrie

tail -f /home/kali/Honeypot/var/log/cowrie/cowrie.log

The logs output shows

Login Attempts:

The logs show that there are multiple login attempts being made from the IP address 192.168.19.14 (your attacking machine).

The username being tested is kali, and the logs are recording attempts with different passwords.

Failed Authentication:

Each time a password is tried, the log indicates whether the attempt succeeded or failed. For instance:

This means that the attempt to log in using the password arsenal was unsuccessful.

Password Checks from Medusa:

The output from Medusa shows it is attempting to authenticate with various passwords against the SSH service on the honeypot.

Step 10: Stopping the Honeypot

bin/cowrie stop

Step 11: Summary and Recommendations for Improvement

1. Data Analysis:

• Review Logs: Checking the logs from Cowrie to see how attackers are trying to access the honeypot. Look for:
• Common Usernames: See which usernames are being used the most. This will help you understand which accounts attacker’s target.
• Common Passwords: Identify which passwords are attempted frequently. This information can show you what passwords attackers think are easy to guess.
• Frequency and Timing: Note how often login attempts happen and at what times. This can reveal patterns in attacker behavior.
• Unusual Patterns: Look for any strange or unexpected behaviors in how attackers are trying to log in. This could indicate a new method being used.

2. Enhance Honeypot Functionality:

• Adding More Usernames:
• Changing Cowrie setup to include additional usernames. By testing with different usernames, we can see if attackers have specific preferences for certain accounts.
• Testing Different Password Lists:
• Try using different password lists instead of just the rockyou.txt file. This can help to see how attackers respond to various passwords and which ones they struggle with the most.

3. Adding Network Monitoring

• Using tools like Wireshark or Zeek alongside Cowrie can give more details about how attackers connect to the honeypot. These tools help us see the network traffic, showing us what type of connection or requests the attacker used to reach the honeypot.
• Why is this helpful?

1. Track Attack Patterns: We can see if the attacker tried different techniques to connect.
2. Detect Suspicious Activity: By monitoring traffic, we might catch any unusual patterns that can reveal more about the attack.
3. Complete the Picture: Combining Cowrie logs with network monitoring gives us a full view of the attacker’s actions, both on the network and inside the honeypot.

Conclusion

By analyzing the logs and enhancing the functionality of the honeypot, we can gain deeper insights into how attackers operate. This will not only improve the honeypot’s effectiveness but also help us build better defenses in the future.

Keep experimenting and learning from the data that was collect!