Honeypot Journals: Credential Attacks and Lessons from Recent Honeynet Incursions

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.

Findings

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 4^th 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.

Password

p4ssw0Rd

p@$$w0rd123

p@sSw0rD

pa$$w0rd!

pa55word12345

pass#word1

pass0rd

pass@word123456

passwd999

passwordpassword

 

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.

Password

qaz123wsx

qazWSX123!@#

qazpl,wsxokm

qwaszx

qwe!@#123

qwer!@#$1234

qwerty!@#456

-pl,0okm

,ki89ol.

.,mlkjoiu987

 

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.

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	194.165.16.27	RU	Russian Federation
#2	141.98.81.154	PA	Panama
#3	51.83.250.156	FR	France
#4	61.177.173.14	CN	China
#5	218.92.0.205	CN	China
#6	5.188.62.223	RU	Russian Federation
#7	5.188.62.221	RU	Russian Federation
#8	77.93.126.12	RU	Russian Federation
#9	5.188.62.220	RU	Russian Federation
#10	185.232.67.40	RO	Romania
#11	185.232.67.36	RO	Romania
#12	78.128.113.150	BG	Bulgaria
#13	185.232.67.44	RO	Romania
#14	195.3.147.47	LV	Latvia
#15	193.105.134.45	IM	Isle of Man
#16	45.227.255.205	PA	Panama
#17	45.227.255.163	PA	Panama
#18	185.232.67.42	RO	Romania
#19	5.188.62.240	RU	Russian Federation
#20	5.188.86.219	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
74.120.14.39	US	scanner-06.ch1.censys-scanner.com	Censys IP/port crawler
74.120.14.40	US	scanner-06.ch1.censys-scanner.com	Censys IP/port crawler
74.120.14.54	US	scanner-07.ch1.censys-scanner.com	Censys IP/port crawler
162.142.125.37	US	scanner-04.ch1.censys-scanner.com	Censys IP/port crawler
162.142.125.38	US	scanner-04.ch1.censys-scanner.com	Censys IP/port crawler
162.142.125.128	US	scanner-21.ch1.censys-scanner.com	Censys IP/port crawler
167.248.133.38	US	scanner-08.ch1.censys-scanner.com	Censys IP/port crawler
167.248.133.40	US	scanner-08.ch1.censys-scanner.com	Censys IP/port crawler
77.247.181.163	NL	lumumba.torservers[.]net	Mass port crawler
183.136.225.14	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.

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

217.64.127[.]220|0|1|0|0|0|0|1

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.

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.

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.

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.