Cowrie SSH Honeypot + Splunk Monitoring

Project Objective

After taking a course on cybersecurity I wanted to see firsthand what kind of threats were present out in the wild of the internet. Was it full of the dangers I was led to believe?

The goal was to build an internet-facing SSH honeypot that could safely capture unsolicited connection attempts, credential guessing, and commands entered after a simulated compromise. This would allow me to see how many attackers are out there and the methods they are using when they find a host to attack. The project also created an end-to-end monitoring pipeline so Cowrie JSON events could be analyzed in Splunk rather than reviewed only from local log files.

Architecture and Security Design

I set up Cowrie, an open source SSH and Telnet honeypot on an Ubuntu VPS hosted by DigitalOcean. Since SSH normally uses port 22, I moved the server’s real SSH connection to port 2222 and left port 22 open for the honeypot. This meant anyone scanning the server and trying to connect over the standard SSH port would reach my honeypot instead of the real SSH service.

Cowrie recorded the activity it received as JSON logs. I used the Splunk Universal Forwarder to send those logs to Splunk through port 9997, where I could analyze the activity.

• Internet → Port 22 → Cowrie SSH honeypot

• My Admin Connection → Port 2222 → Real SSH

• Cowrie logs → Splunk Universal Forwarder → Port 9997 → Splunk dashboards

Deployment and Troubleshooting

Port separation

I checked the open ports to make sure that Cowrie was running on port 22 while my real SSH connection was still on port 2222. This kept the honeypot separate from the connection I used to manage the server.

Figure 1. Cowrie on port 22 and administrative SSH on port 2222.

Troubleshooting a privileged-port failure

When I first set up Cowrie, it couldn't run on port 22 because of a permissions error. I had to troubleshoot the Linux permissions and configuration to get it working. Once I fixed the issue, I checked the ports again to make sure Cowrie was running on port 22 and my real SSH connection was still available on port 2222.

Figure 2. Verification that the real SSH service is listening on port 2222, keeping administrative access separate from the Cowrie honeypot on port 22.

Splunk Log Pipeline

Next, I needed a way to get the activity Cowrie was recording into Splunk so I could actually analyze it. I installed the Splunk Universal Forwarder on the honeypot server and had it send Cowrie’s logs to Splunk over port 9997.

After setting that up, I checked the forwarder to make sure it was connected to Splunk. I also tested port 9997 to confirm that the honeypot server was communicating with the Splunk receiver.

Figure 3. Active forwarding target and successful TCP/9997 connectivity test.

Cowrie saved the activity it captured as JSON data, including information like the attacker’s IP address, which ports were being used, when the activity happened, and what type of event occurred. As a JSON file, the data was difficult to parse. Once this data was sent to Splunk, I could search and filter the activity to figure out exactly what kind of interactions my honeypot was having and what attackers were trying to do after connecting.

Figure 4. Raw Cowrie JSON event data collected by the SSH honeypot before ingestion and analysis in Splunk.

Analysis Results

Activity over time

The timeline gave me an overview of how much activity the honeypot was receiving each day. The biggest spike came on August 8 when Cowrie recorded 261,789 events. It should be noted that these are not necessarily separate attacks but individual events, so multiple events could come from a single interaction with the honeypot.

Throughout this analysis, references to “attackers” can include automated bots and scanning tools in addition to people manually interacting with the honeypot. Similarly, a successful login only means that someone successfully entered Cowrie’s simulated environment, not that they gained access to the real server. Cowrie allows most attackers to enter so their attack patterns can be observed

Figure 5. The Attack Timeline showing a peak on August 8, 2026.

Source concentration

There was a heavyweight among the crew of attackers. 168.90.65.197 generated 227,313 Cowrie events, by far the most of any IP during the week. That one IP accounted for a massive amount of the overall activity received by the honeypot.

Figure 6. Top Source IPs. 168.90.65.197 has by far the highest volume.

usernames

When it came to usernames attackers chose for themselves “root” was by far the most popular. There were 34,692 attempts using “root” compared to the next most popular, “admin” which only had 782 attempts. This is consistent with research from the SANS Internet Storm Center which found “root” made up 48.49% of username attempts observed in their research.

Command execution

Looking at the commands attackers ran showed what attackers did once they thought they had logged in.

The most common command was echo -e "\x6F\x6B", which was run 29,624 times. All this command does is print “ok” using hexadecimal characters. This may have been a quick check to see if the system is responding to interactions correctly.

The next two most common commands were uname -s -v -n -r -m and uname -a. The first asks for details like the operating system/kernel name, kernel version and release, hostname, and hardware architecture. uname -a is basically a quicker way of asking for most of the same information. This helps an attacker learn what kind of machine they are interacting with and decide what they want to do next.

Figure 8. A recent simulated login followed immediately by a uname command, demonstrating post-login interaction capture.

Notable Finding: Automated Host Reconnaissance

The most notable command I captured was a long shell script that gathered a large amount of information about the system. It checked the OS, CPU architecture and model, uptime, number of processors, available shell tools, and GPU hardware. Something that stood out to me was that it specifically checked whether the system had VGA or NVIDIA devices.

Figure 9. The full command which searched for OS, CPU architecture and model, uptime, number of processors, available shell tools and GPU hardware. It also specifically checked to see if the device had a VGA or NVIDIA GPU.

One possible reason for this is cryptojacking, where an attacker could be looking for powerful GPUs to use for cryptocurrency mining. However, there could be other reasons for checking the hardware as well. The script may have simply been trying to figure out what kind of system it had reached and what type of malware or payload would work on it.

Key Takeaways

At the beginning of this project, one of my biggest questions was: are there really that many attackers out there? My answer after running the honeypot is a resounding yes.

Almost immediately, attackers and automated bots began interacting with it. Before long, I was seeing thousands of attempts to connect, log in, gather information, and interact with the system.

I already knew from my cybersecurity studies that automated attacks and scans are constantly happening across the internet, but this was the first time I got to see that activity firsthand. Seeing the volume of activity coming into my own honeypot made the scale of what is happening every second we’re online feel much more real.