Web Server Discovery or Fuzzing Activity

This detection identifies web server reconnaissance and fuzzing attempts. The rule is triggered when a single source IP address generates a high volume of HTTP GET requests that result in 404 (Not Found) or 403 (Forbidden) status codes within a short period. This behavior suggests an attacker is trying to discover hidden or unlinked resources on a web server, a common initial step before more targeted attacks. This is achieved by counting events and distinct URLs accessed from logs across Nginx, Apache, Apache Tomcat, IIS, and Traefik web servers. The rule triggers if more than 500 events and 250 distinct URLs are observed from a single IP address within the monitored timeframe.

Attack Chain

1. The attacker initiates network connections to a target web server (Nginx, Apache, etc.).
2. The attacker sends a series of HTTP GET requests to various URLs, often using a wordlist.
3. The web server processes each request and returns HTTP status codes.
4. The attacker analyzes the HTTP status codes to identify existing resources.
5. A large number of 404 (Not Found) or 403 (Forbidden) responses indicate a fuzzing attempt.
6. The attacker identifies potentially vulnerable or misconfigured resources.
7. The attacker may attempt to exploit discovered vulnerabilities.
8. Successful exploitation could lead to information disclosure or unauthorized access.

Impact

Successful web server discovery enables attackers to map out a web application's structure and identify potential vulnerabilities or misconfigurations. This reconnaissance can precede more severe attacks, such as unauthorized access to sensitive data, code execution, or denial-of-service attacks. While this rule has low severity, successful reconnaissance can lead to high impact outcomes.

Recommendation

• Deploy the Sigma rule High Volume of 404/403 GET Requests to your SIEM and tune the threshold (events > 500 and URLs > 250) for your environment.
• Investigate any alerts generated by the Sigma rule to identify the source IP address and the target web server, then check the associated logs.
• Review WAF/CDN logs for rate limiting and blocks related to the suspicious source IP, as recommended in the overview.
• Implement rate limiting on web servers to mitigate the impact of web server discovery and fuzzing attempts, as mentioned in the overview.
• Harden the web tier by disabling directory listing and default app endpoints, blocking patterns like /.git/, /.env, and /backup.zip at the WAF, and restricting origin access to CDN egress only, as mentioned in the overview.