MSSQL linked-server crawl → cross-host RCE
Linked-server trust chains in MSSQL let a low-priv login execute as a higher-priv login on a remote SQL host — and pivot recursively across the estate.
§ Context
Assumed environment: attacker has any SQL login on one server. The estate has cross-database linked-server objects, frequently configured with cached credentials for service accounts.
§ Steps
- 01Dump LSASS for cached domain credsCredential AccessT1003.001— LSASS Memory
- 02Any SQL loginInitial AccessT1078— Valid Accounts
- 03Code exec as the SQL service accountExecutionT1059— Command and Scripting Interpreter
- 04Enumerate linked serversLateral MovementAD-MSSQL-LINK— MSSQL Linked Server Crawl
PowerUpSQL: Get-SQLServerLinkCrawl
- 05Enable xp_cmdshell on a privileged hopExecutionAD-MSSQL-XPCMD— MSSQL xp_cmdshell
- 06EXECUTE AS / openquery across linksPrivilege EscalationAD-MSSQL-IMPERSONATE— MSSQL EXECUTE AS
§ References
- T1003.001LSASS Memory
- T1078Valid Accounts
- T1059Command and Scripting Interpreter
§ Frequently asked
- What is the "MSSQL linked-server crawl → cross-host RCE" attack path?
- Linked-server trust chains in MSSQL let a low-priv login execute as a higher-priv login on a remote SQL host — and pivot recursively across the estate. It chains 6 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Dump LSASS for cached domain creds (T1003.001) — a credential access primitive. Assumed environment: attacker has any SQL login on one server.
- What is the final impact of this kill-chain?
- The final step lands on EXECUTE AS / openquery across links (AD-MSSQL-IMPERSONATE), which falls under Privilege Escalation. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques2
io_uring UAF → modprobe_path overwrite → root
Use an io_uring UAF to land arbitrary kernel write, repoint /proc/sys/kernel/modprobe to an attacker binary, then trigger a kernel auto-modprobe — runs the binary as root.
- Shared techniques2
nf_tables UAF → kernel R/W → root
CVE-2024-1086-class nf_tables UAF reachable from a user namespace. Win the race with userfaultfd to land an attacker object in the freed slot, build a kernel R/W primitive, overwrite the current task's cred struct.
- Shared techniques2
BYOVD → kernel-level disable of EDR callbacks
From local admin, load a signed-but-vulnerable driver. Use its kernel primitive to walk the EDR's PsSetCreateProcessNotifyRoutine entries and unlink them — EDR stops receiving events while still 'running'.
- Shared techniques2
Process doppelgänging → spawn signed image with attacker bytes
Use NTFS transactional file APIs to overlay an attacker image during process creation. The final mapped process differs from the on-disk file — AV sees only the legit signed image at scan time.
- Shared techniques2
certutil + bitsadmin → AV-friendly stager chain
Initial access dropped a tiny .bat. It uses certutil to decode a base64 blob and bitsadmin to fetch the real beacon, then schtasks for persistence. Every binary is signed Microsoft.
- Shared techniques2
F5 BIG-IP iControl auth bypass (CVE-2022-1388) → root on LB
Connection-header smuggle bypasses iControl REST auth, command-injection RCE as root. Load balancers see all traffic — recover TLS keys, session cookies, internal SSO config.