Attackers bypassed MFA on patched SonicWall Gen6 VPNs because admins missed extra manual steps required to fully fix the flaw.
There is a particular kind of security failure that is harder to catch than an unpatched system: a patched system where the patch did not actually work because nobody followed all the steps. That is what is happening right now with SonicWall Gen6 SSL-VPN appliances and CVE-2024-12802, and it has already led to ransomware-related intrusions across multiple organizations.
Between February and March 2026, ReliaQuest researchers observed what it assesses as the first in-the-wild exploitation of CVE-2024-12802 across multiple environments. The flaw is an authentication bypass in SonicWall VPNs that can reduce security to single-factor access. Although firmware updates exist for Gen6 devices, full remediation requires six additional manual steps, often missed in standard patching workflows, leaving systems exposed despite appearing fixed. Attackers then brute-forced VPN accounts, bypassed MFA, and rapidly moved inside networks, sometimes reaching file servers in under 30 minutes.
“In the intrusions we observed, threat actors brute-forced VPN accounts and bypassed MFA to gain access to internal networks. The tools observed were consistent with actors operating in the ransomware ecosystem. In some cases, as few as 13 brute-force attempts separated an attacker from a valid credential. In one environment, they reached a file server within 30 minutes and deployed tools consistent with pre-ransomware staging.” reads the post by ReliaQuest. “Intrusions left the same signal in the logs: A session type associated with automated VPN authentication that most organizations are unlikely to be monitoring today.”
The vulnerability itself, CVE-2024-12802, is stems in how SonicWall handles two different Active Directory login formats: UPN (User Principal Name, the format that looks like an email address) and SAM (Security Account Manager, the older format). MFA enforcement is applied to each login format independently, not to the user identity behind them. An attacker who knows valid credentials can authenticate using the UPN path even when MFA is configured, because the enforcement for that specific path is missing.
“Patching the firmware doesn’t remove the existing Lightweight Directory Access Protocol (LDAP) configuration that allows the bypass; the vulnerable configuration remains in place.” continues ReliaQuest. “Remediation requires deleting that configuration entirely and rebuilding it without the userPrincipalName format that the exploit relies on. SonicWall’s advisory (SNWLID-2025-0001) specifies six additional manual steps.
SonicWall documented all of this in their advisory, but standard patch management workflows are not designed to verify manual reconfiguration steps, the firmware updates, the version check passes, and the device looks fine.
“SSL-VPN MFA Bypass in SonicWALL SSL-VPN can arise in specific cases due to the separate handling of UPN (User Principal Name) and SAM (Security Account Manager) account names when integrated with Microsoft Active Directory, allowing MFA to be configured independently for each login method and potentially enabling attackers to bypass MFA by exploiting the alternative account name.” reads the advisory. “IMPORTANT: For GEN7 and GEN8 Firewalls, we have incorporated the remediation steps described in the advisory (Comments section) into versions 7.2.0-7015 and 8.0.1-8017. These versions also include additional security enhancements. After upgrading the firewall to the specified version, the use of userPrincipalName in LDAP server configurations is once again supported.
For Gen7 and Gen8 devices, this is not a problem. A firmware update is enough. The issue is specific to Gen6 hardware, which also hit end-of-life on April 16 this year and no longer receives security updates — a detail that makes the remediation conversation even more urgent.
The intrusion pattern ReliaQuest observed was consistent across multiple incidents. In one incident, the attacker went from initial VPN access to reaching a domain-joined file server and establishing an RDP connection using a shared local administrator password in under thirty minutes.
The behavior after that initial foothold was telling: the attacker attempted to deploy a Cobalt Strike beacon for command-and-control and tried to load a vulnerable driver, likely to kill endpoint protection using the Bring Your Own Vulnerable Driver technique. The EDR on that particular system blocked both. But the attacker logged out deliberately, came back days later using different accounts, and repeated the pattern, behavior more consistent with an initial access broker assessing victim value than with a ransomware group executing immediately.
One detail that made detection particularly difficult, as said in the report.
“The rogue login attempts observed in the investigated incidents still appeared as a normal MFA flow in logs, leading defenders to believe that MFA worked even when it failed. The sess=’CLI’ signal is a key indicator of these attacks, which suggests scripted or automated VPN authentication.” continues the report.
In other words, the logs showed what looked like successful MFA authentication, giving security teams no obvious signal that anything was wrong.
Event IDs 238 and 1080 are additional indicators worth monitoring, along with VPN logins originating from VPS or VPN infrastructure rather than expected user locations.
If you are running Gen6 SonicWall SSL-VPN appliances, confirm that the full remediation has been completed, not just that the firmware is current. The six-step LDAP reconfiguration process in SonicWall’s advisory is the actual fix. Firmware version alone is not sufficient to confirm you are protected.
The broader recommendation for Gen6 hardware is migration to a supported generation, given that end-of-life status means no future security patches. That is a bigger project, but the alternative is running perimeter infrastructure that will not receive fixes for whatever comes next.
For defenders reviewing logs right now, the sess=”CLI” indicator in VPN authentication logs is worth a search against recent history. If you find it alongside successful authentications for accounts that should be MFA-protected, you have a problem that predates this advisory.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, SonicWall VPNs)
