Multiple SonicWall Login Failures Followed by Successful Login

  1[metadata]
  2creation_date = "2026/07/31"
  3integration = ["sonicwall_firewall"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  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    "Noise: Unknown",
 87    "Performance: Fast",
 88    "Rule Type: ES|QL",
 89    "Data Source: SonicWall Firewall Logs",
 90]
 91timestamp_override = "event.ingested"
 92type = "esql"
 93
 94query = '''
 95from logs-sonicwall_firewall.log-*
 96| where
 97    data_stream.dataset == "sonicwall_firewall.log" and
 98    (
 99      (
100        event.action == "login-failure" and
101        event.code in ("30", "32", "33", "200", "243", "329", "745", "749", "1655")
102      ) or (
103        event.action == "login-success" and
104        event.code in ("235", "236", "237", "238", "1080")
105      )
106    ) and
107    source.ip is not null and
108    user.name is not null and
109    (observer.serial_number is not null or observer.name is not null)
110| eval
111    Esql.appliance_id = coalesce(observer.serial_number, observer.name),
112    Esql.is_failure = case(event.action == "login-failure", 1, 0),
113    Esql.is_success = case(event.action == "login-success", 1, 0),
114    Esql.failed_user = case(event.action == "login-failure", user.name, null),
115    Esql.successful_user = case(event.action == "login-success", user.name, null),
116    Esql.failure_event_code = case(event.action == "login-failure", event.code, null),
117    Esql.success_event_code = case(event.action == "login-success", event.code, null),
118    Esql.failure_timestamp = case(event.action == "login-failure", @timestamp, null),
119    Esql.success_timestamp = case(event.action == "login-success", @timestamp, null)
120| stats
121    Esql.failed_logins = sum(Esql.is_failure),
122    Esql.successful_logins = sum(Esql.is_success),
123    Esql.failed_user_count = count_distinct(Esql.failed_user),
124    Esql.failed_user_names = values(Esql.failed_user),
125    Esql.successful_user_names = values(Esql.successful_user),
126    Esql.failure_event_codes = values(Esql.failure_event_code),
127    Esql.success_event_codes = values(Esql.success_event_code),
128    Esql.first_failure = min(Esql.failure_timestamp),
129    Esql.last_failure = max(Esql.failure_timestamp),
130    Esql.first_success = min(Esql.success_timestamp),
131    Esql.last_success = max(Esql.success_timestamp)
132  by Esql.appliance_id, source.ip
133| where
134    Esql.failed_logins >= 5 and
135    Esql.failed_user_count >= 3 and
136    Esql.successful_logins >= 1 and
137    Esql.first_failure < Esql.last_success
138| eval Esql.failure_to_success_seconds = date_diff("seconds", Esql.first_failure, Esql.last_success)
139| sort Esql.failed_user_count desc, Esql.failed_logins desc
140| keep source.ip, Esql.*
141'''
142
143
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146[[rule.threat.technique]]
147id = "T1110"
148name = "Brute Force"
149reference = "https://attack.mitre.org/techniques/T1110/"
150[[rule.threat.technique.subtechnique]]
151id = "T1110.001"
152name = "Password Guessing"
153reference = "https://attack.mitre.org/techniques/T1110/001/"
154
155[[rule.threat.technique.subtechnique]]
156id = "T1110.003"
157name = "Password Spraying"
158reference = "https://attack.mitre.org/techniques/T1110/003/"
159
160[[rule.threat.technique.subtechnique]]
161id = "T1110.004"
162name = "Credential Stuffing"
163reference = "https://attack.mitre.org/techniques/T1110/004/"
164
165
166
167[rule.threat.tactic]
168id = "TA0006"
169name = "Credential Access"
170reference = "https://attack.mitre.org/tactics/TA0006/"
171[[rule.threat]]
172framework = "MITRE ATT&CK"
173[[rule.threat.technique]]
174id = "T1078"
175name = "Valid Accounts"
176reference = "https://attack.mitre.org/techniques/T1078/"
177
178[[rule.threat.technique]]
179id = "T1133"
180name = "External Remote Services"
181reference = "https://attack.mitre.org/techniques/T1133/"
182
183
184[rule.threat.tactic]
185id = "TA0001"
186name = "Initial Access"
187reference = "https://attack.mitre.org/tactics/TA0001/"
188
189[rule.alert_suppression]
190group_by = ["Esql.appliance_id", "source.ip"]
191missing_fields_strategy = "suppress"
192
193[rule.alert_suppression.duration]
194unit = "m"
195value = 15