Skip to content

Capabilities ApexAI Breach Proof

Capability · Web attack success detection

Did the attack work? Know, do not guess.

Every internet-facing application is attacked every day, and almost all of it fails. The danger is the one request that got through. ApexAI Breach Proof looks at what happened after each attack, separates the attempts from the successes and checks its answer against your own logs before it asks anyone to act.

Status: Preview Breach Proof runs in observe mode on real web and server logs: it records its findings and confirmations for review, and raises nothing on its own yet.

Why attempts drown out breaches

Web security tools are good at spotting attack payloads. That is also their problem. A scan, a bot or a careless tester produces the same signatures as a real intruder, so analysts face a wall of alerts that all look alike. Teams learn to tune them down, and a successful attack ends up hidden among thousands of failed ones.

Attackers know this. They spread attempts over hours or days, vary their requests and wait for the one that works. A rule that needs a burst of activity, or that treats any normal-looking response as harmless, misses exactly the slow, patient attack that matters most. And a response that looks normal is not proof of a breach either: claiming success too easily wastes as much time as missing it.

What Breach Proof gives you

  • A clear outcome per finding

    Every finding says whether the evidence shows an attempt, a probable success or a proven success, and never claims more than the evidence supports.

  • Confirmed against raw logs

    Before a success is reported, ApexAI checks what followed in your own logs, read-only, and shows the query it ran so your team can repeat it.

  • The patient attacker found

    Activity is followed per client over a long window, so attacks spread thin over time are joined into one story.

  • The real actor named

    When traffic passes through a proxy or WAF, the finding says whether the real client could be identified, instead of blaming the proxy.

  • Authorised scanners in their place

    Known authorised scanners explain attempts only. If a success comes from the same source, it is still raised.

  • Better rules for your SIEM

    Where your current rules missed something, Breach Proof drafts improvements for people to review. Nothing is written to your SIEM by itself.

Attack families it covers

Breach Proof looks for the outcome, not the payload, across the attacks that most often lead to a real compromise of a web application:

  • Web shells and command execution through the web server
  • Reading configuration files, secrets and other sensitive server files
  • SQL injection that returned data or changed behaviour
  • Path traversal and file access outside the application
  • Using a web server as a tunnel into the internal network
  • Abuse of business functions and administrative APIs reached from the internet
  • A web server process starting programs it should never start

How a finding reaches your team

  1. 01

    Observe

    Web access logs and server process activity from your SIEM are read, read-only.

  2. 02

    Separate

    Each attack is classed as an attempt, a probable success or a proven success.

  3. 03

    Confirm

    Probable and proven successes are checked against the raw logs, with the exact query kept on record.

  4. 04

    Join

    The finding is attached to the host, application and client entities, so it becomes part of one incident story.

  5. 05

    Decide

    Your team sees the evidence, the outcome and the proposed next step, and decides what to do.

Questions

How is a successful web attack different from an attempt?

An attempt is a malicious request. A success is evidence that the request achieved something: a command ran, a file was read, data came back or the server did something it should not. Breach Proof reports which of the two the evidence shows.

Do I need a WAF or a new agent?

No. Breach Proof works from the web and server logs your SIEM already collects. Better logs give better answers, for example when the real client address is kept behind a proxy.

Will it flood us with alerts from scanners?

No. The point is to raise the few attacks that worked, not the many that did not. Known authorised scanners explain attempts, and attempts alone are not escalated.

Does Breach Proof change our SIEM rules?

No. It can draft rule improvements where it found gaps, but they are proposals for your team. Nothing is written to your SIEM.

See ApexAI on your own alerts.

A walkthrough with your team, in observe mode first: ApexAI scores and proposes, nothing acts on its own.