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
- Multiple SonicWall Login Failures Followed by Successful Login
- M365 Identity Login from Atypical Region
- Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN
- Entra ID Multiple Device Registrations by a Single User
- Microsoft Entra ID Impossible Travel Sign-in