5.1 Exploited attack event in production
What this use case does: Alerts when Contrast ADR confirms that an attack was successfully exploited in a production application — not just attempted, not just probed, but actually executed in a dangerous function.
The scenario
An attacker sends a crafted request to your application. A WAF might flag the pattern. A scanner might log the attempt. But neither can tell you whether the payload actually reached a vulnerable function and executed. Contrast ADR can — it instruments the application runtime and observes code execution directly.
This is the foundational use case. It requires no correlation with other tools. A single ADR attack event in your SIEM tells you: this specific attack, against this specific application, reached this specific function, and the outcome was exploitation.
The detection gap
Without ADR | With ADR |
WAF says “blocked a suspicious request” — was it real? | ADR confirms: the payload reached HikariProxyStatement.execute() and modified the SQL query. Verified exploit. |
Scanner says “this app has a SQL injection vulnerability” — is it being exploited? | ADR confirms: this vulnerability was exploited 12 times in the last hour from 3 source IPs. |
SIEM has no application-layer visibility — you’re blind between the load balancer and the database | ADR provides runtime telemetry: attack type, target function, payload, outcome, application name, environment |
The ADR attack event data model
Every Contrast ADR attack event contains these fields. This is what arrives in your SIEM:
Field | What it tells you | Example |
Attack Rule | The vulnerability class exploited | sql-injection, cmd-injection, path-traversal, xxe, jndi-injection |
Result | Did it work? | EXPLOITED (confirmed), BLOCKED (ADR prevented execution), PROBED (attempted, didn’t reach a sink), SUSPICIOUS (anomalous but unconfirmed) |
Severity | How bad | CRITICAL, HIGH, MEDIUM |
Application | Which app was targeted | cargo-cats-dataservice |
Hostname | Which instance/pod | cargo-cats-dataservice-7bd8f7c4d8-lsw8p |
Target URL | Which endpoint | /payments |
Source IP | Where the attack came from | 10.1.1.128 |
MITRE Tactics | Pre-mapped ATT&CK tactics | TA0010 Exfiltration , TA0009 Collection , TA0040 Impact |
Reconstructed Query | The actual query/command after injection | INSERT INTO credit_card ... VALUES ('9999999999999999 ' AND SLEEP(5) ...') |
Environment | Where it’s running | PRODUCTION, DEVELOPMENT |
Console Link | Direct link to the Contrast console for full details | https://app.contrastsecurity.com/... |
1. Result = EXPLOITED — ignore probes and suspicious activity, only alert on confirmed exploitation
2. Environment = PRODUCTION — ignore dev/test noise
3. Severity = CRITICAL or HIGH — focus analyst attention
Example alert
CRITICAL — Exploited Attack in Production Attack: sql-injection Application: cargo-cats-dataservice (Java) Endpoint: GET /payments Source IP: 10.1.7.201 Hostname: cargo-cats-dataservice-7bd8f7c4d8-lsw8p Environment: PRODUCTION Result: EXPLOITED Sink: HikariProxyStatement.execute() MITRE: TA0040 Impact, TA0010 Exfiltration, TA0009 Collection Console: https://app.contrastsecurity.com/Contrast/... (direct link to event)
Response playbook
Open the Contrast console link — review the full attack payload and code path
Assess impact: what data or function does the exploited sink have access to?
If Block Mode is available for this rule: enable it for this application
If not: escalate to AppSec for emergency mitigation (WAF rule, input validation, or code fix)
Search SIEM for the same source IP across other applications
Search SIEM for the same attack rule across other applications — is this a targeted campaign or opportunistic scanning?
Notify AppSec with the specific function and payload for remediation
What to send developers when escalating
When you hand over the attack event to AppSec or Engineering for remediation, include these fields from the attack event:
Application name: identifies the codebase to fix
File and method: exact source location of the vulnerable sink (for example,
app.py:test_connection() calling subprocess.run())Full stack trace: call path from the request handler to the sink
Attack payload: the exact malicious input that triggered the exploit (needed for a regression test)
HTTP request details: method, endpoint, headers, body
All five are populated automatically by Contrast ADR on every attack event. Forward them verbatim from the Contrast console; no extraction or summarization needed. None of this is available from WAF, EDR, or other perimeter tools. That’s why, without ADR, dev cycles to reproduce and remediate application-layer attacks are typically slow.
Key takeaway
This use case gives your SOC something it has never had: confirmed exploitation at the code level. Not “suspicious pattern matched” — “this attack payload reached HikariProxyStatement.execute() and modified the SQL query.” That certainty changes triage from investigation to response.