Multiple SonicWall Login Failures Followed by Successful Login

  1[metadata]
  2creation_date = "2026/07/31"
  3integration = ["sonicwall_firewall"]
  4maturity = "production"
  5updated_date = "2026/07/31"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies multiple failed SonicWall authentication attempts against several user accounts from one source IP, followed
 11by a successful remote-access login from the same source to the same appliance. This may indicate successful password
 12spraying, credential stuffing, or password guessing.
 13"""
 14false_positives = [
 15    """
 16    Shared egress addresses, managed service providers, help desks, identity-provider outages, password rotation, or
 17    several legitimate users entering incorrect credentials before another user successfully authenticates may trigger
 18    this rule. Add exceptions only for confirmed shared-service sources and scope them to the relevant appliance.
 19    """,
 20]
 21from = "now-15m"
 22interval = "5m"
 23language = "esql"
 24license = "Elastic License v2"
 25name = "Multiple SonicWall Login Failures Followed by Successful Login"
 26note = """## Triage and analysis
 27
 28### Investigating Multiple SonicWall Login Failures Followed by Successful Login
 29
 30This rule detects at least five failed authentication events affecting at least three users from one source IP to one SonicWall appliance, followed by at least one successful remote-access login after the failure activity began. The successful user does not have to be one of the failed users because credential attacks can test several credential pairs and shared source infrastructure can target multiple accounts.
 31
 32Failure event codes include incorrect or unknown credentials, RADIUS or LDAP authentication failures, and account lockouts. Successful event codes cover VPN- or WAN-zone administrator and remote-user logins, including SSL VPN.
 33
 34### Possible investigation steps
 35
 36- Review `source.ip`, its ASN, geolocation, reputation, and prior activity. Determine whether it belongs to expected corporate proxy, VPN egress, managed service provider, jump-host, or monitoring infrastructure.
 37- Review `Esql.failed_user_names`, `Esql.successful_user_names`, `Esql.failed_logins`, `Esql.failed_user_count`, and `Esql.successful_logins`. Determine whether a successful user was also targeted by the failed attempts.
 38- Review `Esql.failure_event_codes` and `Esql.success_event_codes` to distinguish administrator, remote-user, SSL VPN, LDAP, RADIUS, and lockout activity.
 39- Examine the sequence between `Esql.first_failure`, `Esql.last_failure`, `Esql.first_success`, and `Esql.last_success`. Look for automated pacing, username enumeration, repeated attempts, or continued failures after the first successful login.
 40- Confirm whether MFA was required and completed for each successful authentication.
 41- Correlate successful VPN sessions with assigned tunnel IPs, internal authentication, DNS, network flow, and endpoint activity. For administrator logins, review subsequent SonicWall configuration changes.
 42
 43### False positive analysis
 44
 45- Several users behind a shared public address may enter incorrect credentials while another user authenticates.
 46- Password rotation, expired cached credentials, LDAP or RADIUS issues, help-desk testing, and synthetic monitoring can generate failure-to-success patterns.
 47- Validate the source and workflow before adding an exception. Prefer an exception scoped by both source and appliance rather than excluding a user or source globally.
 48
 49### Response and remediation
 50
 51- If unauthorized access is suspected, disable affected accounts, terminate active sessions, reset credentials, revoke tokens or keys, and enforce MFA.
 52- Block or restrict the source at the SonicWall appliance while investigating.
 53- Review configuration changes and downstream activity from successful VPN sessions. Isolate affected systems and begin incident response if post-authentication activity is identified.
 54- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes.
 55"""
 56references = [
 57    "https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign",
 58    "https://www.elastic.co/docs/reference/integrations/sonicwall_firewall",
 59    "https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM",
 60]
 61risk_score = 73
 62rule_id = "efe7ac71-3b13-41cf-8263-30af68ce3f19"
 63setup = """## Setup
 64
 65This rule requires the Elastic **SonicWall Firewall** integration and SonicWall Enhanced Syslog authentication events.
 66
 67Configure the appliance to forward **Users > Authentication Access** and **Users > RADIUS Authentication** events.
 68Confirm that credential failure event codes `30`, `32`, `33`, `200`, `243`, `329`, `745`, `749`, and `1655`, and
 69successful remote-access event codes `235`, `236`, `237`, `238`, and `1080`, are collected. Verify that the integration
 70populates `data_stream.dataset`, `event.action`, `event.code`, `source.ip`, `user.name`, and either
 71`observer.serial_number` or a unique `observer.name`.
 72
 73If several customers share one Kibana space, ensure the appliance identity is unique per tenant so activity from
 74different customers is not aggregated together.
 75"""
 76severity = "high"
 77tags = [
 78    "Domain: Network",
 79    "Domain: Identity",
 80    "Use Case: Threat Detection",
 81    "Use Case: Identity and Access Audit",
 82    "Tactic: Credential Access",
 83    "Tactic: Initial Access",
 84    "Data Source: SonicWall",
 85    "Resources: Investigation Guide",
 86]
 87timestamp_override = "event.ingested"
 88type = "esql"
 89
 90query = '''
 91from logs-sonicwall_firewall.log-*
 92| where
 93    data_stream.dataset == "sonicwall_firewall.log" and
 94    (
 95      (
 96        event.action == "login-failure" and
 97        event.code in ("30", "32", "33", "200", "243", "329", "745", "749", "1655")
 98      ) or (
 99        event.action == "login-success" and
100        event.code in ("235", "236", "237", "238", "1080")
101      )
102    ) and
103    source.ip is not null and
104    user.name is not null and
105    (observer.serial_number is not null or observer.name is not null)
106| eval
107    Esql.appliance_id = coalesce(observer.serial_number, observer.name),
108    Esql.is_failure = case(event.action == "login-failure", 1, 0),
109    Esql.is_success = case(event.action == "login-success", 1, 0),
110    Esql.failed_user = case(event.action == "login-failure", user.name, null),
111    Esql.successful_user = case(event.action == "login-success", user.name, null),
112    Esql.failure_event_code = case(event.action == "login-failure", event.code, null),
113    Esql.success_event_code = case(event.action == "login-success", event.code, null),
114    Esql.failure_timestamp = case(event.action == "login-failure", @timestamp, null),
115    Esql.success_timestamp = case(event.action == "login-success", @timestamp, null)
116| stats
117    Esql.failed_logins = sum(Esql.is_failure),
118    Esql.successful_logins = sum(Esql.is_success),
119    Esql.failed_user_count = count_distinct(Esql.failed_user),
120    Esql.failed_user_names = values(Esql.failed_user),
121    Esql.successful_user_names = values(Esql.successful_user),
122    Esql.failure_event_codes = values(Esql.failure_event_code),
123    Esql.success_event_codes = values(Esql.success_event_code),
124    Esql.first_failure = min(Esql.failure_timestamp),
125    Esql.last_failure = max(Esql.failure_timestamp),
126    Esql.first_success = min(Esql.success_timestamp),
127    Esql.last_success = max(Esql.success_timestamp)
128  by Esql.appliance_id, source.ip
129| where
130    Esql.failed_logins >= 5 and
131    Esql.failed_user_count >= 3 and
132    Esql.successful_logins >= 1 and
133    Esql.first_failure < Esql.last_success
134| eval Esql.failure_to_success_seconds = date_diff("seconds", Esql.first_failure, Esql.last_success)
135| sort Esql.failed_user_count desc, Esql.failed_logins desc
136| keep source.ip, Esql.*
137'''
138
139
140[[rule.threat]]
141framework = "MITRE ATT&CK"
142[[rule.threat.technique]]
143id = "T1110"
144name = "Brute Force"
145reference = "https://attack.mitre.org/techniques/T1110/"
146[[rule.threat.technique.subtechnique]]
147id = "T1110.001"
148name = "Password Guessing"
149reference = "https://attack.mitre.org/techniques/T1110/001/"
150
151[[rule.threat.technique.subtechnique]]
152id = "T1110.003"
153name = "Password Spraying"
154reference = "https://attack.mitre.org/techniques/T1110/003/"
155
156[[rule.threat.technique.subtechnique]]
157id = "T1110.004"
158name = "Credential Stuffing"
159reference = "https://attack.mitre.org/techniques/T1110/004/"
160
161
162
163[rule.threat.tactic]
164id = "TA0006"
165name = "Credential Access"
166reference = "https://attack.mitre.org/tactics/TA0006/"
167[[rule.threat]]
168framework = "MITRE ATT&CK"
169[[rule.threat.technique]]
170id = "T1078"
171name = "Valid Accounts"
172reference = "https://attack.mitre.org/techniques/T1078/"
173
174[[rule.threat.technique]]
175id = "T1133"
176name = "External Remote Services"
177reference = "https://attack.mitre.org/techniques/T1133/"
178
179
180[rule.threat.tactic]
181id = "TA0001"
182name = "Initial Access"
183reference = "https://attack.mitre.org/tactics/TA0001/"
184
185[rule.alert_suppression]
186group_by = ["Esql.appliance_id", "source.ip"]
187missing_fields_strategy = "suppress"
188
189[rule.alert_suppression.duration]
190unit = "m"
191value = 15