SQL Server is installed on hundreds of millions of Windows endpoints worldwide. The service often runs as a highly-privileged account — many legacy deployments still use Local System — and the database frequently holds credentials for other services, connection strings to downstream systems, and trust relationships to additional database servers across the environment.

When attackers gain initial access via a webshell, compromised service account, or lateral movement through another system, MSSQL frequently becomes the next stepping stone. Three abuse paths appear in post-exploitation scenarios consistently enough to warrant dedicated detection coverage.

Abuse Path 1: xp_cmdshell

xp_cmdshell is a built-in extended stored procedure that executes OS commands in the context of the SQL Server service account. It has been disabled by default since SQL Server 2005, but anyone with sysadmin rights can re-enable it in under ten seconds:

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

Attackers use this to download and execute payloads, enumerate local credentials, or establish C2 connectivity — all running as the SQL Server service account, which is frequently a domain account with read access to file shares across the environment.

Sigma Rule — xp_cmdshell Enablement or Execution:

title: MSSQL xp_cmdshell Enabled or Executed
id: a7f3c421-8bde-4f2a-9a1c-5e8b9d3e2f1a
status: stable
description: Detects enabling or execution of xp_cmdshell via SQL Server audit events
author: SOC Analyst Hub
date: 2026-06-23
tags:
    - attack.execution
    - attack.t1505.001
    - attack.t1059.003
logsource:
    product: windows
    service: application
detection:
    selection:
        EventID: 33205
        Message|contains:
            - 'xp_cmdshell'
            - "sp_configure 'xp_cmdshell'"
    condition: selection
falsepositives:
    - Legitimate DBA maintenance (rare; whitelist by source hostname)
level: high

KQL (Microsoft Sentinel — SQL Audit Logs):

AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| where action_name_s == "EXECUTE"
| where statement_s has_any ("xp_cmdshell", "sp_configure")
| project TimeGenerated, server_instance_name_s, client_ip_s,
          server_principal_name_s, statement_s
| sort by TimeGenerated desc

Detection requires SQL Server Audit to be enabled and logs forwarded to your SIEM. Windows Application Event Log alone is insufficient — it captures SQL Server startup and error events but not individual query executions.

Abuse Path 2: SQL Agent Job Persistence

SQL Server Agent is the built-in job scheduler. Attackers create Agent jobs with CmdExec or PowerShell step types to execute OS commands on a schedule, establishing persistence that survives reboots and is rarely inventoried during IR triage.

The key database tables are msdb.dbo.sysjobs and msdb.dbo.sysjobsteps. Any job with a step type of CmdExec (subsystem type 2) or PowerShell (type 16) warrants scrutiny.

Sigma Rule — Suspicious SQL Agent Job Creation:

title: SQL Server Agent Job with OS Command Execution Step
id: b2e4d567-9cf1-4e8b-a2c3-6f7d8e9f0a1b
status: experimental
description: Detects SQL Agent job creation with CmdExec or PowerShell steps
author: SOC Analyst Hub
date: 2026-06-23
tags:
    - attack.persistence
    - attack.t1053.005
logsource:
    product: windows
    service: application
detection:
    selection:
        EventID: 33205
        Message|contains: 'sp_add_jobstep'
    filter_type:
        Message|contains:
            - 'subsystem=CmdExec'
            - 'subsystem=PowerShell'
    condition: selection and filter_type
falsepositives:
    - Legitimate scheduled maintenance jobs (baseline and whitelist by job name)
level: high

Hunting Query — All CmdExec/PowerShell Agent Jobs:

Run this directly on a suspect SQL Server to enumerate suspicious persistence:

SELECT j.name        AS job_name,
       js.step_name,
       js.subsystem,
       js.command,
       j.date_created,
       j.date_modified,
       sp.name       AS owner
FROM   msdb.dbo.sysjobsteps js
JOIN   msdb.dbo.sysjobs j
       ON js.job_id = j.job_id
JOIN   sys.server_principals sp
       ON j.owner_sid = sp.sid
WHERE  js.subsystem IN ('CmdExec', 'PowerShell', 'ActiveScripting')
ORDER  BY j.date_modified DESC;

Include this query in your standard IR playbook for any engagement where MSSQL is present in the environment.

Abuse Path 3: Linked Server Lateral Movement

Linked Servers allow one SQL Server instance to execute queries against another. An attacker with sysadmin on Server A can execute xp_cmdshell on Server B via the EXEC ... AT syntax:

-- Execute OS command on linked server
EXEC ('xp_cmdshell ''net user hacker P@ssw0rd /add /domain''')
AT [DBSERVER-PROD-02]

This is pure lateral movement: one compromised database server becomes a pivot to every server it’s linked to. Linked server relationships often span environments — production, UAT, and DR — and are rarely audited after initial configuration.

Sigma Rule — Linked Server Remote Command Execution:

title: MSSQL Linked Server Remote Command Execution
id: c3f5e678-0da2-5f9c-b3d4-7e8f9a0b1c2d
status: experimental
description: Detects EXEC AT syntax invoking xp_cmdshell on a remote linked server
author: SOC Analyst Hub
date: 2026-06-23
tags:
    - attack.lateral_movement
    - attack.t1021
logsource:
    product: windows
    service: application
detection:
    selection:
        EventID: 33205
        Message|contains: 'xp_cmdshell'
    linked_indicators:
        Message|contains:
            - ' AT ['
            - 'OPENQUERY'
    condition: selection and linked_indicators
falsepositives:
    - Cross-server reporting queries through legitimate linked servers
level: critical

Audit Linked Servers:

SELECT name, product, provider, data_source,
       is_linked, modify_date
FROM   sys.servers
WHERE  is_linked = 1
ORDER  BY modify_date DESC;

Map all linked server relationships as part of your asset inventory. Any linked server that isn’t documented and business-justified is a lateral movement path waiting to be used.

Hardening Recommendations

Detection is important, but reducing the attack surface matters more:

Disable xp_cmdshell unless explicitly required by an application. Audit who holds sysadmin rights (the only role that can re-enable it) and reduce that list to the minimum viable set.

Audit SQL Agent jobs quarterly. Jobs owned by service accounts or with CmdExec/PowerShell steps should be documented and justified. Remove any that aren’t actively used.

Inventory and restrict Linked Servers. Each linked server relationship is a lateral movement path. Require change control approval for new linked server configurations and review existing ones annually.

Enable SQL Server Audit. Windows Application Event Log captures startup and error events but not query execution. SQL Server Audit to file or Windows Security log provides the telemetry these detection rules require.

Separate SQL Server service accounts. Running SQL Server as NETWORK SERVICE or a dedicated low-privilege domain account limits what an attacker can do via xp_cmdshell even if they succeed in enabling it.

The most common gap in MSSQL detection is the absence of SQL Audit telemetry in the SIEM. Without it, all three abuse paths generate minimal signal in standard Windows logs. Getting that telemetry pipeline in place is the prerequisite for everything else here.