Common usernames submitted to honeypots

Published: 2023-09-05
Last Updated: 2023-09-05 01:43:10 UTC
by Jesse La Grew (Version: 1)
2 comment(s)

Based on reader feedback, I decided to take a look at usernames submitted to honeypots. The usernames that are seen on a daily basis look very familiar. They tend to come from default user accounts, such as "administrator" on Windows systems or "root" on Linux systems. The knowledge of a default user account can help in brute force attacks. If the username is already known, only the password needs to be guessed. This shouldn't be too much of a problem to users as long as strong passwords are chosen or other authentication methods such as public key authentication is used. Setting up public key authentication is also referenced in our DShield setup instructions for a Raspberry Pi [2]. 

I exported the username data from my honeypot, which is a little over 16 months of data, using JQ. 

# output data from all local cowrie logs
# cat /logs/cowrie.json.* 
# select data with the username key present
# jq 'select(.username)' 
# output raw username vales (without quotes) and store in a text file
# jq -r .username > 2023-09-04_all_usernames_raw.txt

cat /logs/cowrie.json.* | jq 'select(.username)' | jq -r .username > 2023-09-04_all_usernames_raw.txt


Total number of usernames submitted: 3,668,336
Number of unique passwords submitted: 105,022 (2.86% of passwords submitted were unique)

The most common username, "root", accounted for almost 50% of the total username submissions. This is not surprising since SSH is a common attack protocol that the honeypots collect this data from and is commonly used in Linux systems. This may change over time as newer Windows operating systems which include SSH options, become more common [3].

Username Count Percentage
root 1,778,938 48.49%
admin 137,971 3.76%
user 58,942 1.61%
test 48,086 1.31%
ubuntu 44,230 1.21%
345gs5662d34 36,473 0.99%
nproc 33,269 0.91%
postgres 17,700 0.48%
oracle 17,384 0.47%
ftpuser 13,404 0.37%
TOTAL 2,186,397 59.60%

Figure 1: Top 10 usernames submitted to my honeypot and overall counts


Almost 60% of all usernames come from the top 10 list. Let's take a look at some of the most frequently used passwords for some of these usernames. This data can also be extracted with JQ.

# output all cowrie data in /logs directory
# cat /logs/cowrie.json.*
# select all data with the username of "root"
# jq 'select(.username=="root")'
# output raw password data (no quotes)
# jq -r .password
# sort data alphabetically
# sort
# give unique password values with frequency counts
# uniq -c
# sort data by frequency count, reverse sorted (descending, most frequent hits on top)
# and save results to text file
# sort -rn > passwords_submitted_with_root_user_count.txt

cat /logs/cowrie.json.* | jq 'select(.username=="root")' | jq -r .password | sort | uniq -c | sort -rn > passwords_submitted_with_root_user_count.txt

Figure 2: Honeypot passwords associated with most common usernames


In the honeypot data, there are some deviations with the most common passwords used. The most commonly submitted password with the "root" user account was noted in my previous diary [4]. This also highlights another unusual finding with a username of the same value ("345gs5662d34"). This username only has one password associated with it, unlike the other top findings. If you know something about this particular value, please add a comment.

It's very common to see the login for a new device or service to have a default password that is the same as the built-in default user account. Attacking these default values can be very successful if users do not change the default password. Also, if a device is reset during troubleshooting, these default credentials may not be addressed after the reset. 

Figure 3: 20 Most frequently used usernames for one honeypot over the last 16 months


The most commonly submitted usernames and passwords with the same values can also be easily retrieved with JQ. 

# read json logs in /logs directory
# cat /logs/cowrie.json.*
# select values with the username key present
# jq 'select(.username)'
# select data where the values in the username and password keys are equal
# jq 'select(.username==.password)'
# select and output username and password values in CSV format
# jq -r '[.username, .password] | @csv'
# sort data alphabetically
# sort 
# display unique values with the number of instances of the value
# uniq -c
# sort the data by number of instances, reverse sorted (descending order)
# sort -nr
# display the first 30 items
# head -n 30

cat /logs/cowrie.json.* | jq 'select(.username)' | jq 'select(.username==.password)' | \
jq -r '[.username, .password] | @csv' | sort | uniq -c | sort -nr | head -n 30

Figure 4: 30 most commonly seen matching username and psasword values from honeypot


Make sure to use unique passwords and when possible, avoid using the default account with your device or service [5]. If possible, disable that account and when it's not possible, set a very strong password with limited rights. 


Jesse La Grew

2 comment(s)


Could 345gs5662d34 be a situation where it is actually "PASSWORD" in a different language keyboard? I remember reading this a few years ago on news[.]ycombinator, regarding the character string "ji32k7au4a83" showing up as passwords.

swang on March 4, 2019

This is using the zhuyin keyboard which most likely means Taiwanese users since Taiwan is probably the sole user of the zhuyin keyboard.
Typing that out on a zhuyin keyboard gets you: ㄨㄛˇㄉㄜ˙ㄇㄧˋㄇㄚˇ

In Pinyin that is wo3 de mi4ma3

Or in English "my password"
Sorry for the late reply, this is fantastic! I'm sadly not running a honeypot though from server logs it does line up perfectly. That 345gs5662d34 was one that stuck out to me too. I was watching the recordings from SEC-T and the presentation covering hashcat by Will Hunt ( highlights an example just like Rusty suggests above.

By that logic, this should be something like "root:root".

Since there are a ton of these, it is highly unlikely that there is a single party doing the bruteforcing. It seems reasonable therefore that there exists a list/dump or tool with some builtin standard user:pass combinations. I'd love to figure out the origin of this strange string

Anyway, thank you for an excellent pair of write-ups! Keep the good stuff coming :)

Diary Archives