SQLRecon: assessing Microsoft SQL Server from a C# console tool

A single console binary for SQL Server assessment

SQLRecon is described as a Microsoft SQL Server toolkit designed for offensive reconnaissance and post-exploitation. The project page points readers to a wiki for the detail on each technique, and the code is C# with the solution living in the SQLRecon/ directory of the repository.

The intended user is a security practitioner with access to a SQL Server instance, either because they were given it to test or because they are auditing one. The tool is not a database administration utility. Its modules answer questions that only matter during an assessment: whether auditing is enabled, what linked servers exist, what the server exposes about itself and about the Active Directory domain behind it.

Two things set it apart from a plain enumeration script. First, the project publishes a page of prevention, detection and mitigation guidance aimed at defenders, which tells you what the toolkit probes and therefore what its output should look like on a monitored estate. Second, the author has written up the tool on the IBM Security Intelligence site and presented it at Black Hat, so the technique set is documented publicly rather than kept as folklore.

The licence is BSD-3-Clause, and the repository contains a LICENSE file alongside the README and the SQLRecon/ source directory.

Enumeration modules that need no authentication provider

The module system is split in two, and the split reflects what is possible before and after you have credentials.

Enumeration modules do not require an authentication provider to be supplied. They are passed into the enumeration module flag, which has the short form /e: and the long form /enum:. Two are named in the documentation. Info shows information about the SQL server, and SqlSpns uses the current user token to enumerate the Active Directory domain for MSSQL service principal names. The SPN module is the interesting one for domain mapping, because it works from the token you already hold rather than from stored credentials.

SQL modules are the other family. They are executed against one or more instances of Microsoft SQL Server and are passed into the module flag, /m: or /module:. The published module matrix carries five columns per module: description, whether impersonation is used, whether linked execution is used, whether linked chain execution is used, and whether a privileged context is required. That matrix is the fastest way to understand the shape of the tool, because it shows that modules differ along two axes that matter for a defender: how the module reaches the server, and how far the module can travel once it is there.

AuditStatus is the clearest example. It checks whether SQL auditing is in place, and it is marked as working with impersonation, linked execution and linked chain execution, but it does not require a privileged context. CheckRpc, which obtains a list of linked servers, appears next in the same table.

Running the first enumeration module against a host

There is no installer script and no package manager entry in the documentation. Instead, the project says you can download a copy of SQLRecon from the releases page, or compile the solution yourself, describing that as cloning the repo, opening the solution file and building. The releases page is where the v4.0 build from 2026-04-02 lives.

The flags for the enumeration module are documented as follows:

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.

Read that carefully. The port option defaults to 1434 over UDP, which is the SQL Server Browser port used for instance discovery rather than the TCP port used for queries. The timeout defaults to three seconds, so a scan across many hosts will finish quickly, sometimes before a slow host has answered.

The sibling module for domain enumeration is passed with the same enumeration flag:

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

That module takes an optional domain name, which means it can either rely on the domain of the current token or be pointed at a specific NETBIOS name or FQDN. A first run should therefore look at what Info returns on a single host, then repeat against a wider list once you know what a healthy response looks like.

Six authentication providers and what each one needs

Interacting with a SQL Server requires picking an authentication provider, and the set of six covers the common Windows and Azure identity paths.

WinToken uses the current user's token to authenticate, which is the path of least resistance when the console is already running as a domain user. WinDomain takes explicit Active Directory credentials, with a host, a domain, a username and a password. Local uses local SQL credentials instead, with a host, a username and a password. The three of these are all passed with the authentication flag, /a: or /auth:.

The Azure pair behaves the same way. EntraID uses Azure EntraID credentials against an Azure SQL database and additionally takes a domain FQDN in the form DOMAIN.COM. AzureLocal uses local SQL credentials against an Azure SQL database. The documentation adds a hard prerequisite for EntraID: the Azure Active Directory Authentication Library (ADAL) or the Microsoft Authentication Library (MSAL) has to exist on the machine where SQLRecon runs, so the tool cannot rely on a credential alone in that case.

The sixth provider is the one that changes the security profile of a run. Pth authenticates using an NT hash over raw TDS/NTLM, in LM:NT format or as 32 hex characters, and the documentation states that elevated privileges or SeImpersonate are not required for it. That claim is the reason defenders should read the detection guidance before running it, because a hash-based authentication attempt against SQL Server is something that leaves traces in the logs that a policy-driven environment may catch.

Running one module across many SQL servers

The host flag is required and accepts one or more servers. To execute a module against several instances, separate the hosts with a comma:

/h:SQL01,10.10.10.2,SQL03

Three of the authentication providers explicitly document multiple host support, and the WinToken provider lists the host flag without that note, which suggests its single host handling differs. The enumeration Info module does document multiple hosts as well.

Two defaults shape what happens on each host. SQLRecon connects to the master database by default, and you can change that with the database flag, /database:. It connects over TCP port 1433 by default, and the /port: flag changes that, which matters for SQL Server failover clustering instances or servers configured with dynamic TCP ports, where the instance is not on 1433 at all.

The connection timeout defaults to three seconds, changed with /t: or /timeout:, and it applies per connection attempt. With a comma separated host list and a three second budget, a batch run against unreachable hosts will sit through the timeout on each one, so raising it for slow links is a practical adjustment rather than a tuning nicety.

The debug and verbose flags decide what reaches the server

Two optional flags change how much of the tool's behaviour you see, and they differ in an important way.

The /debug flag displays all SQL queries that are executed by a module without actually executing them on the remote hosts. That makes it a dry run for a module: you get the statement text and nothing runs. The /v or /verbose flag displays the same SQL queries before executing them on the remote hosts. The difference is one of effect, not verbosity, and the documentation includes examples of both in the wiki.

Between them they let you separate planning from action, which is what makes the toolkit usable in a shared or client environment. Running the module list with /debug first shows what a module intends to query on each target before a single statement reaches a production instance.

There is a limit to what the documentation covers. The published module table is truncated in the README, so the full module set, the description of each one and the rest of the matrix columns are not visible there; the wiki is where the per-technique detail lives. If you are planning an assessment, treat the wiki as the authoritative module list rather than assuming the README table is complete.

Release cadence, the defender page and the licence

The repository is not archived and the last push was on 2026-06-16, so work is landing after the most recent release rather than the project sitting idle. Three tags are visible in the recent history: v4.0 published on 2026-04-02, v3.10 on 2025-06-17 and v3.9 on 2024-12-17. The jump from a 3.x line to v4.0 suggests a breaking change somewhere, but the README does not state what changed, so treat the release notes for the version you pick as the place to check compatibility.

Upgrade cost here is mostly operational. The tool is a compiled C# console application, so a .NET runtime has to be present on whatever machine executes it, and the EntraID provider additionally needs ADAL or MSAL installed locally. Running the release build from the releases page avoids a build step, and the wiki linked from the README holds the per-technique instructions.

The licence is BSD-3-Clause, which permits redistribution and modification with attribution obligations. The same page also points to prevention, detection and mitigation guidance written for defenders, and that document is the most useful thing on the site for anyone running the toolkit on infrastructure they also have to protect.

Editorial conclusion

SQLRecon suits offensive security engineers who need one console binary to survey and then act against SQL Server estates, and it suits defenders who want to know which weaknesses the same tooling will find. It is a poor fit for general database administration, for Linux or macOS hosts without a .NET runtime, or for anyone who needs supported, auditable tooling rather than a research utility. Before deploying it, confirm the target Windows and .NET versions, and check the repository's own prevention, detection and mitigation guidance page to see which of your defensive controls the modules will test.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. skahwah/SQLRecon on GitHub