Multiple SonicWall Login Failures Followed by Successful Login

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Multiple SonicWall Login Failures Followed by Successful Login

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.

Rule type: esql

Rule indices: None

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-15m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

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

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Setup

edit

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.

Rule query

edit

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

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Brute Force
- ID: T1110
- Reference URL: https://attack.mitre.org/techniques/T1110/
Sub-technique:
- Name: Password Guessing
- ID: T1110.001
- Reference URL: https://attack.mitre.org/techniques/T1110/001/
Sub-technique:
- Name: Password Spraying
- ID: T1110.003
- Reference URL: https://attack.mitre.org/techniques/T1110/003/
Sub-technique:
- Name: Credential Stuffing
- ID: T1110.004
- Reference URL: https://attack.mitre.org/techniques/T1110/004/
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Technique:
- Name: External Remote Services
- ID: T1133
- Reference URL: https://attack.mitre.org/techniques/T1133/

« First Time Seen NFS AUTH_SYS Root UID Access Cassandra JavaScript UDF Creation »