First Seen SonicWall Remote Access Login by User and Source

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/08/21"
  3integration = ["sonicwall_firewall"]
  4maturity = "production"
  5updated_date = "2026/08/21"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a successful SonicWall VPN- or WAN-zone administrator or remote-user login from a source IP that was not
 11previously observed with the same user on the same appliance during the prior 14 days. This may indicate stolen
 12credentials, compromised administrator access, or unauthorized remote access.
 13"""
 14false_positives = [
 15    """
 16    New administrators or VPN users, travel, mobile networks, ISP address rotation, managed service providers, and first
 17    observations after integration onboarding or retention loss can trigger this rule.
 18    """,
 19]
 20from = "now-9m"
 21index = ["logs-sonicwall_firewall.log-*"]
 22interval = "5m"
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "First Seen SonicWall Remote Access Login by User and Source"
 26note = """## Triage and analysis
 27
 28### Investigating First Seen SonicWall Remote Access Login by User and Source
 29
 30This rule detects a newly observed combination of SonicWall appliance serial number, user name, and source IP for a
 31successful VPN- or WAN-zone login. Event IDs `235` and `236` are administrator logins from VPN and WAN zones, `237` and
 32`238` are remote-user logins from VPN and WAN zones, and `1080` is a successful SSL VPN user login.
 33
 34### Possible investigation steps
 35
 36- Confirm the user, source IP, appliance, login type, VPN policy, MFA result, and assigned tunnel address.
 37- Review the source geolocation, reputation, and prior authentication activity.
 38- Correlate with failed logins, configuration changes, internal reconnaissance, and endpoint activity.
 39- Prefer exceptions scoped to the appliance, user, and expected source rather than globally excluding an identity.
 40
 41### False positive analysis
 42
 43- Validate new users, travel, ISP address changes, managed service provider activity, and integration onboarding before
 44  treating the alert as unauthorized access.
 45
 46### Response and remediation
 47
 48- If unauthorized access is suspected, terminate active sessions, disable the affected account, rotate credentials and
 49  tokens, verify MFA, and review downstream activity from the assigned tunnel address.
 50- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes.
 51"""
 52references = [
 53    "https://www.elastic.co/docs/reference/integrations/sonicwall_firewall",
 54    "https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM",
 55    "https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign",
 56]
 57risk_score = 47
 58rule_id = "7df97e5b-1722-4305-80c7-7a203f2ff36e"
 59setup = """## Setup
 60
 61This rule requires the Elastic SonicWall Firewall integration and SonicWall Enhanced Syslog authentication events.
 62Configure the appliance to forward **Users > Authentication Access** events, including event IDs `235`, `236`, `237`,
 63`238`, and `1080`. Verify that the integration populates `data_stream.dataset`, `event.action`, `event.code`,
 64`source.ip`, `user.name`, and `observer.serial_number`.
 65
 66The new-terms key requires `observer.serial_number`. Events without that field do not match. Ensure serial numbers are
 67stable and unique across tenants in a shared Kibana space.
 68"""
 69severity = "medium"
 70tags = [
 71    "Domain: Network",
 72    "Domain: Identity",
 73    "Use Case: Threat Detection",
 74    "Use Case: Identity and Access Audit",
 75    "Tactic: Initial Access",
 76    "Data Source: SonicWall Firewall Logs",
 77    "Rule Type: New Terms",
 78    "Resources: Investigation Guide",
 79]
 80timestamp_override = "event.ingested"
 81type = "new_terms"
 82
 83query = '''
 84data_stream.dataset:"sonicwall_firewall.log" and
 85  event.action:"login-success" and
 86  event.code:("235" or "236" or "237" or "238" or "1080") and
 87  source.ip:* and user.name:* and observer.serial_number:*
 88'''
 89
 90
 91[[rule.threat]]
 92framework = "MITRE ATT&CK"
 93[[rule.threat.technique]]
 94id = "T1078"
 95name = "Valid Accounts"
 96reference = "https://attack.mitre.org/techniques/T1078/"
 97
 98[[rule.threat.technique]]
 99id = "T1133"
100name = "External Remote Services"
101reference = "https://attack.mitre.org/techniques/T1133/"
102
103
104[rule.threat.tactic]
105id = "TA0001"
106name = "Initial Access"
107reference = "https://attack.mitre.org/tactics/TA0001/"
108
109[rule.investigation_fields]
110field_names = [
111    "@timestamp",
112    "message",
113    "event.code",
114    "event.action",
115    "event.outcome",
116    "source.ip",
117    "source.port",
118    "source.geo.country_iso_code",
119    "user.name",
120    "observer.serial_number",
121    "observer.name",
122    "observer.ip",
123    "sonicwall.firewall.vpnpolicy",
124    "sonicwall.firewall.vpnpolicyDst",
125]
126
127[rule.new_terms]
128field = "new_terms_fields"
129value = ["observer.serial_number", "user.name", "source.ip"]
130[[rule.new_terms.history_window_start]]
131field = "history_window_start"
132value = "now-14d"

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.

References

Related rules

to-top