Every second, websites around the globe are under attack—sometimes by hackers seeking vulnerabilities, and sometimes by well-intentioned security researchers. But how can you tell the difference?

This article is based on 10 months logged suspicious HTTP requests to https://www.cybernode.au, a React.js static website hosted in AWS Sydney region. In this article, we’ll dive into the traffic patterns observed on Cyber Node’s website, analyze the origins and nature of the requests, and explore how we can interpret these signals to better protect the organization. Legitimate site traffic has been filtered out to obtain those results.

Most Frequent Malicious Paths

Upon reviewing the logs, specific paths on the website were being targeted far more frequently than others. The top requested paths as well as what their presence or absence can mean for an attacker:

Requested path - Description (from a hacker's perspective)

• /.DS_Store -Typical macOS file that reveals directory structures, which can give attackers insights into the application’s file system
• /.env - Often contains sensitive environment variables like API keys, database credentials, etc., making it a prime target for attackers
• /.git/config - Can expose Git repository details, which might include sensitive information such as source code and credentials
• /.vscode/sftp.json - Contains FTP/SFTP connection details, which could include sensitive credentials for remote server access
• /_all_dbs - Typically related to CouchDB, and if exposed, it lists all databases, potentially giving attackers access to database contents
• /config.json - Can contain sensitive configuration details like credentials or API keys, which attackers can use to compromise the system
• /debug/default/view - Used for access to debugging interfaces that could expose sensitive information like error messages or internal application data
• /login.action - Commonly associated with vulnerable web frameworks (e.g., Apache Struts), making it a target for attackers exploiting known vulnerabilities
• /server - Typically contains server configurations or access sensitive directories that could expose server information
• /server-status - Contains Apache server statistics. If exposed, it provides detailed server info that can be exploited
• /telescope/requests - Related to Laravel’s debugging tool, which, if exposed, can reveal internal application data useful for attackers
• /v2/_catalog - Related to Docker repositories. Attackers may be probing for Docker images or misconfigured APIs
• /version - Probing for software or platform versions to target known vulnerabilities in outdated or misconfigured software
• /wp-login.php - Attempts to access the WordPress login page, indicating possible brute-force login attempts on WordPress sites

At first glance, the requests to /wp-login.php raise red flags. This is the default login page for WordPress websites, yet Cyber Node’s website does not run WordPress. The high frequency of these requests suggests automated bots targeting the website in the hope of finding an unsecured WordPress installation. These brute-force attempts are usually done with malicious intent, seeking to exploit weak or default credentials.

Similarly, requests for /.git/config and /.env files indicate probing for critical configuration data that could expose sensitive information about the website’s internal structure, such as Git repositories or environment variables containing API keys and credentials. These types of requests highlight a sophisticated level of probing, where attackers are not just looking for low-hanging fruit but also for opportunities to exploit misconfigurations.

Who’s Behind the Scans?

When examining the geographic distribution of malicious requests, the results offer a surprising insight. Rather than seeing a high volume of activity from countries typically associated with cyber-attacks, such as Russia or North Korea, the bulk of suspicious traffic comes from a wide range of countries, many of which are not known for hosting illegitimate cyber-security operations. The breakdown of malicious requests reveals:

Malicious Request per Country - 10 months period

• Germany, 62
• China, 56
• United States, 25
• Switzerland, 14
• Netherlands, 9
• Poland, 5
• Singapore, 4
• Russian Federation, 4
• Hong Kong, 3
• India, 3
• United Kingdom, 3
• Indonesia, 3
• Vietnam, 2
• Ukraine, 2
• Canada, 2
• France, 2
• Bulgaria, 2
• Iran, 2

The presence of USA, Germany and Switzerland at the top of the list is unexpected. Several cyber-security firms in these countries regularly scan websites as part of routine vulnerability assessments. However, this activity can sometimes blur the lines between proactive research and potential exploitation, as legitimate tools are also available to malicious actors. These requests reinforce the notion that malicious probes can come from countries typically regarded as cyber-security hubs.

China however, according to the news media, is more typically associated with nation-state actors and sophisticated cyber operations. Given the broad reach of Chinese scanning and hacking groups, the volume of requests is not surprising.

Interestingly, countries like the Netherlands and Singapore host numerous data centers and cloud services. These services are frequently exploited by attackers using compromised infrastructure to launch their attacks. This suggests that many of the requests might be originating from compromised servers or cloud platforms, rather than from individual malicious actors operating within those countries.

Meanwhile, Russia, a country frequently linked to high-profile cyber-attacks, generated only 4 requests, similar to countries like Singapore and Poland.

The geographic diversity of these requests demonstrates that malicious activity is not confined to a handful of well-known cyber-attack origins. Instead, attackers may be distributing their efforts across a global network of servers and platforms, making it increasingly difficult to pinpoint where the real threats are coming from.

This trend challenges traditional notions of cyber-security, where blocking traffic from specific high-risk regions like Russia or China was once considered effective. Now, attacks can just as easily originate from countries with robust cyber-security infrastructures, as malicious actors exploit legitimate tools and services for their purposes.

Repeat Offenders

A closer look at the IP addresses responsible for multiple malicious requests targeting Cyber Node’s website in the last 10 months reveals a clear pattern of repeat offenders. These IPs, often linked to well-known cloud providers and hosting services, suggest that attackers are leveraging compromised servers or cloud infrastructure to conduct their activities.

The top 4 IPs, all from Germany, are hosted on DigitalOcean Inc, a well-known cloud provider that caters to developers, businesses, and unfortunately, malicious actors. This activity strongly suggests the use of compromised virtual machines or accounts for conducting coordinated probing attempts. This high volume of requests indicates that DigitalOcean’s infrastructure is a prime target for attackers seeking to anonymize their scanning efforts by using widely available and reputable cloud services.

Another interesting offender,179.43.149.114, originates from Switzerland and is tied to Private Layer Inc, a hosting provider known for prioritizing user privacy and anonymity. This platform’s emphasis on privacy, while appealing to legitimate users, also makes it an attractive option for cyber-criminals seeking to hide their tracks. As above, these requests suggest that Private Layer’s infrastructure is either being abused by attackers or that a compromised server is being used to conduct these probes.

Other offenders, including DMZHOST in the Netherlands, Zenlayer Inc in the United States, and Scaleway in Poland, made between 4 and 6 requests. These smaller-scale probes may represent early-stage reconnaissance, with the intent to identify weaknesses before launching more sophisticated or larger-scale attacks.

This analysis highlights how malicious actors are increasingly using global cloud infrastructure and privacy-focused hosting providers to anonymise their operations and carry out attacks with relative impunity. The challenge for defenders lies in balancing security with the recognition that not all scanning activity from these providers is inherently malicious.

Don't wait for a breach to happen—take proactive steps today. Contact us at sales@cybernode.au or visit https://cybernode.auto learn how we can help you secure your business.

A Fine Line: Security Research vs. Malicious Intent

There is an important distinction between proactive security research and malicious probing. Security researchers often scan websites as part of a responsible disclosure process to help site owners identify and fix vulnerabilities before they can be exploited. On the other hand, malicious actors use similar techniques to exploit any weaknesses they find, often leading to compromised websites or stolen data.

In Cyber Node’s case, many of the requests for/wp-login.php or .git/config can clearly be classified as malicious, as they specifically target common vulnerabilities in Content Management Systems (CMS) or misconfigured repositories. These types of attacks are often launched by automated bots attempting to exploit weak or default settings.

Real-World Cases

To better understand how seemingly harmless probing can evolve into major cyber incidents, let's explore a few real-world examples of attacks that began with scanning or reconnaissance activity similar to what Cyber Node experienced.

Log4j Vulnerability | 2021

The Log4Shell vulnerability revealed how widely-used logging library, Log4j, could be exploited by attackers through remote code execution. As soon as the vulnerability was announced, security researchers and attackers alike began scanning the internet for systems using vulnerable versions of Log4j with frequent requests for/.git/config and /server-status. This led to a wave of automated exploits across multiple industries, as attackers sought to hijack vulnerable systems.

Source - "Mass scanning activity continues - The vast majority of traffic observed by Microsoft remains mass scanners by both attackers and security researchers." -Microsoft - # Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability

Equifax Breach | 2017

The Equifax breach exposed the personal information of over 147 million people. Attackers exploited a known Apache Struts vulnerability (CVE-2017-5638), which allowed them to execute remote code on Equifax’s servers. This breach occurred because Equifax had failed to patch the vulnerability, despite it being publicly disclosed and actively exploited by attackers. The vulnerability was announced in March 2017, and hackers began scanning the internet for /login.action, eventually gaining access to Equifax’s systems in May 2017.

Source -Command Execution Attacks on Apache Struts server CVE-2017–5638

Conclusion - Striking the Balance Between Awareness and Action

The line between security research and malicious activity is razor-thin. Without proactive monitoring and defense strategies, organizations risk exposing their digital assets to exploitation. Cyber Node’s traffic analysis is a warning: attacks can come from unexpected sources, and ignoring early signals could result in a major breach.

To stay protected:

• Be proactive: Apply patches promptly and ensure secure server configurations to block attacks that begin with simple scanning.
• Monitor scanning activity: Treat probing, like that seen with Log4j and Apache Struts, as a warning signal.
• Learn from past breaches: Major incidents like Equifax and SolarWinds began with reconnaissance, underscoring the need to understand this phase.
• Leverage threat intelligence: Keep up with intelligence reports to identify and respond to emerging attack patterns.
• Enhance defenses: Implement rate-limiting, block known malicious IPs, and use web application firewalls (WAF) to filter common exploit attempts.
• Audit server configurations: Ensure sensitive files like .git/config and .env are not publicly accessible.

How confident are you that your website is not being scanned right now?