Automated Exploit Scanning Detected and Blocked

Today I analyzed an interesting real-world security incident against an Internet-facing Linux server.

Within just a few minutes, a single source performed automated reconnaissance combined with multiple exploit attempts targeting well-known vulnerabilities.

Among the requests were probes for:

• Log4Shell (CVE-2021-44228)
• Spring4Shell (CVE-2022-22965)
• exposed .env files
• Git repositories
• WordPress configuration files
• AWS credentials
• Tomcat Manager
• Spring Boot Actuator
• GraphQL endpoints
• Atlassian Confluence
• F5 BIG-IP
• Cisco VPN
• and many other common attack vectors

What made this incident interesting wasn’t a single exploit attempt — it was the attacker’s methodology.

The requests formed a typical automated vulnerability scan designed to identify any exposed service that might be vulnerable, regardless of the underlying technology.

An important detail about HTTP 200 responses

One detail that often causes confusion is that several requests received an HTTP 200 response.

Receiving HTTP 200 does not mean that an exploit was successful.

It simply means that the web application processed the HTTP request and returned a normal HTTP response.

In this case, the security detection was based on the malicious request patterns themselves, not on evidence of a successful compromise.

Layered security pipeline

The security pipeline worked as intended:

• ✅ Reverse proxy logged the incoming requests.
• ✅ CrowdSec identified multiple exploit signatures.
• ✅ Security events were forwarded to the firewall.
• ✅ The malicious source was automatically banned.

The screenshots show CrowdSec detecting exploit activity including:

• crowdsecurity/http-probing
• crowdsecurity/spring4shell_cve-2022-22965
• crowdsecurity/apache_log4j2_cve-2021-44228

The source was automatically added to the active ban decisions.

What this demonstrates

This incident is a good example of why layered security is important for Internet-facing infrastructure.

A reverse proxy provides visibility into incoming HTTP traffic.

CrowdSec analyzes the traffic and identifies known malicious patterns.

The firewall provides an additional enforcement layer by blocking the detected source.

No single component has to do everything.

Instead, each layer contributes to detection, visibility, and automated response.

Internet-facing services are continuously scanned by automated bots. Preventing every scan is impossible, but building visibility, detection, and automated response makes a significant difference.

Security is not about never being attacked.

It’s about detecting attacks early, understanding what is happening, and responding automatically.

Technologies involved

• Linux
• Nginx Proxy Manager
• CrowdSec
• Firewall
• HTTP/HTTPS
• Reverse Proxy
• Automated Threat Detection
• Blue Team / Defensive Security

#CyberSecurity #Linux #CrowdSec #Nginx #BlueTeam #SOC #NetworkSecurity #DevSecOps #Infrastructure #ThreatDetection

Photos