Honeypot Journals: Credential Attacks and Lessons from Recent Honeynet Incursions

All posts

If you look at a digital attack map, you might think it is impossible for these cyber incursions to happen so rapidly. Thankfully, CUJO AI Labs have the infrastructure in place to check these claims. This is a write-up of the recent trends in credential stuffing attacks we detected in our honeypots.

We recently conducted a 3-week-long study, where we analyzed honeypot logs and tried to understand the recent trends in credential-stuffing and brute-force attacks. We had also studied new attack schemes happening in our honeynet. What we found is that there is substantial evidence for the ongoing traffic trends observed in the public threat attack maps.

Interested in deconstructing cyber threats? Read about a recent DNS hijacking attack in Brazil.

Password Attacks: Credential Stuffing and Brute-force

As we discussed in our previous article on the genetics of a modern IoT attack, an IoT attack usually starts with either exploiting a vulnerability in the target devices or brute-forcing device credentials.

Back in 2016, the success of the Mirai botnet was due to only 61 hard-coded username-password pairs. This is why investigating the current state of credential brute-force attacks is worthwhile, as it provides a window into the current threat landscape.

Weak Passwords

Typically, three credential weaknesses were exploited in such attacks.

Default and hard-coded credentials

IoT devices often come with default passwords. Usually, manufacturers enforce a password change upon first login. However, when users are not forced to change the default credentials, they frequently keep using them. In the worst cases, the credentials are hard-coded and it is not even possible to change them. Furthermore, some vendors configure custom accounts for remote accessibility. Attackers can use these default and hard-coded credentials to access vulnerable devices.

Easy to guess credentials

The biggest issue with passwords is that people cannot memorize long random sequences of symbols. This is why many use simple passwords that are easy to remember. Such passwords are easily brute-forceable by attackers.

Leaked credentials

Besides simple passwords, password reuse is another common issue. Even if a person creates a difficult password, they are under increased threat if they use it for more than one account or device. If such a password is compromised, the stolen credentials can be used by attackers to break into other accounts of the same person.

The Honeypot Experiment: Collecting Data

For our experiment, we used a few simple SSH honeypots to collect data.

The goal of using honeypots is to attract threat actors and observe their actions in the controlled, monitored environment that they believe to be a production system. From a researcher’s perspective, the aim is to let the attackers spend a long time inside the honeypot, to have them reveal attacker toolsets and techniques, or even simple Indicators of Compromise.

To truly work, the honeypot needs to run and emulate critical components of a production system for the attacker to be attractive enough to attack the system.


During our investigation, our honeypots saw 18,422 unique usernames and 63,955 passwords.

Attackers have an easy job with credential attacks, since ready-made password lists are all over the internet. They can use leaked lists of passwords seen in malware attacks (e.g., Mirai), credentials from data breaches, dictionaries of the most common username-password pairs, or publicly known default passwords of various devices (e.g., default router credentials).

Browsing through the credentials that were recorded by our honeypot, we found examples for all of the different cases mentioned above.

Credentials used in malware attacks

As an example, Mirai’s credential list is still used by attackers; however, it is unlikely that today they can initiate successful attacks using that list.

Device-specific credentials

Mostly publicly available default router credentials. Many of these are old and deprecated.

Username Password Router
admin microbusiness Pirelli Router
cusadmin highspeed Comcast Business Router
craft crftpw Avaya DEFINITY
root aerohive Aerohive Router
mtch mtch Alcatel PBX
disttech 4tas Nortel Meridian Link Router
admin zoomadsl ZOOM ADSL Modem
LUCENT01 UI-PSWD-01 Lucent Anymedia
admin DZY-W2914NSV2 WeVo Router
cytauser cytauser ZTE ZXHN H267N Cyta Router


Application-specific credentials

For popular applications, simple credentials are frequently used in brute-force attacks. Usually, these are very basic passwords, the combination of the software name, a general password, such as “changeme”, “password” or numeric values.

Username Password
postgres password
oracle oracle123
jenkins jenkins
hadoop hadoop
ts3 teamspeak
mysql changeme
root redhat
spark spark
django 123456
apache 1q2w3e4r5t6y


Common credentials used by average users

As we discussed above, people like to use easy-to-remember, simple passwords. Nordpass created a list of the most common passwords of 2020, which shows that people are still extensively using passwords such as “123456”, which was used by 2,543,285 users. These simple passwords are easily brute-forceable and were frequently used in attacks against our honeypot.

The word “password” is a popular choice; it was the 4th most popular in the 2020 list. In our honeypot logs, we have seen hundreds of variations of it. You can find a few examples below.



We have seen thousands of numeric passwords. Birth dates are a popular option users choose. Attackers are aware of this, which is why we see attempts of simply trying all the dates during a specific time.

As easy-to-remember passwords, keyboard combinations are also popular choices for people. As such, these are used by attackers as well. See a few examples from our honeypot logs below.



These are just a couple of examples of passwords that should never be used, but still a popular choice of people and exploited by attackers.

Most popular credentials

Below is a list of the top 25 most popular credentials that we observed in our honeypot logs.

Top 25 Most used credential combos Top 25 – Usernames Top 25 – Passwords
root root root root
admin admin admin 123456
admin password user admin
admin <BLANK> test password
root admin nproc 1234
user user postgres 123
nproc nproc ubuntu 0
root 1234 oracle user
root 123456 blank nproc
admin ubnt Administrator 12345
1234 1234 git test
Administrator admin operator 1
operator operator ftpuser ubnt
admin admin1 1234 operator
root freedom guest admin1
test test mysql 12345678
0 0 pi 123456789
pi raspberry nagios blank
blank blank deploy 0
2Wire <BLANK> 0 freedom
root 123 support qwerty
user 1234 testuser test123
guest guest ftp 123123
user 1 www changeme
pi raspberryraspberry993311 ts3 1qaz2wsx


Poor IoT security practices

When it comes to attacking IoT devices, weak credentials are only half of the problem. Remote access to these devices enables adversaries to execute successful attacks. It was the key to Mirai’s success when internet-facing devices were “protected” with just the default credentials.

Interested in IoT security research? Read our latest article on IoT hacking in a restricted environment.

We investigated the most popular devices among our users, focusing on IP cameras, routers, and NAS devices. Based on their public documentation, we found that the user usually chooses credentials during set up or when the default password change is enforced upon the first login. For routers, remote access is restricted and only allowed using a password chosen by the user. However, the possibility of setting a weak password is still an issue.

Cheap IoT devices = Lack of security in mind?

With regard to less popular IoT devices, the picture is getting worse. Cheap IoT devices are plagued with poorly implemented security features, logic flaws, and bad passwords.

In one recent example, a nursery system, called NurseryCam, used a single, known admin credential (detailed on the vendor’s support page) for all its deployed devices by default (nurserycam888, admin888).

By simply knowing the external IP address of a NurseryCam device, an attacker could log on to the DVR device with the default admin credentials, gaining access to the live camera feed, monitoring children or elderly people.

Origins of Brute-force Based Attacks

Where did all these brute-force attacks come from? Getting a clear picture of the true origin can be tricky, as most of the brute-force attacks are automated and might be proxied over several endpoints to avoid revealing the actual location of the attacker before it reaches the destination.

We also try to steer clear of any attribution based on single IP addresses. That would also require more knowledge on attacker techniques, tactics, and toolsets, not just atomic indicators.

Top offending IP locations

In our observation, most attacks aimed at our honeynet originated from a Russian IP address. The second most significant chunk of the pie consists of attacks coming from Chinese IP addresses. US, Panamanian and Romanian IP addresses have also made it into the Top 5, respectively.

Top 5 countries by brute force credential stuffing attacks on our honeypots
Distribution of honeypot attacks by Top 5 countries

When looking at specific IP addresses, it is clear some of these have been set up for automated crawling months before and have continued to scan IP subnets for vulnerabilities and open ports.

The Top 20 attacker IP addresses observed in the study:

Top 20 offending IPs
#1 RU Russian Federation
#2 PA Panama
#3 FR France
#4 CN China
#5 CN China
#6 RU Russian Federation
#7 RU Russian Federation
#8 RU Russian Federation
#9 RU Russian Federation
#10 RO Romania
#11 RO Romania
#12 BG Bulgaria
#13 RO Romania
#14 LV Latvia
#15 IM Isle of Man
#16 PA Panama
#17 PA Panama
#18 RO Romania
#19 RU Russian Federation
#20 RU Russian Federation


We have also cross-referenced source IP addresses attacking our honeynet against the offender IP addresses observed in our customer environments. Most of the findings are simple port crawlers by Censys, a company that scans the internet regularly.

The two outliers are a Tor server in the Netherlands, which was seen scanning and port crawling both our honeynet and customer networks: the other interesting hit is a Chinese IP address that has been observed to deal out automated brute-force attacks and historically has been port scanning, starting from the late April of 2021.

IP CC Hostname Description US scanner-06.ch1.censys-scanner.com Censys IP/port crawler US scanner-06.ch1.censys-scanner.com Censys IP/port crawler US scanner-07.ch1.censys-scanner.com Censys IP/port crawler US scanner-04.ch1.censys-scanner.com Censys IP/port crawler US scanner-04.ch1.censys-scanner.com Censys IP/port crawler US scanner-21.ch1.censys-scanner.com Censys IP/port crawler US scanner-08.ch1.censys-scanner.com Censys IP/port crawler US scanner-08.ch1.censys-scanner.com Censys IP/port crawler NL lumumba.torservers[.]net Mass port crawler CH China Telecom – CT-HangZhou-IDC SSH brute force attacks


Payloads with a Drop of Honey

In this section, we look at malicious binaries and payloads that are dropped or downloaded onto an infected honeypot. We give you a couple of examples of what attackers are trying to deploy recently.

Army of slaved honeypots

One exciting facet of honeypots is how attackers deliberately use them as stepping-stones for infiltrating other systems once actors establish persistence on the device. In many cases, we observed the invader getting access into the honeypot. Then, instead of infecting it and setting up persistence, the attacker decided to pivot off our honeypot instance to other malicious C2 servers.

The attacker’s goal was to use the honeypot instance as a bot, a part of their army. Safety measures of the honeypot thwarted these attempts, but it is still worth investigating these to understand the attacker’s motive.

We have seen the following traffic from one of our honeypot instances. The attacker tried to send a check-in POST request towards a C2 server on TCP port 5555.

C2 check-in traffic

The server response would contain a single line of IP address and seven switches relating to server functions:


The attacker tried to get our honeypot instance to connect to this panel and use it as part of the botnet.

Coinminers everywhere

In another scenario, attackers deployed a tar.gz archive file onto the honeypot instance via brute-forcing the SSH credentials. This package consisted of malicious binaries and init scripts. The main binaries (cron, anacron) are named after system binaries to try and stay under the radar. Both malicious binaries are Monero mining payloads.

monero mining payload
Dota malware originating from many IP addresses

The remaining scripts were used for creating persistence, backdoor services to the infected system or had to do with killing processes that are from competitor miners.

In another scenario, an attacker took a different approach. Once the perpetrator had logged in to the honeypot, we saw a curl command being issued to download a xmr.sh script. This script also an initialization script for the MoneroOcean miner.

moneroocean miner script pull
Xmr.sh coinminer script being pulled down
MoneroOcean initialization script
MoneroOcean v2.11 initialization script

Specific Mikrotik attacks

Another malicious activity we investigated in our honeypot system was a Mikrotik-focused attack. The attack was specifically aimed at Mikrotik devices. It installed a simple scheduled job on the infected device under the name “U6”, which would poll the C2 server on the TCP port 80 for further commands every 10 minutes.

Mikrotik malicious service persistence
U6 Mikrotik malicious service persistence

The C2 server could send commands that can change the firewall rules, DNS server settings, and other network settings on the infected device.

Although the detailed attack failed in our honeypot instance, it is an excellent example of how vulnerabilities are exploited. The initial attack vector for these types of attacks was a Winbox server vulnerability in RouterOS, which resulted in reading the system user database file for the attacker. This issue was assigned the vulnerability of CVE-2018-14847.


Conclusion: Credential Attacks Are Here to Stay

With this report, we wanted to emphasize the importance of IoT security, which must be kept in mind when designing IoT systems, as well as good password management and proper software development lifecycles to produce less critical vulnerabilities.

The few highlighted attack scenarios shed some light on current attack schemes happening in honeypot instances. Some clear takeaways are:

  • Automated scanners and brute-force attackers will stay with us for the upcoming years. We need to accept that if an internet-connected device is left with default credentials, it will get breached sooner or later. Default passwords are still an issue. With the myriad of leaked credential lists (Github, Pastebin), it becomes a simple routine to exploit such poorly secured devices
  • Good password hygiene goes a long way and counters automated credential attacks
  • Attackers are always on the move to find the weakest link in the chain of security measures and get access through the poorly implemented IoT security gateways


Recommendations for Protecting IoT Devices Against Brute-force Credential Stuffing Attacks

Our observations draw an alarming picture. Even though credential attacks are among the oldest techniques in the attackers’ arsenal, people have a hard time effectively protecting themselves. However, following a couple of simple rules would make it easier to avoid falling victim to such attacks.

Our recommendations are the following:

  • Use strong, unique passwords for all your accounts
  • Enable multi-factor authentication, if possible
  • Use a password manager
  • Check if your credentials have been part of a data breach – https://haveibeenpwned.com/
  • Secure your IoT devices properly
    • Disallow remote access (port forwards), if it is not necessary
    • Disable UPnP on the router, if possible
    • Change default passwords
    • Set complex, unique passwords
    • Patch the IoT devices


The write-up was created by Albert Zsigovits and Dorka Palotay.


Want to learn more about end-users and their thoughts about security? Access our detailed report on their cybersecurity perceptions.

Other posts by Albert Zsigovits

Cybersecurity IoT ISP Security
Cybersecurity IoT