SonicWall CVE-2024-40766: why patched firewalls keep falling to Akira and Fog

Background. CVE-2024-40766 is an improper-access-control flaw (vendor advisory SNWLID-2024-0015, CVSS 9.3) in the SonicOS management interface and SSLVPN across Gen 5/6/7 SonicWall firewalls, with patches available since August 2024. Through late 2025 it became one of the most reliable ransomware on-ramps in the field: Arctic Wolf documented an aggressive Akira campaign that used compromised SSLVPN credentials tied to the CVE to reach full ransomware deployment in an hour or less (Arctic Wolf, 2025-09-26). Nearly a year after the patch, the same device class keeps appearing in Akira and Fog intrusions — which is the puzzle a fresh SANS Internet Storm Center diary (2026-06-23) sets out to explain (SANS ISC, 2026-06-23).

The mechanism is post-patch residue, not an unpatched bug. The SANS ISC analysis makes the operationally important point explicit: organisations apply the firmware update but never complete the hardening that the update assumes, so the access paths the intrusions ride survive the patch (SANS ISC, 2026-06-23). SANS ISC further notes that on Gen 6 devices the firmware update alone is insufficient: a related SSLVPN MFA-bypass weakness (CVE-2024-12802) needs manual LDAP reconfiguration to close. Four residual misconfigurations recur:

• Stale local accounts created during initial device setup that were never removed and whose passwords were never rotated — including after the CVE-2024-40766 patch, even though the flaw's impact is precisely unauthorised access to such accounts.
• LDAP "Default Group" with implicit SSLVPN access, which silently grants VPN rights to potentially hundreds of Active Directory accounts without the administrator realising the membership scope.
• Unenforced or misconfigured MFA on the SSLVPN portal, so a single valid credential is sufficient.
• A publicly reachable Virtual Office Portal (the SSLVPN self-service / MFA-enrolment page), which exposes credential-stuffing and self-enrolment attack surface to the internet.

Kill chain. The pattern maps cleanly: initial access via valid SSLVPN credentials (T1133 External Remote Services, T1133) using stolen or stale T1078 Valid Accounts (T1078) — frequently T1078.002 Domain Accounts (T1078.002) when the LDAP default-group grant pulls AD identities into the VPN scope — followed by rapid lateral movement and Akira/Fog encryption (T1486 Data Encrypted for Impact, T1486). Arctic Wolf's "deploys ransomware in an hour or less" framing is the operational tempo to plan against: there is little dwell time in which to react once the VPN foothold is established.

Why it matters to us. SonicWall is a common branch-office and SMB perimeter firewall across Swiss cantonal/communal IT, healthcare and education networks — the exact mid-market public-sector estate this brief serves, and the kind of environment where a device was patched in 2024, ticket closed, and never revisited. The defender lesson generalises beyond SonicWall: applying a firewall patch for an access-control CVE does not rotate the credentials the CVE may already have exposed, nor does it close the misconfigurations that let a single credential become VPN access.

Detection concepts (no IOCs). Review SonicOS SSLVPN authentication logs (the SSLVPN auth events; SonicOS exposes these via syslog) for logons from stale/rarely-used local accounts and for sessions authenticated through LDAP groups that have not been recently reviewed; alert on Virtual Office Portal access from external source addresses; and aggregate SSLVPN login events into the SIEM so brute-force and credential-stuffing bursts are visible. Because the endgame is ransomware, pair perimeter telemetry with host detections for mass file-rename / encryption behaviour on file servers.

Hardening / mitigation. Per the SANS ISC and vendor guidance: upgrade to firmware 7.3.0+; rotate every SonicWall account password after patching (treat the CVE as a credential-exposure event, not just a code fix); enforce MFA on all SSLVPN users, explicitly including those whose access derives from an LDAP default-group membership; audit the LDAP Default Group and remove implicit SSLVPN grants; restrict the Virtual Office Portal to internal networks only; and enable logging for all SSLVPN login attempts.