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:
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:
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.
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.
Figure 4: Index-requests of various sources
We could identify various providers and tools that have checked our webserver for its availability:
- censys.io
- netsystemsresearch.com
- leakix.net
- zmap/zgrab (Scanner)
- colly (Scanner-Framework)
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”:
Figure 5: Vulnerability scan of leakix.net
The page itself explains that the service scans the entire Internet randomly for known vulnerabilities:
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
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