SQLRecon is a Microsoft SQL Server toolkit that is designed for offensive reconnaissance and post-exploitation. For detailed information on how to use each technique, refer to the wiki.

You can download a copy of SQLRecon from the releases page. Alternatively, feel free to compile the solution yourself. This should be as straight forward as cloning the repo, double clicking the solution file and building.

Prevention, detection and mitigation guidance has also been provided for all you defenders out there.

Check out my blog post on the IBM Security Intelligence website. If you prefer videos, then check out my presentation at Black Hat.

Enumeration Modules do not require an authentication provider to be supplied. These modules must be passed into the enumeration module flag (/e:, /enum:). The wiki has details on using enumeration modules.

Info    - Show information about the SQL server.
          /h:, /host    -> SQL server hostname or IP. Multiple hosts supported.
          /port:        -> (OPTIONAL) Defaults to 1434 (UDP).
          /t:, timeout: -> (OPTIONAL) Defaults to 3s.

SqlSpns - Use the current user token to enumerate the AD domain for MSSQL SPNs.
          /d:, /domain: -> (OPTIONAL) NETBIOS name or FQDN of domain.

SQLRecon supports a diverse set of authentication providers (/a:, /auth:) to enable interacting with a Microsoft SQL Server.

WinToken   - Use the current users token to authenticate against the SQL database
             /h:, /host:     -> SQL server hostname or IP

WinDomain  - Use AD credentials to authenticate against the SQL database
             /h:, /host:     -> SQL server hostname or IP. Multiple hosts supported.
             /d:, /domain:   -> NETBIOS name or FQDN of domain.
             /u:, /username: -> Username for domain user.
             /p:, /password: -> Password for domain user.

Local      - Use local SQL credentials to authenticate against the SQL database
             /h:, /host:     -> SQL server hostname or IP. Multiple hosts supported.
             /u:, /username: -> Username for local SQL user.
             /p:, /password: -> Password for local SQL user.

EntraID    - Use Azure EntraID credentials to authenticate against the Azure SQL database
             /h:, /host:     -> SQL server hostname or IP. Multiple hosts supported.
             /d:, /domain:   -> FQDN of domain (DOMAIN.COM).
             /u:, /username: -> Username for domain user.
             /p:, /password: -> Password for domain user.

AzureLocal - Use local SQL credentials to authenticate against the Azure SQL database
             /h:, /host:     -> SQL server hostname or IP. Multiple hosts supported.
             /u:, /username: -> Username for local SQL user.
             /p:, /password: -> Password for local SQL user.

• Hosts: The host flag (/h:, host:) is required and allows one or more SQL servers. If you want to execute a module against multiple SQL servers, separate the hosts with a comma, for example /h:SQL01,10.10.10.2,SQL03.
• Database: SQLRecon connects to the master database by default, however, this can be optionally changed by supplying a custom database name via the database (/database:) flag.
• Debug: The /debug flag is optional and displays all SQL queries that are executed by a module, without actually executing them on the remote host(s). An example of this can be found in the wiki.
• Port: In some cases, a Microsoft SQL Server may not be listening on a standard TCP port. Some examples are Microsoft SQL Server failover clustering, or dynamic TCP ports. SQLRecon connects to databases via TCP Port 1433 by default, however, this can be optionally changed using the /port: flag.
• Timeout: The default SQL database connection time is 3 seconds, however, this value can be optionally changed by supplying a timeout value (/t:, /timeout:) which corresponds to the number of seconds before terminating the connection attempt.
• Verbose: The /v, /verbose flag is optional and displays all SQL queries that are executed by a module before executing them on the remote host(s). An example of this can be found in the wiki.

Please note that the EntraID authentication provider requires that the Azure Active Directory Authentication Library (ADAL) or Microsoft Authentication Library (MSAL) exists on the system SQLRecon is executed from. This is for Azure EntraID authentication and authorization functionality.

SQL modules are executed against one or more instance of Microsoft SQL server. These modules must be passed into the module flag (/m:, /module:).

The host flag (/h:, host:) is required and allows one or more SQL servers. If you want to execute a module against multiple SQL servers, separate the hosts with a comma, for example /h:SQL01,10.10.10.2,SQL03.

The wiki has details on using each module which supports execution on one or more instance of SQL Server.

Impersonation modules are executed against one or more instances of Microsoft SQL server, under the context of an impersonated SQL user. All impersonation modules have the following minimum requirements:

• An impersonation user must be specified (/i:, /iuser:).
• A module which supports impersonation must be specified (/m:, /module:).

The wiki has details on using each module which supports execution using Impersonation.

Linked modules are executed on one or more instances of a linked Microsoft SQL server. All linked modules have the following minimum requirements:

• A linked SQL server must be specified (/l:, /link:). The link flag allows one or more linked SQL servers. For example, if SQL01 has a link to SQL02, and SQL01 has a link to DB04, you can separate the linked hosts with a comma, and a module will be executed on each linked SQL server, for example /l:SQL02,DB04.
• A module which supports linked execution must be specified (/m:, /module:).

The wiki has details on using each module which supports execution on one or more instance of a Linked SQL Server.

Linked chain modules are executed on the final Microsoft SQL server in a linked server chain. All linked chain modules have the following minimum requirements:

• A linked SQL server chain must be specified in the /l:, /link: flag. If SQL01 has a link to SQL02, and SQL02 has a link to PAYMENTS01, and you want to execute a module on PAYMENTS01, then the argument would be /l:SQL02,PAYMENTS01.
• The /chain flag must be included to execute the module against the final SQL server in the supplied linked chain.
• A module which supports linked chain execution must be specified (/m:, /module:).

The wiki has details on using each module which supports execution on the final SQL server supplied in a Linked SQL Server Chain.

SQLRecon has several modules that can assist with enumerating and attacking Microsoft System Center Configuration Manager (SCCM) and Microsoft Endpoint Configuration Manager (ECM). The SCCM or ECM server will need to have a Microsoft SQL database exposed either locally or remotely.

SCCM modules must be passed into the SCCM module flag (/s:, /sccm:).

Most of the SCCM modules can be executed under the context of an impersonated SQL user (/i:, /iuser:).

The wiki has details on using each module against an SCCM/ECM database.

If you are interested in extending SQLRecon, please refer to the contributing and extending section in the wiki.

I encourage you to open an issue if you have any suggestions or ideas.

The goal is to continuously improve SQLRecon. Listed below are some planned research areas:

• Implement support for NTLM hash-based authentication.
• Explore enablerpc/disablerpc functionalities for linked and link chained SQL servers.

The following people have contributed either directly or indirectly to various aspects of SQLRecon.

• Adam Chester (xpn)
• Azaël Martin (n3rada)
• Daniel Duggan (rasta-mouse)
• Dave Cossa (G0ldenGunSec)
• Dwight Hohnstein (djhohnstein)
• Joshua Magri (passthehashbrowns)