Honeypot Recon: Global Database Threat Landscape

In today's digital era, the importance of securing databases cannot be overstated. As more and more global businesses and organizations rely on DBMS systems to store tons of sensitive information, the risk of targeted attacks and data breaches continues to increase. Therefore, the importance of monitoring and uncovering new actors along with their - often unique - attack techniques and methods is crucial.

In the following article, we'll be delving into the general patterns and trends related to database attacks, which have been observed across various regions around the globe. Our team relied on data pulled from honeypot sensors, which have been strategically distributed worldwide, to gain insights into these trends. This network of sensors has helped us identify certain disproportions in the frequency, intensity, and nature of attacks targeting different database types located worldwide.

One interesting discovery was that certain databases were subjected to credential brute-force attempts more frequently than others. These brute-force attacks, where botnets repeatedly try different combinations of usernames and passwords to gain unauthorized access, have shown a higher prevalence in the case of some specific databases.

Lastly, we will discuss the interesting correlations we have found amongst the attributes collected during this research. At times, these correlations have been highly insightful, providing us with a deeper understanding of the characteristics of the database attacks. These findings, along with their implications, will be detailed in the subsequent sections of this text.

We hope this exploration sheds light on the evolving landscape of cyber threats across the globe.

Global Honeypot Project

When it comes to databases, a honeypot can be a powerful tool for identifying and analyzing potential threats. To obtain a better perspective of attacks worldwide, Trustwave has implemented a network of honeypots located in multiple countries across the globe. By distributing honeypots in such a manner, we can gather a reliable set of information on the methods and techniques used by attackers and their botnets, allowing a comprehensive understanding of the current database threat landscape. We decided to focus on gaining a global view, therefore we used the Low Interaction Honeypot (LIH) software; in other words, we collected login attempts along with data around the login process.

In the beginning of December 2022, we placed sensors (honeypot servers) in key regions of the world with emphasis on Central Europe and the tense situation associated with it: Russia, Ukraine, Poland, UK, China, and the United States. Sensors (honeypot servers) spread in this manner allowed us to detect and analyze attacks that may be specific to a particular region or country, which can be useful for identifying and mitigating unique regional threats.

In this article, the data described comes from the period of four months, from the beginning of December 2022.

Figure 01 – Sensor locations

Databases

We selected nine popular database systems: MS SQL Server (MSSQL), MySQL, Redis, MongoDB, PostgreSQL, Oracle DB, IBM DB2 (Unix/Win), Cassandra, and Couchbase. The ‘database servers’ were listening on their default TCP ports.

Figure 02 – Login attempts

It quickly became clear that the activity of MSSQL has been much higher than other databases. The disproportion is so large (>93% - Figure 02) that comparing it to the other DBMS’es was sometimes difficult. For this reason, we have launched another research project to take a closer look at the super high activity of MSSQL attacks that will be released later this month.

Values hiding under MySQL should be understood as the sum of login attempts together with MariaDB, Percona for MySQL, and other DBMS flavors whose protocol is based on the MySQL standard.

Sensor’s Net

One of the goals was to determine a country-specific attack rather than a server-specific attack – the idea of doubling the sensors came up. We placed two sensors in each country with a country-range-IP address as far away as possible from the first one in order to eliminate overlap. In other words, the goal was to avoid the situation of two similar IP octets, e.g., x.x.x.99 and x.x.x.100 for the one country (which was a bit tricky to achieve). As a result of this effort, we could distinguish a random from a targeted attack and also understand more about the nature of these attacks.

Figure 03 – Login attempts per sensor

Attack intensity

The histogram below (Figure 04) shows the frequency and intensity of attacks against all sensors, which varies over time. The next chart (Figure 05) shows the number of unique IP addresses captured in the research period.

Figure 04 – Attacks histogram against all DB’s

The histogram is the sum of all login attempts (brute-force) on all listening database ports. The visible peaks, as we will learn later in the article, are MSSQL attacks. The other attacks so small as to be barely noticeable (Figure 07) compared to MSSQL values.

Figure 05 – Unique IP’s histogram

In the first period of the project's operation, the incoming data already brought a few surprises. One was the large attack disproportion between sensors. Looking below, the attackers were clearly attracted to the UK sensors.

Figure 06 – Attacks per country (sensors balance)

The approach of duplicated sensors is shown above (Figure 06). As can be seen, the numbers line up in a certain order. The intensity of attacks on a country was similar on each pair of sensors. This confirms that most attacks are carried out on a specific country on purpose (country IP range), the attacks are not randomized globally, and – in this case – attackers are not interested in breaking in just anywhere (i.e., for the purpose of extending their botnet).

Threats and Observations

After four months of observations, it turns out the variability in the intensity of attacks launched against individual databases varies drastically.

Figure 07 – All DB’s attack histogram

As already mentioned, attacks carried out against MSSQL make up more than 93% of all attack activity. This is shown in the chart below, where MSSQL was removed, and many other details become clear.

Figure 08 – DB attack histogram [MSSQL excluded]

Individual attacks are quite noticeable - characteristic peaks tell us about the intensity, frequency, and duration of attacks. December and January were a rather calm period (Figure 09). These facts may suggest that the attacks are carried out manually, with bots waiting for commands and targets from the C&C operator.

Figure 09 – Monthly attacks intensity

It should be noted that the sensors were all set and operating several weeks before the official start day, December 06, 2022. Therefore, the low level of attacks tracked in December shouldn’t be considered a 'start-up period' for the honeypot (Figure 09).

The second most attacked database after MySQL was Redis - which was a bit unexpected. Looking at the numbers of login attempts and comparing highest peaks of those databases: ~150.000 (for MySQL and Redis) to >3.000.000 (for MSSQL) is a massive disproportion.

Figure 10 - Attack histogram per country

Although the UK overall suffered the largest number of attacks, Ukraine went through its heaviest brute-force attack around February 19, and set an intensity record. This particular attack was conducted by just 5 IP addresses (Figure 13 & 14).

MSSQL

The attacks carried out against MSSQL instances were very intense. According to Shodan, there are over 450,000 MSSQL instances available on the Internet with over 133,000 instances located in China.

The most targeted countries are shown below (Figure 11). Doubled sensors confirm it - botnets aiming at IP ranges of exact countries or world region, but not the whole IP scope. Undoubtedly, the UK, along with China, are part of the, let's call it a global communications "hub" for many industries, and corporations - perhaps here we can look for some justification for such intense attacks. On the other hand, sensors in Ukraine and Russia have also had a very difficult time with similar scores.

Figure 11 – MSSQL attacks per country (sensors balance)

Figure 12 – MSSQL attacks per country

Looking at Figure 10, we see a clear peak of the attack carried out around February 19. The table below shows the IP addresses recorded within those days (+/- 2 day).

Figure 13 – IP addresses

We can easily distinguish five addresses with a similar (large) score: 62.210.122.59, 195.154.171.87, 62.210.99.221, 62.210.206.207, 62.210.207.39. All of these addresses are located in France and are barely marked as malicious in popular reputation services such as VirusTotal (i.e., 3/89 of the score) or otx.alienvault.com.

Figure 14 – 5 selected IP addresses activity against all DB’s

The operating regions for this IP group are limited and very selective. Undoubtedly, the interesting fact that distinguishes this group of addresses from the others is that we have only observed it a few times and never again! It seems that the group behind these addresses uses them selectively and sparingly. At the same time, other IP addresses were operating constantly, with random intensity, but they were always ‘nearby’.

Figure 15 - Brute-forced usernames

No surprise, the username ‘sa’ is the main tested account. Besides dictionary attacks carried out against passwords, there were also many attacks carried out against usernames. This is illustrated in the table above (Figure 15). Thus, we recorded more than 2,100 different usernames tested in MSSQL attacks.

MySQL

As Shodan reports, available MySQL instances have now reached the amount of >3.6M (a lot!).

One of this project’s goals was to verify botnet activity within MySQL attacks. We studied MySQL in detail two years ago, and described the findings on the SpiderLabs blog, so today we looked for general deviations and changes recorded compared to the previous study.. However, as the collected data illustrates, MySQL continues to be a very attractive target for bad guys.

In this case, the intensity of attacks on individual sensors differs significantly from MSSQL.

Figure 16 – MySQL attacks per country (sensors balance)

The single UK_01 sensor experienced the brunt of the attack, while the MySQL's UK_02 sensor was not so heavily engaged. For unknown reasons, sensor UK_01 caught the eye of the bad guys. The case was different for the other sensors. Attacks on them were carried out rather lazily, without any spectacular events.

Figure 17 - Brute-forced usernames

Different from MSSQL and the 'sa' account is the case with MySQL. In addition to the leading 'root' account, brute-force attacks also involved other options and were carried out using many popular usernames. The table above lists the users used in the attacks.

Figure 18 – MySQL attacks per country

Redis

No small surprise was the high attack activity recorded on the tcp/6379 port. Redis is a relatively young database (launched 2009), but it is becoming more and more popular - also among attackers. According to Shodan, currently presenting Redis instances are above 270k, while instances with open port 6379/tcp are above 600k. No wonder this database is becoming attractive to attackers.

Figure 19 – Redis attacks per country (sensors balance)

Figure 20 – Redis attacks per country

UK is again the most attractive region for attackers, followed by Russia. In other countries attacks on the Redis instance are less popular (but the threat exists!).

Other Databases

We also monitored login attempts on other databases. While we did not discuss them at length here, we did gain valuable information about them.

Despite a lower level of threat actor interest in other solutions, it’s worth keeping in mind that they are still possible targets so it’s very important to properly secure them against intruders.

Figure 21 – Other databases B/F attacks

Research Summary

In this research, our primary objectives were to monitor database threats globally, describe them, and identify potential areas for future research. Our approach involved deploying low interaction honeypots (LIH) across nine different types of databases, which, despite their limited capabilities, provided a wealth of valuable insights.

Not all databases were attacked with similar intensity. Some, like MSSQL or MySQL, had more unauthorized access attempts than Oracle or IBM DB2. There could be many reasons for this, such as the type of data they hold, if they are corporate or government standard, how common they are, or if attackers know about any weak spots they can exploit.

Our study shows that we need to take database security very seriously. This means using strong, unique passwords and unusual usernames, using strong and secure authentication, disabling default accounts and enabling MFA. Keep a close eye on who is trying to access the system and with which privileges, update software, conduct security audits frequently, and many more!

The research also shows that we need to keep studying this area to stay ahead of the threats. Protecting against cyber threats is an ongoing job, and we need to stay alert and keep working to improve database security. This is where the remarkable utility of database vulnerability scanners, such as Trustwave AppDetectivePro or DbProtect, come into play.

In the context of this article, we'd like to emphasize why these potent tools are not just a nice-to-have but rather a must-have for every place where data is stored. For instance, they ensure your database aligns with data protection regulations such as DISA-STIG, CIS, GDPR, HIPAA, or PCI-DSS, saving potential non-compliance penalties. They also serve as effective reporting and auditing tools, helping assess risk, plan security investments, and demonstrating due diligence. Vulnerability scanners can help prevent data breaches, protect against internal threats, and are a part of cybersecurity best practices.

The information we got from this study can guide future research, helping us understand the threats better and find ways to protect these important database systems.