How to Audit Your SonicWall Exposure After the Latest Zero-Day Exploits

The public report is enough to justify immediate work: SonicWall customers are being targeted with two zero-days, and edge appliances are one of the few system classes where a small initial bug can turn into broad network access.

My view is straightforward: this is not a patch-and-move-on event. You need an exposure review. If the device sits on the internet, brokers VPN, or exposes admin access, I would treat it as sensitive infrastructure until I had inventoried it, checked it for abuse, and preserved evidence.

Why this SonicWall zero-day alert deserves immediate attention

A firewall or VPN appliance is not like a single internal app. It sits on the trust boundary, handles authentication traffic, and often stores enough configuration to make follow-on movement easier if it is compromised.

That is why the response should look different from ordinary patching:

• a patched box can still be the point of initial compromise
• a compromised box can hide the attacker behind a trusted IP
• config backups, auth secrets, and session state can matter as much as the binary version

If you run SonicWall at the edge, assume the blast radius includes both the appliance and anything behind it.

What the public reporting confirms, and what it does not

What I can confirm from the source material is narrow but important:

• public reporting says attackers are exploiting two zero-days against SonicWall customers
• the event is current, not historical
• the reporting is about SonicWall customers and deployed devices, not a theoretical lab issue

What I cannot confirm from the material I have is just as important:

• the specific CVE IDs are not provided here
• the exact affected firmware versions are not provided here
• the exact exploit path is not provided here
• whether the exploit needs authentication is not provided here
• whether every SonicWall model is affected is not provided here

So I would not guess. I would verify against the vendor advisory and my own inventory. If your team is already circulating rumors about “the” affected version, slow that down. In incidents like this, precision matters more than speed theater.

Build an exposure inventory before you touch the appliance

Before rebooting, patching, or changing policy, write down exactly what you have. I usually want one table with device identity, role, version, and exposure state.

Identify every SonicWall device, model, and firmware version

Start from the sources of truth you already have:

• CMDB or asset inventory
• network diagrams that are not stale
• cloud and edge IP allowlists
• configuration management exports
• remote access documentation

If you already keep device inventories in CSV form, the first pass can be very simple:

cut -d, -f1,2,3 sonicwall-assets.csv | column -t -s,

What I want from that list is not perfection; I want a working map of:

• hostname
• model
• firmware version
• primary public IP
• business owner
• whether the box is still supported

If you cannot answer those in ten minutes, that is already a finding.

Separate internet-facing edge boxes from internal management-only systems

This distinction drives priority. An appliance reachable from the internet deserves immediate attention. One reachable only from a locked-down management segment is still important, but it is not the first fire to put out.

A quick external check from a clean network segment helps. Use a range you own and a port list that matches your environment:

nmap -Pn -sV -p 80,443,8443,10443,5000,5001 203.0.113.0/28

Look for anything that resembles management, VPN, or administrative access. An example of the kind of result that matters looks like this:

PORT     STATE SERVICE VERSION
443/tcp  open  https
5001/tcp open  commplex-link

The exact banner will vary. The point is to identify which boxes answer from the public side and whether they expose more than they should.

Map which services are exposed: VPN, admin UI, logging, and APIs

On the appliance and in your perimeter controls, make a list of every service that can be reached remotely:

• SSL VPN or remote access portals
• admin web UI
• SSH or CLI management, if enabled
• syslog or log-forwarding interfaces
• any API or integration endpoint you expose for automation

I would also note whether those services are:

• internet-facing
• reachable only from a VPN
• reachable only from an internal admin network
• disabled but still present in config backups

That last one matters because stale config often becomes the source of surprise later.

Quick checks to decide whether you are exposed

Verify firmware against the vendor advisory and your change records

Do not rely on memory. Pull the firmware version from the device, then compare it with:

• the vendor advisory
• your last approved change ticket
• the maintenance window notes
• any support case history tied to the appliance

If the version is unknown, treat that as an exposure gap. If the device is outside a supported branch, I would treat that as a separate risk even if the zero-day turns out not to apply directly.

Check external reachability from a clean network segment

Use a system that is outside your corporate network and outside the appliance’s own management path. You want to know what a stranger can see.

A simple check is enough:

curl -vk https://<public-ip-or-name>/

What you are looking for is not just a web page. You are looking for:

• any response at all
• certificate subject and hostname mismatch
• redirects into a login portal
• banner strings that identify the product
• ports that respond when they should not

If the device answers from the internet and you did not intend that, you already have a hardening task even if you never find evidence of abuse.

Confirm whether remote access, management, or portal features are enabled

A lot of exposure comes from features that were enabled for convenience and never revisited.

Check:

• remote administration
• VPN portals for employees or vendors
• legacy management interfaces
• test or staging access that was temporarily opened and forgotten
• any rule that allows broad access from “any” source

If a feature is not needed, disable it. If it is needed, restrict it to a narrow allowlist and a separate admin path.

Hunting for signs of exploitation

Look for unusual logins, failed auth bursts, and impossible source locations

I would start with the logs that show who authenticated, from where, and when.

Suspicious patterns include:

• login success from a source country or ASN you never use
• repeated failures followed by a success
• logins outside business hours
• admin logins from a non-admin network
• a familiar username from a new source IP or user agent

If you forward logs to a SIEM, write detections around those patterns first. A rough grep-style search on exported logs might look like this:

grep -Ei 'login|auth|failed|success|admin|vpn' sonicwall-logs.txt | tail -n 200

That is not a full investigation, but it will surface the obvious noise quickly.

Review recent configuration changes, new accounts, and policy edits

The second thing I check is the change trail. If an attacker got in, they often leave one of these behind:

• a new local admin account
• a modified VPN policy
• a firewall rule that opens a path inward
• DNS or routing changes
• a new certificate or trust anchor
• scheduled exports or backups of the configuration

Compare the current config to the last known-good backup. If you have no last known-good backup, that is another problem to fix after the incident.

Inspect outbound connections and persistence on adjacent systems

The appliance itself may not tell the whole story. Look at the systems it touches:

• VPN concentrators
• RADIUS or SSO providers
• directory services
• jump hosts
• monitoring systems that receive admin alerts

I would check whether any of those systems saw:

• new sessions immediately after the suspected compromise window
• authentication from the firewall’s management IP at odd hours
• outbound connections to unfamiliar destinations
• new scheduled tasks or service changes on adjacent hosts

If the appliance was used as a staging point, the next move is often lateral, not noisy.

Containment steps I would take first

Isolate the most exposed devices

If the device is internet-facing and you suspect compromise, narrow exposure first:

• remove public access where business allows it
• restrict admin access to a jump host or VPN
• block management from broad source ranges
• keep emergency access paths documented

The goal is to reduce attacker access without destroying evidence.

Rotate credentials, revoke sessions, and reset shared secrets

Assume that anything the device could have seen may be exposed:

• local admin credentials
• VPN user passwords
• API tokens
• RADIUS or LDAP bind secrets
• shared certificates or pre-shared keys
• backup credentials stored in the appliance

Revoke active sessions where possible. If the appliance integrates with SSO, verify that expired sessions are truly dead and not just visually logged out.

Preserve logs and exports before rebuilding anything

Before a rebuild or firmware flash, preserve:

• full audit and authentication logs
• config backups
• support bundles
• evidence of running version and build date
• screenshots or text copies of unusual admin state, if any

If you hand this to an incident responder later, they will want the sequence of events, not just a fresh device.

Defensive hardening after the emergency window

Reduce attack surface with management restrictions and allowlists

Once the immediate risk is handled, I would make management boring:

• allow admin access only from dedicated source IPs
• move management to a separate network segment
• disable anything you do not actively use
• avoid exposing admin UI to the general internet
• review port forwards and NAT rules that accidentally expose services

This is basic work, but it is the kind that prevents a repeat.

Require MFA and separate admin access from normal user access

Do not let regular user access and admin access blur together.

Use:

• MFA for remote access
• separate admin accounts from daily user accounts
• separate admin network paths from user VPN paths
• a change process for privilege elevation

If a compromise does happen later, this makes the blast radius much smaller.

Keep firmware and backup config baselines current

The post-incident habit I care about most is disciplined baseline management:

• keep a current config backup
• record the firmware version after every change
• store a last-known-good copy offline
• track which features are enabled in each device class
• re-check supported status quarterly

That baseline is what lets you answer, quickly, whether a later advisory matters to you.

A practical triage checklist you can run today

If any row is “unknown,” I would treat the device as still exposed.

Conclusion: treat this as an exposure review, not just a patch job

My view is that a SonicWall zero-day event like this should trigger three questions at once: what is exposed, what changed, and what evidence exists. If you only patch, you can miss the part that matters most: whether the device was already used as a foothold.

The practical order is:

1. inventory the devices
2. confirm reachability
3. look for signs of abuse
4. contain the most exposed systems
5. rotate secrets
6. then patch and harden

That sequence is boring, but it is the right kind of boring for perimeter gear.

Further reading

• SonicWall Security Advisories — vendor advisories and remediation notes
• CISA Known Exploited Vulnerabilities Catalog — confirmed exploited vulnerabilities tracked by CISA
• NIST National Vulnerability Database — CVE records and reference material for verification