« First Occurrence of User-Agent For a GitHub User First Time AWS CloudFormation Stack Creation »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

First Seen SonicWall Remote Access Login by User and Source

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

First Seen SonicWall Remote Access Login by User and Source

edit

Identifies a successful SonicWall VPN- or WAN-zone administrator or remote-user login from a source IP that was not previously observed with the same user on the same appliance during the prior 14 days. This may indicate stolen credentials, compromised administrator access, or unauthorized remote access.

Rule type: new_terms

Rule indices:

  • logs-sonicwall_firewall.log-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (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: Initial Access
  • Data Source: SonicWall Firewall Logs
  • Rule Type: New Terms
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating First Seen SonicWall Remote Access Login by User and Source

This rule detects a newly observed combination of SonicWall appliance serial number, user name, and source IP for a successful VPN- or WAN-zone login. Event IDs 235 and 236 are administrator logins from VPN and WAN zones, 237 and 238 are remote-user logins from VPN and WAN zones, and 1080 is a successful SSL VPN user login.

Possible investigation steps

  • Confirm the user, source IP, appliance, login type, VPN policy, MFA result, and assigned tunnel address.
  • Review the source geolocation, reputation, and prior authentication activity.
  • Correlate with failed logins, configuration changes, internal reconnaissance, and endpoint activity.
  • Prefer exceptions scoped to the appliance, user, and expected source rather than globally excluding an identity.

False positive analysis

  • Validate new users, travel, ISP address changes, managed service provider activity, and integration onboarding before treating the alert as unauthorized access.

Response and remediation

  • If unauthorized access is suspected, terminate active sessions, disable the affected account, rotate credentials and tokens, verify MFA, and review downstream activity from the assigned tunnel address.
  • 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 events, including event IDs 235, 236, 237, 238, and 1080. Verify that the integration populates data_stream.dataset, event.action, event.code, source.ip, user.name, and observer.serial_number.

The new-terms key requires observer.serial_number. Events without that field do not match. Ensure serial numbers are stable and unique across tenants in a shared Kibana space.

Rule query

edit
data_stream.dataset:"sonicwall_firewall.log" and
  event.action:"login-success" and
  event.code:("235" or "236" or "237" or "238" or "1080") and
  source.ip:* and user.name:* and observer.serial_number:*

Framework: MITRE ATT&CKTM

« First Occurrence of User-Agent For a GitHub User First Time AWS CloudFormation Stack Creation »