First Seen SonicWall Remote Access Login by User and Source
Description
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.
Query · kuery
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:*
Investigation fields
Pivot points the source recommends for triage.
@timestampmessageevent.codeevent.actionevent.outcomesource.ipsource.portsource.geo.country_iso_codeuser.nameobserver.serial_numberobserver.nameobserver.ipsonicwall.firewall.vpnpolicysonicwall.firewall.vpnpolicyDst
Implementation guide
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.
Known false positives
- New administrators or VPN users, travel, mobile networks, ISP address rotation, managed service providers, and first observations after integration onboarding or retention loss can trigger this rule.
Analyst notes
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.