When SonicWall CVE-2024-40766 was added to CISA’s Known Exploited Vulnerabilities catalog in August 2024, organisations got until September 30 to remediate. Most applied the firmware patch and marked it done. A SANS Internet Storm Center audit published today reviewed 14 of those patched devices. Akira and Fog ransomware operators had been inside several of them long after the patch window closed. The firmware fix scored the right number on the dashboard. It didn’t fix the organisation.
What the Patch Actually Does
SonicWall CVE-2024-40766 is an improper access control flaw in SonicOS. It affects the management interface and SSLVPN service on Gen 5, Gen 6, and Gen 7 firewalls. NIST rates it CVSS 9.8. An unauthenticated remote attacker can exploit it to gain unauthorised access, or crash the appliance in some configurations. The firmware patch closed that access control bug. Nothing else.
The problem is what attackers did before the patch landed. They created accounts. They harvested credentials. Some registered their own TOTP devices for accounts they had already compromised. A firmware update does not undo any of that.
The Persistence Problem
Twelve of 14 audited firewalls had stale local SSLVPN accounts. These included accounts for departed employees, legacy service accounts from old hardware, and some with non-printable characters in usernames. SANS flagged that last type as a likely sign of automated account creation by exploitation tooling. Those accounts survived the patch cycle because nobody checked for them.
Eleven devices had never rotated local credentials after the update. Also in September 2025, the MySonicWall platform was breached. Encrypted credentials from customer configuration backups were exposed. If those credentials were cracked, a patched firewall with unchanged passwords is still compromised.
LDAP Gives Everyone VPN Access
Nine of 14 firewalls mapped the Default LDAP User Group to a VPN-enabled group. This is a common leftover from default setup guides. The result: every Active Directory account with valid credentials gets implicit SSLVPN access. That includes contractors, receptionists, and monitoring service accounts. It includes accounts for staff who left months ago and were never fully deprovisioned in AD.
However, patching CVE-2024-40766 does nothing about this. The LDAP setting was wrong before the vulnerability was disclosed, still wrong when the patch was applied, and wrong now.
The TOTP Enrollment Problem
Half the devices in the SANS audit had the Virtual Office TOTP enrollment portal reachable from the internet. An attacker with valid credentials can go to that portal and enroll their own TOTP device. They are not breaking MFA. Instead, they are configuring it for themselves before the legitimate user gets there.
The result: MFA shows as enabled and compliant on the dashboard, while providing no real barrier to someone who obtained credentials during an earlier window.
Gen 6 Has No Patch Path
Gen 6 SonicWall hardware reached end-of-life in April 2026. A separate MFA bypass, CVE-2024-12802, is present on Gen 6 and requires six manual LDAP remediation steps from SonicWall advisory SNWLID-2025-0001. Firmware version alone does not confirm remediation. Yet all Gen 6 devices in the SANS sample lacked those steps. There will be no further firmware fixes for Gen 6.
The Australian Cyber Security Centre published an advisory on the ongoing campaign. The Canadian Centre for Cyber Security followed. Both confirmed active exploitation on patched devices.
The Deeper Issue
Patch compliance metrics count deployments. They do not count credential rotations, account reconciliations, or portal access restrictions. Most vulnerability management programmes treat the firmware update as the end state. This is a recurring failure on perimeter devices. SonicWall CVE-2024-40766 is one example. The pattern repeats across every major VPN and firewall platform. The patch is necessary. But remediating the vulnerability requires the cleanup that follows.
Arctic Wolf reported Akira deploying ransomware within an hour of SSLVPN access on patched devices. The entry point was not an unpatched bug. Rather, it was a valid account that should have been deleted months earlier.
The SANS checklist covers account audit, credential rotation, LDAP group reconfiguration, portal access restriction, ASN-based IP filtering, and session monitoring. Most of that work does not appear in a patch management tool. So that is the gap Akira is using.
What to Check on Your SonicWall Now
If your device was affected by SonicWall CVE-2024-40766 and you applied the patch, these are the steps SANS identified as most likely to stop active intrusions:
- Audit local accounts. Pull every local SSLVPN account and cross-check it against your current HR roster. Remove accounts for departed staff and legacy service accounts. Flag any username with non-printable characters for immediate deletion.
- Rotate all credentials. Change local firewall account passwords, the LDAP bind account password, and any Active Directory passwords for accounts that held SSLVPN rights during the exploitation window.
- Reconfigure the Default LDAP User Group. Assign it to a local group with no service access. Then grant SSLVPN rights explicitly only to the groups that need them.
- Restrict the Virtual Office portal. Move TOTP enrollment behind internal IP ranges or a VPN-connected source. If public enrollment is unavoidable, monitor all enrollment events.
- Upgrade to SonicOS 7.3.0 or later. This version adds brute-force detection and improved MFA controls that reduce exposure to credential-stuffing. For Gen 6 hardware, also complete all six LDAP steps from advisory SNWLID-2025-0001.
Because log storage on default-configured SonicWall devices is limited, evidence of intrusion may already be gone. So forwarding logs to an external SIEM or aggregator is not optional if you want visibility into whether any of these gaps were already exploited.
