5.3 SQL Injection with Data Exfiltration (ADR + DLP)

What this use case does: Correlates a Contrast ADR confirmed SQL injection exploit with a DLP alert on the same host — proving that the injection led to sensitive data access or exfiltration.

The scenario

An attacker exploits a SQL injection vulnerability in your application. The injected query reaches the database and returns data it shouldn’t — customer records, credentials, PII. Contrast ADR sees the injection at the application layer. Your DLP tool sees the sensitive data access at the database or network layer. Neither tool alone tells the full story. Together, they confirm: this SQL injection caused this data breach.

The detection gap

ADR alone	DLP alone	ADR + DLP correlated
Confirmed SQL injection in execute() — but what data was accessed?	Anomalous data access on users table — but why? Misconfigured query? Authorized report? Attack?	Confirmed: SQL injection in `execute()` caused unauthorized access to users table. Root cause + impact in one alert.
Can block the injection. Cannot assess breach scope.	Can flag the data access. Cannot identify the root cause.	Breach scope and root cause confirmed — you have what you need for incident response and notification.

Attack timeline

Phase	What ADR sees	What DLP sees	Combined picture
Exploit	SQL injection in application. Payload: ' `UNION SELECT username, password_hash FROM users--` . Result: EXPLOITED. Sink: `HikariProxyStatement.execute()`	Nothing yet	ADR identifies the root cause and attack vector
Data Access	ADR detects the injected query executed against the database	DLP detects anomalous data access: sensitive columns accessed, unusual volume returned	ADR explains how (injection) + DLP confirms what was accessed
Exfiltration	ADR provides the injection context and the exploited function	DLP detects sensitive data patterns (PII, credentials) leaving the network	Full chain: injection → data access → exfiltration confirmed

Correlation logic: ADR exploit event joined with DLP alert on the same target hostname within a 1-hour window. The wider time window accounts for the delay between the injection and DLP detecting the resulting data movement.

Example alert

CRITICAL — SQL Injection with DLP Alert (Risk Score: 99)
--- ADR Detection ---
Attack: sql-injection
Application: cargo-cats-dataservice (Java)
Endpoint: GET /payments
Sink: HikariProxyStatement.execute()
Query: INSERT INTO credit_card (card_number, shipment_id)
VALUES ('9999999999999999 ' AND SLEEP(5) OR 'a'='a', 1)
Source IP: 10.1.7.201
Result: EXPLOITED
--- DLP Detection ---
Product: [DLP product name]
Category: DATA_EXFILTRATION
Resource: users table — sensitive columns accessed
Description: [DLP alert description]
--- Correlation ---
Join: Target hostname match within 1-hour window

Response playbook

Immediate: Enable Block Mode for SQL injection on the affected application

Open both the ADR console link and DLP alert — confirm the correlation is valid (same app, same timeframe)

Assess breach scope using DLP data: which tables, which columns, how many records

Preserve evidence: ADR logs (attack vector + payload) + DLP logs (data accessed + volume)

Notify Legal/Compliance with the precise scope — you have the root cause (ADR) and the impact (DLP)

Escalate to AppSec: provide the exact function, the reconstructed query (from vectorAnalysis.query ), and the endpoint for emergency fix

Search SIEM for the same source IP targeting other applications

Flag affected database tables for enhanced DLP monitoring

Key takeaway

ADR tells you how the attacker got in. DLP tells you what they took. Together, you get the two things you need most for breach response: verified root cause + precise impact scope. Without the correlation, your SOC is investigating two separate alerts that each tell half the story.

In this section: