Lion Cipher Lab

Command execution on Microsoft SQL Server via xp_cmdshell — prove it, then harden it

• Penetration Testing / Red Team
• Intermediate
• ~75 min
• Free · no account required

Why it matters

Databases are where the crown jewels live, and Microsoft SQL Server is one of the most common databases in enterprise environments. The single most damaging way it gets owned is boring: the `sa` account -- the built-in system administrator login -- is left with a weak, guessable, or reused password, and the server is reachable on the network. That is not a data-theft problem, it is a whole-host problem, because a SQL Server sysadmin can reconfigure the server, and one of the things they can turn on is xp_cmdshell, a built-in feature that runs operating-system commands. The reason this lab…

What you'll learn

• explaining in plain words why a Microsoft SQL Server with a weak `sa` password is a critical exposure: `sa` is the built-in sysadmin login, and a sysadmin can reconfigure the server itself -- including turning on features that run operating-system commands
• standing up a real SQL Server locally and for free with the official Docker image (mcr.microsoft.com/mssql/server:2022-latest) so you can practise the whole find-and-fix loop on a server you own
• connecting to SQL Server with impacket's mssqlclient and reading the server's own configuration to see the state of security-relevant options
• proving the BEFORE state honestly: `xp_cmdshell` is DISABLED by default, so an attempt to run an OS command errors out with a message that says exactly that -- the feature is off, not broken
• understanding what xp_cmdshell is (an extended stored procedure that shells out to the OS) and why it runs commands as the SQL Server SERVICE account, not necessarily as SYSTEM
• understanding sp_configure / RECONFIGURE: how a sysadmin toggles advanced server options, and why 'show advanced options' has to be on first
• measuring the AFTER state: with sysadmin access the option can be re-enabled and an OS command returns output -- demonstrating that a weak sa password is a full server-and-host compromise, not just a data-read
• hardening and RE-MEASURING: disable xp_cmdshell again, set a strong sa password (or disable the sa login entirely), run the engine under a least-privileged service account, and restrict who can reach port 1433 -- then watch the same attempt fail
• the judgment: the vulnerability is the WEAK PASSWORD, not the existence of xp_cmdshell; on a hardened install (strong/disabled sa, non-sysadmin app logins, network isolation) none of this is reachable, which is why the fix is about accounts and exposure, not about the feature alone
• placing the technique on MITRE ATT&CK -- T1078 (Valid Accounts, for abusing the sa login) and T1059 (Command and Scripting Interpreter, for the OS command) -- so you know what a defender hunts for

Steps in this lab

1. First, the shape of the problem — an account, not a magic bug
2. Set up: run a real SQL Server locally, for free
3. Install impacket and connect as sa
4. BEFORE — prove xp_cmdshell is OFF by default
5. AFTER — a sysadmin can turn it back on
6. Why this worked — and why the naive fix misses the point
7. HARDEN — set xp_cmdshell back off
8. HARDEN — fix the real hole: the account and the exposure
9. Honest limits, and how a pro thinks about it

Open the full interactive lab →