Lateral Move via MSSQL Linked Servers — The super easy way

Linked Servers are one of the easiest ways to move around Active Directory using MSSQL server misconfigurations. They, LinkedServers, were meant to help DBAs and developers run remote queries and split workloads between servers. But like any cool feature, they become a security nightmare. In this post, I will share how I approach those. If you still do not get it after this, I owe you a Colombian coffee, deal?

Let’s break down this explanation in two blogs. This first part is about concepts. Because if we do not fully understand the concept behind remote TSQL queries and LinkedServers, our head will spin faster than that girl at the Exorcist movie.

The second blog will be about execution and tools. Because tools come and go. So, getting a good grasp of these concepts, will organically lead to a success on part two. Trust me!

Ok. Let’s get to the point.

Linked Server Definition

This is not that hard to understand, but it is the main building block for everything else.

Linked Servers is Microsoft’s terminology for the ability to send queries between SQL Servers. It allows one SQL Server instance to execute queries against another SQL Server instance. This capability is specific to SQL Server and, when it was introduced, it significantly changed how developers and administrators designed distributed database environments.

The image above illustrates two Linked Server connections. One goes from A to B. A second Linked Server connection goes from B to C.

Here is where it gets very interesting. From an attacker’s point of view, if server A is compromised and Linked Servers are misconfigured, it may be possible to execute queries on server C by chaining those connections. Depending on how authentication and privileges are configured, this can lead to Os command execution on C through SQL Server features that interact with the operating system.

If server C resides in a different domain, this permits lateral movement across domains within the same forest.

This is why proper MSSQL and Linked Server configuration is critical. Server C can be well hardened and direct credentials may not be available. However, if the SQL Server instance on A or even B is misconfigured and trusted connections or excessive privileges are in place, this can be catastrophic and result in unauthorized access to C.

The Method

Now here is the meat and potatoes of this blog.

This is the super easy way (method) to successfully enumerate and exploit LinkedServers. Useful for OSEP and even real engagements. It consists of these steps:

1. Identify linked server connections
2. Assess linked server configuration
3. Evaluate privileges

The first step is finding any existing LinkedServer connection. These connections define the paths an attacker may be able to traverse, including the ability to chain access from one server to another.

Once any linked server connections have been identified, we analyze how authentication and permissions are handled across them. The focus is on login mappings, impersonation settings, and whether remote procedure calls are enabled. Weak or overly permissive configurations are often the primary enabler for lateral movement.

The next and final step is to assess our current privileges. MSSQL server roles such as the sysadmin role provide full control over SQL Server and, in certain cases, access to features that let us interact with Windows. This can potentially let the user to escape from the SQL Server boundaries and execute OS level commands or even obtain a reverse shell on a system such as our Kali machine.

Easy, right? The Linked Server concept itself is actually simple. What can get tricky is translating that concept into actual commands. Depending on the tool you use, the resulting TSQL can look overly complex or confusing. Thankfully, there are ways to simplify it and avoid a quote nightmare. We will explore those in the second part.