Skip to content

Automated cyber attacks: no system remains untouched

10. November 2021

Independent of the size of a company or enterprise, everyone has to expect becoming a target of cyber attacks. Many attacks are not aimed at a specific target, but happen randomly and automated. Upon deploying a new server for the provisioning of our own vulnerability database, we noticed that already in the first 20 hours of online time, almost 800 requests could be logged on the webserver. In this article we want to dissect which origin these requests have and illustrate that attackers target far more than well-known systems and companies these days. In addition, we give practical advice, how to protect your own system against these attacks.

Legitimate requests to the vulnerability database (37%)

In a first step we want to filter all requests from our log file that constitue valid queries to our vulnerability database (the majority of which were executed in test cases). We do this by filtering all known source IP addresses, as well as regular requests to known API endpoints. The vulnerability database provides the following API endpoints for the retrieval of vulnerability data:

  • /api/status
  • /api/import
  • /api/query_cve
  • /api/query_cpe
  • /api/index_management

After a first evaluation, we observed that 269 of 724 requests were legitimate requests to the vulnerability database:

Cyber attacks Figure 1: Sample of legitimate requests to the webserver

But which origin do the remaining 455 requests have?

Directory enumeration of administrative database backends (14%)

A single IP address was particularly persistent: With 101 requests an attacker attempted to enumerate various backends for database administration:logs 2 cut

Figure 2: Directory scanning to find database backends

Vulnerability scans from unknown sources (14%)

Furthermore we could identify 102 requests, where our attempts to associate the source IPs with domains or specific organisations (e.g., using nslookup, user-agent) were unsuccessful. The 102 requests originate from 5 different IP addresses or subnets. This means around 20 requests per scan were executed.

logs 3 cut

Figure 3: Various vulnerability scans with unknown origin

Enumerated components were:

  • boaform Admin Interface (8 requests)
  • /api/jsonws/invoke: Liferay CMS Remote Code Execution and other exploits

Requests to / (11,5%)

Overall, we could identify 83 requests that requested the index file of the webserver. This allows to identify, whether a webserver is online and to observe which service is initially returned.

logs 4

Figure 4: Index-requests of various sources

We could identify various providers and tools that have checked our webserver for its availability:

Vulnerability scans from leakix.net (9%)

During our evaluation of the log file we could identify further 65 requests that originate from two IP addresses, using a user agent of “leakix.net”:

logs 5

Figure 5: Vulnerability scan of leakix.net

The page itself explains that the service scans the entire Internet randomly for known vulnerabilities:

logs 6

Figure 6: leakix.net – About

HAFNIUM Exchange Exploits (2,8%)

Furthermore we could identify 20 requests that attempted to detect or exploit parts of the HAFNIUM Exchange vulnerabilities. (Common IOCs can be found under https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf):

  • autodiscover.xml: Attempt to obtain the administrator account ID of the Exchange server
  • \owa\auth\: Folder that shells are uploaded into post-compromise to establish a backdoor to the system

logs 7

Figure 7: Attempted exploitation of HAFNIUM/Proxylogon Exchange vulnerabilities

NGINX .env Sensitive Information Disclosure of Server Variables (1,5%)

11 requests have attempted to rea