Security dashboards tell us how many threats have been blocked. But the numbers become far more valuable when we understand the activity behind them. A closer look at 351,263 security events recorded by SiteWALL revealed a revealing story about automated attacks, older vulnerabilities and the challenges of protecting business applications.
The number that made us look twice
351,263 security threats blocked.
That is the kind of number that gets attention in a cybersecurity review.
It shows that security controls are actively identifying and stopping suspicious requests before they can reach protected applications.
Looking more closely at this particular set of events revealed important patterns.
When we analysed traffic recorded by SiteWALL Web Application Firewall, we found that all 351,263 events were classified under HTTP Splitting. What caught our attention was the type of attack.
HTTP Response Splitting is a vulnerability that became widely known more than twenty years ago. It allowed attackers to manipulate how vulnerable applications constructed HTTP responses, potentially changing the content delivered to users or interfering with web caches.
Over the years, web servers and application frameworks have introduced stronger protections against this technique. Modern, properly maintained applications are generally much better protected, although older systems and implementation weaknesses can still leave gaps.
So why were we still seeing hundreds of thousands of requests associated with a vulnerability the industry has understood for so long? We decided to examine the traffic more closely.
What we found behind the numbers
Of the 351,263 events, 346,690 were associated with IP addresses geolocated in India. That was 98.7 percent of the total.
Around 340,159 requests reported Wget as their user agent. Wget is a legitimate command line tool for retrieving web content, but its unusually frequent appearance in these requests was consistent with automated scanning.
One IP address alone accounted for 87,111 requests, nearly one in every four events.
The concentration was striking. The actual requests were even more revealing.
Many attempted to access familiar system files such as /etc/passwd and /windows/win.ini.
Others contained patterns consistent with database injection, including requests that appeared intended to trigger external network activity.
We also found HTTP requests containing patterns associated with email header injection. These are relevant to web applications that generate emails using submitted information.
Several requests contained carriage return characters associated with HTTP header injection.
Although the requests contained different suspicious patterns, they appeared under the same HTTP Splitting detection category.
Much of this activity was detected and blocked by SiteWALL's AI/ML engine, demonstrating how intelligent threat detection can recognise suspicious behaviour across different request patterns.
What the volume made clear was a broad pattern of automated probing that SiteWALL successfully detected and blocked across multiple attack techniques.
The value of the investigation was not just confirming the volume of threats blocked. It was understanding what attackers were attempting and how that activity was distributed across sources and attack patterns.
Why attackers keep trying old vulnerabilities
There is a simple reason attackers continue using techniques that have been known for decades. Trying them costs very little.
Automated scanning tools can send thousands of requests to websites without knowing much about the applications running behind them. They test newly discovered vulnerabilities alongside techniques that were popular twenty years ago.
When an attempt fails, they simply move on.
There is little reason for an attacker to stop testing an old weakness if it occasionally finds a vulnerable application.
For businesses, the concern is that not every application receives the same level of security attention.
Think about the applications running inside a typical enterprise.
The main customer portal may be relatively new, with regular security reviews and software updates. But there may also be an older partner portal, a reporting application developed years ago, or a service maintained by an external vendor.
Some are difficult to modify because even a small change could interrupt business operations. Others depend on software components that are no longer actively maintained. A few have been running reliably for so long that nobody thinks to question their security.
An application can work perfectly well for the business while still carrying vulnerabilities that were identified years ago. That is the opportunity automated scanners are looking for.
They are not necessarily trying to defeat the most secure application in your environment. They are looking for the one that has been overlooked.
For a CIO, this creates a practical challenge. How do you ensure that every application exposed to the internet receives appropriate protection when those applications differ so much in age, technology and ownership?
An old vulnerability does not become irrelevant simply because modern software has addressed it.
When 20 attacks matter more than 300,000
Large attack numbers tell us how much suspicious activity is reaching our applications. Understanding the nature of that activity helps us decide where attention is needed most.
Consider two situations.
An organisation receives 300,000 automated requests attempting known vulnerabilities against properly secured applications.
Another application receives just 20 carefully constructed requests targeting a recently disclosed weakness.
Which situation should concern the security team more?
It depends on the applications involved, the vulnerabilities being targeted and the potential business impact.
The 300,000 requests may dominate the dashboard because of their volume. The 20 requests may barely register.
Yet if those 20 requests target an exposed, unpatched application handling financial transactions or sensitive customer information, they could represent a far greater risk to the business.
This is why effective application security requires both protection and visibility.
Threat detection and blocking help protect applications from malicious traffic. Examining the requests provides additional context that allows security teams to prioritise investigations and strengthen their defences.
Security teams need to know which applications are being targeted, what attackers are attempting and whether those applications have exploitable weaknesses.
Technology teams need to understand which business applications are exposed and whether appropriate controls are in place.
Business leaders need to know whether critical services are adequately protected.
These are the insights that make cybersecurity reports useful for business decisions.
What matters beyond blocking attacks
Not every application can be fixed the moment a weakness is found. One may run on a platform the vendor no longer updates. Another cannot be touched during business hours without risking an outage. A third is stuck waiting on a supplier to ship a patch.
While that gap is open, a firewall sitting in front of the application holds the line. It stops the probing traffic before it reaches the code, which is exactly the cover an old or frozen system cannot give itself.
That is the half of the job people expect. The half they forget is reading what the firewall caught. The block count on its own told us almost nothing here. The shape of it, one tool, one country, a single address behind 87,111 requests, is what told us this was a machine sweeping the internet and not someone aiming at us.
That reading is what turns a wall of blocked events into something a team can act on. It shows which applications are drawing fire, whether the same sources keep coming back, and where the traffic is worth a second look.
So the useful questions have nothing to do with the size of the number. Which of our older applications are still reachable from the internet, and is anyone still looking after them? Are the same sources testing us again and again? Is anything unusual pointed at the systems we can least afford to lose?
A firewall cannot answer all of that alone, and it was never meant to stand in for secure code, patching and vulnerability work. What it does is buy time for the applications that cannot move quickly, and show you where to look while you still can.
What the numbers really told us
We started with one big number and an attack the industry thought it had left behind twenty years ago.
What the traffic actually showed was quieter and more useful. Almost all of it was automated scanning, a handful of old tricks bundled under a single label and fired off by scripts that cost nothing to run. SiteWALL blocked every one of the 351,263 events.
The scanners keep running because they are patient and cheap, and they only need to find the one application you stopped watching. The reporting tool nobody logs into. The partner portal no one has patched since the day it launched. That is what they are hunting for.
So the blocked count is worth having. It is proof the wall is doing its job. But on its own it is just a number. What made it matter was stopping to ask what sat behind it, and what that told us about where we are exposed.
The real measure of security is not just how many attacks you block. It is how effectively you protect the applications your business cannot afford to lose.
