In an audit of 14 SonicWall firewalls that all had the CVE-2024-40766 patch applied, 12 still had stale local SSLVPN accounts - and 11 had never rotated passwords after the firmware upgrade. The patch fixed the access control bug. It did not fix the mess left behind.
Stale Accounts and Passwords Nobody Changed
Manuel Humberto Santander Peláez at SANS ISC audited 14 SonicWall firewalls across multiple organizations. Every device had the CVE-2024-40766 patch installed. The results are not pretty. 12 of 14 firewalls had SSLVPN accounts that did not exist in Active Directory. Some were legacy service accounts from Gen 6 migrations. Some were accounts for employees who left years ago. A few had usernames with non-printable characters - null bytes in the username, a hallmark of automated exploitation tooling creating backdoor accounts.
Worse: 11 of 14 firewalls had not rotated local account passwords after the firmware upgrade. The same credentials that may have been exposed through the MySonicWall backup breach or the vulnerability itself were still valid. An attacker who collected them six months ago can log in today. No source-IP restrictions existed on 10 of the 14 firewalls. No geo-IP filtering. No ASN blocking. Legitimate remote workers connect from residential ISPs; attackers connect from VPS hosting providers.
The LDAP Default User Group Trap
The most dangerous misconfiguration lived in the LDAP authentication settings. SonicWall firewalls have a setting called the Default LDAP User Group. Every user who authenticates via LDAP is automatically added to this group, on top of whatever AD groups they belong to. If that default group has SSLVPN Services access, then every single Active Directory account with valid credentials can connect to the VPN. The receptionist. The warehouse operator. The service account nobody monitors. The contractor who left two years ago but whose AD account never got disabled.
We found this misconfiguration in 9 of 14 firewalls. In one case the Default LDAP User Group was mapped to a group that granted both SSLVPN access and administrative rights to the firewall management interface. Any compromised AD credential from any source gives the attacker a VPN tunnel and admin control of the perimeter device. SonicWall published a knowledge base article on this risk in August 2025, but guidance is not a patch. The fix is manual: create a dedicated local group with no service access, set it as the default, then assign SSLVPN permissions explicitly.
The Virtual Office Portal Bypass
Half of the audited firewalls had the SonicWall Virtual Office Portal - the web interface where users configure MFA and TOTP tokens - reachable from the internet with no authentication gate. If an attacker has valid credentials and the portal is public, they do not need to break MFA. They simply enroll their own TOTP device for that account. Multiple Akira intrusions bypassed MFA this way; the attacker never cracked the second factor, they set it up themselves.
The fix is a single access rule restricting the portal to internal network addresses or VPN-connected sources. It takes minutes. But it requires knowing the portal exists, and most administrators we spoke with did not know it was publicly exposed.
Sessions That Never Died
On every audited firewall Santander exported SSLVPN session data for the 30-day window after the patch was applied. Legitimate user sessions clustered at business hours from residential ISP ranges. Then there were the orange diamonds: sessions from VPS and hosting provider ASNs, starting during off-hours, some running 40 to 60 hours. No legitimate employee connects to a corporate VPN from a cloud hosting provider for two days straight.
The red squares were the worst - sessions on stale local accounts that had been disabled in AD more than a year before the patch. Those accounts still existed as local firewall users. They authenticated successfully. They stayed connected for four to seven days. The patch did not terminate them. The patch did not disable the accounts. It fixed the access control flaw and left everything else untouched.
What Actual Remediation Looks Like
One representative firewall had 23 local SSLVPN accounts. Six were legitimate. The other 17 were stale, orphaned, or unexplained. The LDAP Default User Group granted implicit SSLVPN access to 147 AD accounts; after reconfiguring, that dropped to 28 who actually needed VPN access. All 19 accounts without MFA enforced were either removed or had MFA turned on. Seven active sessions longer than 24 hours were terminated. Three exposed admin interfaces were restricted to a management VLAN.
The patch took five minutes. The cleanup took an afternoon. That afternoon is the gap between a firewall that shows as patched in a vulnerability scanner and one that is actually hardened against threat actors who know exactly what post-patch misconfigurations to look for.
The Bottom Line for Any SonicWall Operator
Akira and Fog operators are not scanning for unpatched firewalls anymore. They are scanning for patched firewalls where nobody completed the post-patch steps. A patched SonicWall with 17 stale local accounts and an overpermissive LDAP default group is not remediated - it is a device with newer firmware and the same attack surface. If you run SonicWall with SSLVPN, applied the CVE-2024-40766 patch, and did nothing else, you did Step 1. Now do Step 2: reconcile accounts, fix the LDAP group, rotate passwords, restrict the Virtual Office Portal, terminate stale sessions, and upgrade to SonicOS 7.3.0 or later. For Gen 6 devices, complete all six LDAP remediation steps from SNWLID-2025-0001 - firmware version alone does not confirm remediation. Gen 6 reached end-of-life in April 2026. Start planning your migration. The patch closed the bug. Now close the configuration gaps that the bug left behind.
Source: CVE-2024-40766: The Patch Fixed the Bug. Nobody Fixed the Configuration., (Tue, Jun 23rd)
Domain: isc.sans.edu
Comments load interactively on the live page.