Multiple SonicWall Login Failures Followed by Successful Login

[metadata]
creation_date = "2026/07/31"
integration = ["sonicwall_firewall"]
maturity = "production"
updated_date = "2026/07/31"

[rule]
author = ["Elastic"]
description = """
Identifies multiple failed SonicWall authentication attempts against several user accounts from one source IP, followed
by a successful remote-access login from the same source to the same appliance. This may indicate successful password
spraying, credential stuffing, or password guessing.
"""
false_positives = [
    """
    Shared egress addresses, managed service providers, help desks, identity-provider outages, password rotation, or
    several legitimate users entering incorrect credentials before another user successfully authenticates may trigger
    this rule. Add exceptions only for confirmed shared-service sources and scope them to the relevant appliance.
    """,
]
from = "now-15m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Multiple SonicWall Login Failures Followed by Successful Login"
note = """## Triage and analysis

### Investigating Multiple SonicWall Login Failures Followed by Successful Login

This 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.

Failure 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.

### Possible investigation steps

- 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.
- 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.
- Review `Esql.failure_event_codes` and `Esql.success_event_codes` to distinguish administrator, remote-user, SSL VPN, LDAP, RADIUS, and lockout activity.
- 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.
- Confirm whether MFA was required and completed for each successful authentication.
- Correlate successful VPN sessions with assigned tunnel IPs, internal authentication, DNS, network flow, and endpoint activity. For administrator logins, review subsequent SonicWall configuration changes.

### False positive analysis

- Several users behind a shared public address may enter incorrect credentials while another user authenticates.
- Password rotation, expired cached credentials, LDAP or RADIUS issues, help-desk testing, and synthetic monitoring can generate failure-to-success patterns.
- 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.

### Response and remediation

- If unauthorized access is suspected, disable affected accounts, terminate active sessions, reset credentials, revoke tokens or keys, and enforce MFA.
- Block or restrict the source at the SonicWall appliance while investigating.
- Review configuration changes and downstream activity from successful VPN sessions. Isolate affected systems and begin incident response if post-authentication activity is identified.
- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes.
"""
references = [
    "https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign",
    "https://www.elastic.co/docs/reference/integrations/sonicwall_firewall",
    "https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM",
]
risk_score = 73
rule_id = "efe7ac71-3b13-41cf-8263-30af68ce3f19"
setup = """## Setup

This rule requires the Elastic **SonicWall Firewall** integration and SonicWall Enhanced Syslog authentication events.

Configure the appliance to forward **Users > Authentication Access** and **Users > RADIUS Authentication** events.
Confirm that credential failure event codes `30`, `32`, `33`, `200`, `243`, `329`, `745`, `749`, and `1655`, and
successful remote-access event codes `235`, `236`, `237`, `238`, and `1080`, are collected. Verify that the integration
populates `data_stream.dataset`, `event.action`, `event.code`, `source.ip`, `user.name`, and either
`observer.serial_number` or a unique `observer.name`.

If several customers share one Kibana space, ensure the appliance identity is unique per tenant so activity from
different customers is not aggregated together.
"""
severity = "high"
tags = [
    "Domain: Network",
    "Domain: Identity",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Tactic: Initial Access",
    "Data Source: SonicWall",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-sonicwall_firewall.log-*
| where
    data_stream.dataset == "sonicwall_firewall.log" and
    (
      (
        event.action == "login-failure" and
        event.code in ("30", "32", "33", "200", "243", "329", "745", "749", "1655")
      ) or (
        event.action == "login-success" and
        event.code in ("235", "236", "237", "238", "1080")
      )
    ) and
    source.ip is not null and
    user.name is not null and
    (observer.serial_number is not null or observer.name is not null)
| eval
    Esql.appliance_id = coalesce(observer.serial_number, observer.name),
    Esql.is_failure = case(event.action == "login-failure", 1, 0),
    Esql.is_success = case(event.action == "login-success", 1, 0),
    Esql.failed_user = case(event.action == "login-failure", user.name, null),
    Esql.successful_user = case(event.action == "login-success", user.name, null),
    Esql.failure_event_code = case(event.action == "login-failure", event.code, null),
    Esql.success_event_code = case(event.action == "login-success", event.code, null),
    Esql.failure_timestamp = case(event.action == "login-failure", @timestamp, null),
    Esql.success_timestamp = case(event.action == "login-success", @timestamp, null)
| stats
    Esql.failed_logins = sum(Esql.is_failure),
    Esql.successful_logins = sum(Esql.is_success),
    Esql.failed_user_count = count_distinct(Esql.failed_user),
    Esql.failed_user_names = values(Esql.failed_user),
    Esql.successful_user_names = values(Esql.successful_user),
    Esql.failure_event_codes = values(Esql.failure_event_code),
    Esql.success_event_codes = values(Esql.success_event_code),
    Esql.first_failure = min(Esql.failure_timestamp),
    Esql.last_failure = max(Esql.failure_timestamp),
    Esql.first_success = min(Esql.success_timestamp),
    Esql.last_success = max(Esql.success_timestamp)
  by Esql.appliance_id, source.ip
| where
    Esql.failed_logins >= 5 and
    Esql.failed_user_count >= 3 and
    Esql.successful_logins >= 1 and
    Esql.first_failure < Esql.last_success
| eval Esql.failure_to_success_seconds = date_diff("seconds", Esql.first_failure, Esql.last_success)
| sort Esql.failed_user_count desc, Esql.failed_logins desc
| keep source.ip, Esql.*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.001"
name = "Password Guessing"
reference = "https://attack.mitre.org/techniques/T1110/001/"

[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

[[rule.threat.technique.subtechnique]]
id = "T1110.004"
name = "Credential Stuffing"
reference = "https://attack.mitre.org/techniques/T1110/004/"



[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique]]
id = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"


[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[rule.alert_suppression]
group_by = ["Esql.appliance_id", "source.ip"]
missing_fields_strategy = "suppress"

[rule.alert_suppression.duration]
unit = "m"
value = 15