Detecting successful web attacks, not just attempts

The attempt flood

A web application firewall or intrusion detection system is built to recognise attack patterns in requests: an injection payload in a parameter, a path that climbs out of the web root, a file upload with a script extension. It is very good at that job. The trouble is that recognising a pattern in a request tells you about the sender’s intent, not about the outcome on the server.

Internet-facing services receive a constant background of automated scanning. Vulnerability scanners, botnets, researchers and authorised testers all send requests that look like attacks. Each one can raise an alert. A SOC that treats every one of those alerts as a potential incident quickly learns to ignore the category, and that habit is exactly what a real intruder benefits from.

Many teams respond by raising the bar: alert only on high request rates, only on certain signatures, only above a severity level. That reduces volume, but it also tunes the detection towards noisy, fast attackers. A patient attacker who spreads a handful of careful requests over hours, or who succeeds on the first try, passes under a rate-based rule without ever crossing it.

Change the question: did it work?

The useful shift is to stop asking "was this an attack?" and start asking "is there evidence that this attack achieved something?". An attempt is cheap for the attacker and usually harmless. A success, even a single one, is where the real incident starts: a web shell that answers commands, a configuration file with credentials that was actually returned, a database query that leaked rows.

Answering that question needs different data from the one a WAF alert carries. It needs what the server did in response, what happened next from the same source, and what happened on the host behind the application. Those facts usually sit in other places: web server access logs, application logs, endpoint telemetry and network records. Bringing them together around one request, one client and one server is most of the work.

A plain HTTP 200 is not proof of success. Many applications answer every request with 200 and an error page. Equally, a blocked request is not always the end of the story, because the same attacker may have reached the origin another way. Success is a judgement built from several facts, and it should never be claimed beyond what the evidence shows.

Where evidence of success tends to live

Without going into specific rules, these are the families of evidence that defenders and incident responders rely on:

• The response: whether the answer for a requested path looks like real content rather than the application’s usual error, compared with how that path normally responds.
• The follow-up: whether the same client, or a new one, comes back to use what an earlier request appears to have created or revealed.
• The host: whether the web server process starts doing things web servers do not normally do, such as launching command interpreters or discovery tools.
• The network: whether the web tier starts reaching places it never reached before, inside or outside the organisation.
• The identity layer: whether credentials that could have been exposed are suddenly used from unusual places.
• The timeline: whether a slow series of attempts over hours or days ends in a change of behaviour, which is easy to miss when each window is looked at alone.

Practical pitfalls

Several common gaps make success hard to see even when the data exists. Detection rules often read the security device’s log rather than the web server’s own access log, so the response size and status that would reveal success are never examined. Query strings are sometimes stripped from logged paths, so the payload is invisible to the rule. Matching that is sensitive to letter case or to one encoding misses variants that the server happily accepts.

Behind a reverse proxy or content delivery network, the address seen by the application may be the proxy, not the client. Blaming the proxy for an attack, or blocking it, causes an outage while the real source walks away. Attribution must only use forwarded client addresses when the proxy is trusted, and say plainly when the actor cannot be resolved.

Authorised scanning deserves careful handling. Known scanners explain attempts, and it is reasonable to suppress the noise they create. They never explain a success. If a request from a scanning address produced a real result, that is still an exposure the organisation needs to fix.

Business-logic abuse is its own category. Mass account unlocks, repeated one-time-password requests or administrative APIs called from the internet can all return success codes while the business damage is invisible to a signature. These need context about what normal use looks like, and they should be reported as probable abuse rather than claimed as proven.

Verify against the raw record

Whatever decides that an attack succeeded should be able to show its work. A good finding carries the exact queries an analyst can rerun against the raw logs, bounded in time, so that a person can confirm the conclusion in minutes rather than trust it blindly. This also protects against the quiet failure mode where a query errors or times out and the absence of results is mistaken for the absence of an attack.

Finally, successful attacks found after the fact are valuable lessons. Each confirmed case shows which evidence appeared first and how early it could have been seen. Feeding those lessons back into detection, as general improvements rather than rules written to catch one known case, is how a team moves its first alert closer to the moment of compromise.

How ApexAI approaches it

ApexAI Breach Proof, currently in preview, is designed around the outcome question. It brings web, host and network evidence together for the same client and server, grades each finding as an attempt, probable or proven, and attaches read-only queries so your analysts can check the conclusion against your own logs. Known authorised scanners are recognised for attempts only. Findings flow into the ApexAI Autonomous SOC, where they join the story of the affected entity instead of becoming one more isolated alert.

Questions