Potential SQL Injection Against Microsoft SQL Server

Identifies potential SQL injection attempts against Microsoft SQL Server by detecting obfuscated T-SQL patterns in SQL Server Audit events. Attackers use CHAR concatenation, CONVERT-based subqueries, and CASE/UNION constructs to bypass input validation and extract data or execute unauthorized statements.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/01"
  3integration = ["system", "windows"]
  4maturity = "production"
  5updated_date = "2026/07/01"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies potential SQL injection attempts against Microsoft SQL Server by detecting obfuscated T-SQL patterns in SQL
 11Server Audit events. Attackers use CHAR concatenation, CONVERT-based subqueries, and CASE/UNION constructs to bypass
 12input validation and extract data or execute unauthorized statements.
 13"""
 14from = "now-9m"
 15language = "esql"
 16license = "Elastic License v2"
 17name = "Potential SQL Injection Against Microsoft SQL Server"
 18references = [
 19    "https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions",
 20    "https://owasp.org/www-community/attacks/SQL_Injection",
 21]
 22risk_score = 73
 23rule_id = "e5d219fd-8362-4b67-a0b8-e3dd4331acdd"
 24severity = "high"
 25tags = [
 26    "Domain: Endpoint",
 27    "OS: Windows",
 28    "Use Case: Threat Detection",
 29    "Tactic: Initial Access",
 30    "Data Source: Windows Application Event Logs",
 31    "Resources: Investigation Guide",
 32]
 33timestamp_override = "event.ingested"
 34type = "esql"
 35
 36query = '''
 37from logs-system.application-*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index
 38| where host.os.type == "windows" and winlog.provider_name like "MSSQL*" and event.code == "33205"
 39| EVAL message_upper = TO_UPPER(message)
 40| where (
 41    message_upper RLIKE ".*CONVERT\\(INT,\\(SELECT (CHAR\\(\\d{1,3}\\)\\+){3,}.*" or 
 42    message_upper RLIKE ".*(CHAR\\(\\d{1,3}\\)\\+){3,}CHAR\\(\\d{1,3}\\).*" or 
 43    message_upper RLIKE ".*CASE WHEN \\(\\d+=\\d+\\).*UNION SELECT \\d+.*" or
 44    message_upper RLIKE ".*WAITFOR DELAY \\'0:0:\\d+\\'.*" or
 45    message_upper RLIKE ".*;\\s*(EXEC|EXECUTE)\\s*\\(?\\s*(MASTER\\.)?\\.?XP_CMDSHELL.*" or
 46    message_upper RLIKE ".*UNION SELECT (NULL\\s*,\\s*){2,}NULL.*" or
 47    message_upper RLIKE ".*'\\w*'\\s*\\+\\s*\\(\\(SELECT @@VERSION\\)\\)\\s*\\+\\s*'\\w*'.*" or
 48    message_upper RLIKE ".*(OR|AND)\\s+'?\\d+'?\\s*=\\s*'?\\d+'?\\s*--.*"
 49  )
 50| eval Esql.original_message = message
 51| keep
 52    @timestamp,
 53    host.id,
 54    host.name,
 55    host.ip,
 56    winlog.computer_name,
 57    message,
 58    event.outcome,
 59    Esql.original_message,
 60    _id,
 61    _version,
 62    _index,
 63    data_stream.namespace
 64    
 65| limit 10
 66'''
 67
 68note = """## Triage and analysis
 69
 70### Investigating Potential SQL Injection Against Microsoft SQL Server
 71
 72Microsoft SQL Server can write audit records to the Windows Application log as event ID 33205 when SQL Server Audit is
 73enabled. Adversaries exploit SQL injection vulnerabilities in applications that query SQL Server, often using obfuscated
 74T-SQL such as CHAR concatenation or UNION-based payloads to evade simple signature checks.
 75
 76#### Possible investigation steps
 77
 78- Review `Esql.original_message` and `message` for the full audited statement, including the application name, client
 79  address, database, and object targeted by the query.
 80- Identify the source application or service account associated with the audited session and determine whether it should
 81  execute dynamic or user-supplied SQL against the affected database.
 82- Correlate with web server, application, or proxy logs around `@timestamp` to identify the HTTP request or client that
 83  delivered the malicious input.
 84- Check for additional SQL Server Audit events (33205) from the same `host.id` or client address before and after the
 85  alert for follow-on statements such as xp_cmdshell, credential access, or data exfiltration.
 86- Investigate other alerts on `host.id` during the past 48 hours for signs of post-exploitation or lateral movement.
 87
 88### False positive analysis
 89
 90- Security scanners, penetration tests, or authorized application vulnerability assessments may generate matching audit
 91  events. Confirm the activity aligns with an approved test window, source address, and application before closing as
 92  benign.
 93- Custom applications that legitimately build dynamic SQL using CHAR concatenation are uncommon but possible. Review the
 94  full statement context and application owner before adding exceptions.
 95
 96### Response and remediation
 97
 98- Initiate the incident response process based on the outcome of the triage.
 99- If exploitation is confirmed, isolate the affected SQL Server or application tier, block the source IP at the
100  perimeter, and preserve SQL Server Audit and application logs for forensic analysis.
101- Patch or remediate the vulnerable application code path that allowed unsanitized input to reach SQL Server.
102- Review SQL Server permissions for the compromised application account and restrict access to only required databases
103  and objects.
104- Ensure SQL Server is not directly exposed to the internet and that SQL Server Audit remains enabled with appropriate
105  retention.
106"""
107
108setup = """## Setup
109
110SQL Server Audit must be configured to write audit events to the Windows Application log so that event ID 33205 is
111generated by the MSSQLSERVER provider (or MSSQL$<instance> for named instances).
112
113Setup instructions: https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/create-a-server-audit-and-server-audit-specification
114"""
115
116[rule.investigation_fields]
117field_names = [
118    "@timestamp",
119    "host.id",
120    "host.name",
121    "host.ip",
122    "winlog.computer_name",
123    "message",
124    "event.outcome",
125    "Esql.original_message",
126]
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[[rule.threat.technique]]
132id = "T1190"
133name = "Exploit Public-Facing Application"
134reference = "https://attack.mitre.org/techniques/T1190/"
135
136[rule.threat.tactic]
137id = "TA0001"
138name = "Initial Access"
139reference = "https://attack.mitre.org/tactics/TA0001/"

Triage and analysis

Investigating Potential SQL Injection Against Microsoft SQL Server

Microsoft SQL Server can write audit records to the Windows Application log as event ID 33205 when SQL Server Audit is enabled. Adversaries exploit SQL injection vulnerabilities in applications that query SQL Server, often using obfuscated T-SQL such as CHAR concatenation or UNION-based payloads to evade simple signature checks.

Possible investigation steps

  • Review Esql.original_message and message for the full audited statement, including the application name, client address, database, and object targeted by the query.
  • Identify the source application or service account associated with the audited session and determine whether it should execute dynamic or user-supplied SQL against the affected database.
  • Correlate with web server, application, or proxy logs around @timestamp to identify the HTTP request or client that delivered the malicious input.
  • Check for additional SQL Server Audit events (33205) from the same host.id or client address before and after the alert for follow-on statements such as xp_cmdshell, credential access, or data exfiltration.
  • Investigate other alerts on host.id during the past 48 hours for signs of post-exploitation or lateral movement.

False positive analysis

  • Security scanners, penetration tests, or authorized application vulnerability assessments may generate matching audit events. Confirm the activity aligns with an approved test window, source address, and application before closing as benign.
  • Custom applications that legitimately build dynamic SQL using CHAR concatenation are uncommon but possible. Review the full statement context and application owner before adding exceptions.

Response and remediation

  • Initiate the incident response process based on the outcome of the triage.
  • If exploitation is confirmed, isolate the affected SQL Server or application tier, block the source IP at the perimeter, and preserve SQL Server Audit and application logs for forensic analysis.
  • Patch or remediate the vulnerable application code path that allowed unsanitized input to reach SQL Server.
  • Review SQL Server permissions for the compromised application account and restrict access to only required databases and objects.
  • Ensure SQL Server is not directly exposed to the internet and that SQL Server Audit remains enabled with appropriate retention.

References

Related rules

to-top