MSSQL failed logon burst
Repeated SQL Server login failures in a short window — a password-guessing attack against the database rather than against Windows.
What it detects
Repeated SQL Server login failures in a short window — a password-guessing attack against the database rather than against Windows.
This is a distinct path from the Windows logon-failure rules and needs its own detection: an internet-reachable SQL Server with SQL authentication enabled is a standard initial-access target, and a successful sa compromise leads directly to command execution via xp_cmdshell. None of that traffic produces a 4625, so the Windows brute-force rules never see it.
MSSQL writes 18456 to the Application log for every failed login. The reason code distinguishing "wrong password" from "no such login" lives in the provider's message resources, which are not present in an exported log, so this rule counts failures rather than classifying them.
MITRE ATT&CK mapping
False positives and triage
An application with stale credentials in a connection string produces exactly this pattern, and will keep producing it indefinitely — reconnect loops are the single most common cause of an 18456 burst.
To distinguish: a misconfigured application retries from ONE source with ONE login name at a machine-like, regular interval. An attack varies the login name (sa, admin, test) or the source. Check whether any attempt eventually SUCCEEDED — an 18456 burst that stops and is followed by a successful login is the case to escalate immediately, and xp_cmdshell activity afterwards means the host is already compromised.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/windows/mssql_failed_logon_burst.yaml, licensed under the Apache License 2.0.
id: windows.auth.mssql_failed_logon_burst
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [windows]
mitre_techniques: [T1110, T1110.001]
description: |
Repeated SQL Server login failures in a short window — a password-guessing attack
against the database rather than against Windows.
This is a distinct path from the Windows logon-failure rules and needs its own
detection: an internet-reachable SQL Server with SQL authentication enabled is a
standard initial-access target, and a successful `sa` compromise leads directly to
command execution via `xp_cmdshell`. None of that traffic produces a 4625, so the
Windows brute-force rules never see it.
MSSQL writes 18456 to the Application log for every failed login. The reason code
distinguishing "wrong password" from "no such login" lives in the provider's
message resources, which are not present in an exported log, so this rule counts
failures rather than classifying them.
match:
provider_contains_any: ['MSSQL']
native_event_id: '18456'
threshold:
count: 5
window_seconds: 300
group_by: [hostname]
correlation_keys: [hostname]
false_positive_guidance: |
An application with stale credentials in a connection string produces exactly this
pattern, and will keep producing it indefinitely — reconnect loops are the single
most common cause of an 18456 burst.
To distinguish: a misconfigured application retries from ONE source with ONE login
name at a machine-like, regular interval. An attack varies the login name (`sa`,
`admin`, `test`) or the source. Check whether any attempt eventually SUCCEEDED —
an 18456 burst that stops and is followed by a successful login is the case to
escalate immediately, and `xp_cmdshell` activity afterwards means the host is
already compromised.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.