Automating Blind SQL Injection Exploitation

The techniques we’ve discussed in this article regarding blind SQL injection enable the extraction and retrieval of database contents in a highly automated manner using either inference techniques or alternative channels. A number of tools are available to help an attacker exploit blind SQL injection vulnerabilities. We’ll discuss five popular tools in the following subsections.


The Absinthe GPL tool (previously known as SQLSqueal) was one of the first automated inference tools in widespread use and is thus a good starting point for examining automated blind SQL injection exploitation.

  • URL:

  • Requirements: Windows/Linux/Mac (.NET Framework or Mono)

  • Scenario: Generic error page, controlled output

  • Supported databases: Oracle, PostgreSQL, SQL Server, and Sybase

  • Methods: Inference response-based binary search; classic errors

Absinthe provides a handy GUI that enables an attacker to extract the full contents of a database; in addition, it contains enough configuration options to satisfy most injection scenarios and can utilize both classic error methods and response-based inference methods for data extraction. The response string that differentiates between two inference states must be easy for Absinthe to identify. One drawback to the tool is that the user cannot provide a customized signature for TRUE or FALSE states. Instead, the tool attempts to perform a diff on a TRUE and FALSE request, and this causes the tool to fail in cases where the page includes other data not influenced by the inference question. One example is in search pages that echo the search string back in the response. If two separate but equivalent inference exploits are provided, the two responses will each contain a unique search string rendering the diff meaningless. There is a tolerance you can fiddle with, but this is not as efficient as providing signatures.

Figure 1 shows the main Absinthe screen. First, you select the injection type, either Blind Injection or Error Based, and then choose the database from a list of supported plug-ins. Enter the Target URL along with whether the request is formatted as a POST or a GET. Finally, enter in the Name textbox each parameter that should be contained in the request, along with a Default Value. If the parameter is susceptible to SQL injection, select the Injectable Parameter check box; also, select the Treat Value as String check box if the parameter is of type string in the SQL query. Do not forget to add in all parameters needed for the vulnerable page to process the request; this includes hidden fields such as __VIEWSTATE on .NET pages.

Figure 1. Absinthe v1.4.1 Configuration Tab

Once the configuration is complete, click Initialize Injection. This sends a bunch of test requests to determine the response difference on which the inference will be based. If no errors are reported, click the DB Schema tab, which displays two active buttons: Retrieve Username and Load Table Info. The first button will retrieve and display the database login used by the vulnerable page and the second button will retrieve a list of user-defined tables from the current database. Once table information has been loaded, click a table name in the tree view of database objects and then click Load Field Info, which will retrieve a list of all column names in the selected table. As soon as that has completed, click the Download Records tab, provide an output filename in the Filename textbox, select the columns you wish to retrieve by clicking the column name and then clicking Add, and finally click Download Fields to XML. This will dump the selected columns to the output file, producing an XML document containing all rows from the selected columns in the target table.

BSQL Hacker

BSQL Hacker utilizes a number of inference techniques to enable the attacker to extract database contents, and is experimental in many of the approaches it implements. Although it is still in beta, there are numerous nifty features that bear exploration.

  • URL:

  • Requirements: Windows (.NET Framework)

  • Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors

  • Supported databases: Access, MySQL, Oracle, and SQL Server

  • Methods: Inference time-based modified binary search; inference response-based modified binary search; classic errors

BSQL Hacker is a graphical GPL tool designed to make exploitation of blind SQL injection vulnerabilities trivial by separating attack templates from the injection strings required to extract particular items from the database. It comes with templates for different types of blind SQL injection attacks against three databases and also stores exploits to extract interesting data from the databases. The tool is designed to be used by novices and experts alike; for the former an Injection Wizard is provided that attempts to figure out all the details of a vulnerability, and for the latter full control over the exploit string is provided.

At the time of this writing, BSQL Hacker is still in beta and is not completely stable. The Injection Wizard did not correctly derive a working exploit in most scenarios I tested and the Automated Injection mode did not work for Oracle or MySQL, and worked only partially for SQL Server. Given the vicarious nature of real-world vulnerabilities the tool makes a decent effort to help the attacker out; however, sometimes exploitation is achievable only with human insight. Other minor nuisances include memory bloat and a crowded interface that has interdependent options in different locations, but all in all the tool does support a large number of attack techniques against three popular databases, and its multithreaded model speeds up injection attacks.

After loading the tool, click File | Load which brings up a file selection dialog containing a list of template files for various databases. Each file contains a template for a specific technique; for example, Template-Blind-ORACLE is used for a blind attack against an Oracle database. Select the file matching your database; if a second dialog is loaded enter the full URL of the vulnerable site, including GET parameters, and click OK.

The Target URL textbox on the Dashboard tab will be populated with the attack template that was loaded from the file. Edit the Target URL such that the attack template fits the vulnerable page. For instance, when loading the Blind-Oracle template, the Target URL textbox contains the following URL: AND

Any strings within {} are “magic variables” that BSQL Hacker replaces at runtime. For the most part, we can leave these alone; instead, we will change the URL from to the vulnerable site along with the GET parameters (for POST requests, use the same request string, except place the parameters and their values in the Post Data table on the Request & Injection tab):' AND

Notice that we replaced {INJECTION} with “select user from dual” in addition to the other changes; the Oracle injection template was flawed, so it was possible to issue only specific queries.

Once the URL is configured, select Oracle from the drop-down list in the toolbar (Figure 2). If the inference method is not response-based, you can perform further configuration on the Detection tab. Otherwise, BSQL Hacker will attempt to determine the difference in responses automatically. This automated detection suffers from the same limitation as Absinthe, but BSQL Hacker will also accept user-supplied signatures, unlike Absinthe.

Figure 2. Selecting the BSQL Hacker Database Plug-in

Now that you have performed all of the necessary configurations, it is time to verify the settings. Click Test Injection and a dialog should display an “Injection succeed.” message. If it doesn’t, verify that the correct database is selected in the drop-down list and ensure that the exploit string correctly completes the original SQL query. You can review requests and responses in the Request History pane.

Assuming all settings are correct, deselect the Automated Attacks button as these attack strings are flawed; in any case, you are just interested in the database login. Finally, click the Start button, which will execute the attack and print the extracted data into the Status pane of the Dashboard, as shown in Figure 3. Although BSQL Hacker attempts to extract database schemas and contents automagically, this feature was lacking reliability and the tool seems best suited for specific queries.

Figure 3. Extracting Database Login Using BSQL Hacker


Attackers who are comfortable with the fundamentals behind inference attacks use the SQLBrute command-line tool due to its lightweight nature and straightforward syntax.

  • URL:

  • Requirements: Python (Windows/Linux/Mac)

  • Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors

  • Supported databases: Oracle and SQL Server

  • Methods: Inference time-based binary search; inference response-based modified binary search

SQLBrute relies only on a Python interpreter, and at 31 KB it is tiny compared to the other tools examined. This makes it ideal for focused injection scenarios or where file size is important, and its thread support boosts speed. A drawback is that it uses a fixed alphabet from which inference tests are drawn; if a byte in the data is not contained within the alphabet it cannot be retrieved, which limits the tool to text-based data.

To run the tool, you will need the full path to the vulnerable page along with any data that must be submitted (either GET or POST parameters). If you’re using the response-based mode, you must supply a regular expression in the –error argument that indicates when the inference question returns false; otherwise, the timing-based mode is available. In the example depicted in Figure 4, SQLBrute has been run in response-based mode against a vulnerable SQL server, and two table names have been extracted from the database. Based on our exploration, we know that when an inference question returns FALSE, the page contains “Review count :0”, but this could also be a regular expression instead of a fixed string if needed. After execution commences, the tool performs a little bit of fingerprinting and starts to extract data and print it to the screen.

Figure 4. Running SQLBrute

SQLBrute is best suited to experienced users who favor simplicity and unobfuscated operation.


Without going through the rest of this tool’s prodigious capabilities, sqlninja does support command execution using DNS as a return channel on SQL Server installations, and we’ll concentrate on that feature.

  • URL:

  • Requirements: Perl, plus a number of number of Perl modules (Linux)

  • Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors

  • Supported database: SQL Server

  • Methods: Inference time-based binary search; alternative channel = DNS

The user implements the channel by first uploading an executable helper program onto the vulnerable database’s operating system. Once that’s in place, he calls the helper application using xp_cmdshell, passes it a domain name (e.g., for which the attacker’s IP address is an authoritative DNS server), and provides it with a command to execute. The helper executes the command, captures the output, and initiates DNS lookups by prefixing the supplied domain with the output. These DNS queries will arrive at the attacker’s address and are decoded by sqlninja and displayed. Sqlninja includes a stand-alone DNS server component which answers queries for the purposes of eliminating timeouts. Figure 5 shows an instance of sqlninja that was used to retrieve the account under which SQL Server was running using the whoami command. Because sqlninja relies on both xp_cmdshell and file creation, privileged database access is a must.

Figure 5. Executing sqlninja to Extract a Username via DNS


The final tool examined for automating blind SQL injection exploitation, squeeza is a command-line tool that supports multiple methods for extracting information from SQL Server databases, with particular emphasis placed on the DNS channel where a reliability layer is added.

  • URL:

  • Requirements: Ruby, tcpdump for DNS channel (Linux/Mac), authoritative DNS server for any domain

  • Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors

  • Supported database: SQL Server

  • Methods: Inference time-based bit-by-bit; alternative channel = DNS

Squeeza takes a slightly different approach to SQL injection in general by dividing injection into data creation (e.g., command execution, a file from the database’s file system, or an SQL query) and data extraction (e.g., using classic errors, timing inference, and DNS). This enables the attacker to mix and match to a large degree: command execution using timing as the return channel, or file copy over DNS. We will focus solely on the DNS extraction channel combined with command execution for data generation for brevity’s sake.

Squeeza’s DNS channel is handled entirely in T-SQL, meaning that there is no requirement for privileged database access (where privileged access is available, it is used as this speeds up extraction). Obviously, when data is generated via command execution, privileged access is required; likewise for file copying. Squeeza also makes every attempt to be reliable in the face of unpredictable UDP DNS packets, and has a transport layer that ensures that all data arrives. It can also handle very long fields (up to 8,000 bytes) and can extract binary data.

Settings are stored in a configuration file for persistence, with the minimum details required being the Web server (host), a path to the vulnerable page (URL), any GET or POST parameters (querystring), and whether the request is a GET or a POST (method). Inside the querystring, the marker X_X_X_X_X_X is used to locate where injection strings are placed. Figure 6 is a screenshot showing squeeza returning a directory listing via DNS.

Figure 6. Squeeza Returning a Directory Listing