5.5 Confirmed WAF alert (ADR + WAF)
What this use case does: Correlates a WAF alert with a Contrast ADR confirmed exploit on the same request — turning a low-confidence WAF detection into a high-confidence, actionable finding.
The scenario
WAFs operate primarily by pattern matching at the network edge. They see HTTP requests and try to decide whether the request looks malicious. The problem: pattern matching produces a high volume of alerts with a significant false positive rate. SOC teams learn to deprioritize or ignore WAF alerts because investigating each one takes time and most turn out to be noise.
This is especially true when WAFs run in detect/alert mode (also called “log only” or “monitoring mode”) — the WAF flags suspicious requests but doesn’t block them, because the team hasn’t tuned the rules enough to trust them for blocking. The alerts pile up. Analysts triage the urgent ones and let the rest age out.
ADR changes this equation. When a WAF flags a request and ADR independently confirms that the same request exploited a vulnerability at the code level, that’s two independent signals agreeing. The WAF saw a suspicious pattern. ADR confirmed it reached a dangerous function and executed. That WAF alert is now a confirmed exploit — act on it.
The detection gap
WAF alone | WAF + ADR correlated |
“SQLi pattern detected on | WAF flagged the request AND ADR confirmed: |
High alert volume, low confidence. Analysts deprioritize WAF alerts because most are noise. | Only the WAF alerts corroborated by ADR surface as SIEM detections. The noise stays in the WAF logs; the confirmed exploits reach the analyst. |
Tuning WAF rules is a constant battle — too aggressive means blocking legitimate traffic, too loose means missing attacks. | ADR provides ground truth for WAF tuning: you can see exactly which WAF rules correctly identified real exploitation and which fired on benign traffic. |
How the correlation works
This rule fires when both of these happen within a 5-minute window for the same source IP and target URL:
Your WAF flags a request (any WAF detection — blocked, allowed, or logged)
Contrast ADR confirms that the same request resulted in a confirmed exploit at the application code level
Because the WAF and ADR see the same HTTP request nearly simultaneously, the 5-minute window is tight and precise.
What this means in practice:
WAF is in… | What happens | What the correlation tells you |
Detect/alert mode | WAF logs the suspicious request but allows it through. ADR sees the request and confirms exploitation. | The WAF alert was correct. This is a confirmed exploit. Act on it. |
Block mode | WAF blocks the request. Payload never reaches the app. ADR sees nothing. | No correlation fires. The WAF handled it. Nothing for the SOC to do. |
Block mode, but the attacker bypasses | WAF blocks some requests, but the attacker re-encodes the payload. WAF may alert on the original attempts. ADR sees the bypassed request and confirms exploitation. | WAF bypass detected. The attacker found a way around the WAF. Update WAF rules and enable ADR Block Mode as defence-in-depth. |
The rule is source-agnostic — it works with any WAF that sends logs to your SIEM: ModSecurity, AWS WAF, Cloudflare, Imperva, F5 BIG-IP ASM, Akamai, Azure WAF, Barracuda, Fortinet, Radware, Signal Sciences, Fastly.
Example alert
CRITICAL — Exploited Attack Corroborated by WAF (Risk Score: 95) --- ADR Detection --- Attack: sql-injection Application: cargo-cats-dataservice (Java) Endpoint: GET /payments Source IP: 10.1.7.201 Result: EXPLOITED --- WAF Detection --- Product: [WAF product name] Rule: [WAF rule that fired] Action: ALLOW Description: [WAF alert description] --- Correlation --- Join: Source IP + Target URL match within 5-minute window
Response playbook
This is a confirmed exploit — the WAF alert and ADR agree. Treat as high priority
Enable ADR Block Mode for the affected rule and application if not already active
Check the WAF action field: was it ALLOW or BLOCK?
If ALLOW (detect mode): consider moving this WAF rule to block mode — ADR has validated it catches real attacks
If BLOCK and ADR still saw an exploit, the attacker bypassed the WAF. Update WAF rules using the exact payload ADR captured.
Review WAF logs for the same source IP — how many requests did the attacker send? What other endpoints were probed?
Search ADR for the same source IP across other applications
Escalate to AppSec with the specific vulnerability for remediation
Use this data to tune your WAF: ADR-confirmed exploits tell you which WAF rules are working and which have gaps
Key takeaway
WAF alerts are low-confidence pattern matches. ADR provides high-confidence code-level confirmation. The correlation surfaces the WAF alerts that represent real exploitation — so your SOC acts on confirmed threats instead of drowning in noise. As a secondary benefit, when the correlation fires against a WAF in block mode, it reveals bypass techniques that would otherwise go undetected.