Patching a CVE used to mean downloading firmware and rebooting. For SonicWall Gen6 SSL-VPN customers, that mental model just cost them domain access. Threat actors are actively brute-forcing VPN credentials and strolling past multi-factor authentication on appliances that administrators believed were fully patched — because the firmware update alone never closed the hole.
The vulnerability, CVE-2024-12802, was technically remediated by SonicWall. But the fix required a manual LDAP reconfiguration that a lot of teams skipped, and attackers noticed before defenders did.
Why a Firmware Update Wasn’t Enough to Stop CVE-2024-12802
According to ReliaQuest, researchers responded to multiple intrusions between February and March that they assess with medium confidence to be the first in-the-wild exploitation of CVE-2024-12802. The flaw stems from missing MFA enforcement for the UPN login format, meaning an attacker with valid credentials can authenticate directly and skip the MFA prompt entirely. SonicWall’s advisory explicitly states that on Gen6 devices, installing the firmware update does not fully mitigate the vulnerability — administrators must also delete the existing LDAP configuration that uses userPrincipalName in the “Qualified login name” field, purge cached LDAP users, remove the configured SSL VPN “User Domain,” reboot, and rebuild the config from scratch.
Why this matters: most vulnerability management programs treat “firmware version current” as the green-light condition for closing a ticket. ReliaQuest noted that in the environments they investigated, the devices looked patched because they were running the updated firmware — yet they remained vulnerable because the remediation steps had not been completed. The detection gap is procedural, not technical.
If you’re a team running Gen6 appliances, your CMDB and your patch dashboard are both lying to you right now unless someone has physically walked through the six-step LDAP rebuild in the vendor advisory. Our take: vendor advisories that bury manual reconfiguration steps below the firmware download link are a structural problem, and SonicWall isn’t the only vendor doing it.
How the Attackers Moved: 30 Minutes From Login to Domain File Server
The intrusion pattern ReliaQuest documented is brutally efficient. The threat actor took between 30 and 60 minutes per session to log in, perform network reconnaissance, test credential reuse on internal systems, and log out. In one incident, the attacker reached a domain-joined file server in as little as half an hour and pivoted via RDP using a shared local administrator password. From there, they attempted to deploy a Cobalt Strike beacon for command-and-control and a vulnerable driver — a classic Bring Your Own Vulnerable Driver (BYOVD) play to disable endpoint protection. The installed EDR blocked both the beacon and the driver load.
Why this matters: the deliberate log-out behavior, paired with re-entries days later using different accounts, suggests this isn’t a single ransomware crew. ReliaQuest believes the actor is an initial access broker — someone who breaks in, fingerprints the environment, and resells the access to ransomware affiliates. That’s the same playbook that fed Akira’s SonicWall SSL VPN campaign last year, where attackers logged into MFA-protected accounts using a method that was never publicly confirmed.
Imagine you’re a mid-sized hospital running Gen6 SonicWall appliances at the perimeter — exactly the kind of environment described in healthcare software stacks built for compliance. A broker gets in at 2 a.m., maps your file shares in 40 minutes, logs out, and three weeks later your radiology department is encrypted by a ransomware affiliate who paid for the access. Our take: brokered access will keep stretching the window between intrusion and impact, and any detection strategy that only watches for ransomware payloads will keep missing the break-in that enabled it.
The Detection Signal Most SOCs Are Missing
ReliaQuest flagged something defenders need to act on immediately: in the investigated incidents, the rogue logins still appeared as a normal MFA flow in the logs. Defenders looking at SIEM dashboards saw clean authentication events and assumed MFA was doing its job. The researchers identified sess="CLI" as a key indicator, suggesting scripted or automated VPN authentication rather than a human at a browser. Event IDs 238 and 1080, plus VPN logins originating from suspicious VPS or commercial VPN infrastructure, round out the detection signature.
Why this matters: if your log pipeline is normalizing or dropping the session-type field, you have no way to distinguish a legitimate user from an automated bypass. Supply chain teams have hit the same problem: traceability logs that rolled up signals that mattered — visible in isolation, invisible after aggregation. For shops thinking about resilience across end-to-end supply chain auditing, the same lesson applies: log fidelity at the edge determines whether you can reconstruct an incident at the center.
If your SOC ingests SonicWall logs today, the next sprint should include a rule for sess="CLI" paired with geolocation anomalies on the source IP. Our prediction: within two quarters, at least one major SIEM vendor will ship a pre-built content pack for CVE-2024-12802, because the signal is precise and the exposure too broad to leave as a DIY rule.
Why Gen6 End-of-Life Makes This Worse
Gen6 SSL-VPN appliances reached end-of-life on April 16 of this year and no longer receive security updates. That means any organization still running Gen6 hardware is now patching a vulnerability on a platform that won’t get patched for the next one. SonicWall’s guidance is to move to Gen7 or Gen8, where a firmware update alone fully removes the CVE-2024-12802 risk without the LDAP reconfiguration dance.
Why this matters: the calculus on “replace the appliance” changes when the vendor stops shipping fixes. Procurement teams that approved a 12-month delay on the hardware refresh because “the box still works” are now sitting on an exploitable VPN edge with no upgrade path for the next disclosed bug. Our take: any security team that hasn’t already booked the Gen6 replacement for this quarter is going to be explaining this CVE to their auditors before the year is out.
FAQ
Q: What is CVE-2024-12802 and which devices are affected? A: CVE-2024-12802 is a missing MFA enforcement vulnerability in SonicWall SSL-VPN appliances that lets attackers with valid credentials bypass multi-factor authentication when logging in with the UPN format. It affects Gen6, Gen7, and Gen8 devices, but Gen6 requires manual LDAP reconfiguration beyond the firmware update to be fully remediated.
Q: How do I tell if my SonicWall device is actually patched?
A: Running the updated firmware is not sufficient on Gen6. You must delete the existing LDAP configuration using userPrincipalName in the “Qualified login name” field, remove cached LDAP users, remove the configured SSL VPN “User Domain,” reboot the firewall, recreate the LDAP configuration without userPrincipalName, and take a fresh backup so the vulnerable config can’t be restored later.
Q: What logs should defenders look at right now?
A: ReliaQuest recommends hunting for sess="CLI" in VPN authentication logs, which indicates scripted or automated logins rather than browser-based sessions. Event IDs 238 and 1080, along with VPN logins originating from suspicious VPS or VPN infrastructure, are additional strong signals.
Key Takeaways
- Treat any vendor advisory with manual remediation steps as a separate ticket from the firmware update — your patch dashboard will report “green” while the vulnerability remains live.
- Build SIEM detections for
sess="CLI", event IDs 238 and 1080, and VPN logins from commercial VPS infrastructure before your next quarterly review. - Audit shared local administrator passwords on domain-joined servers; the half-hour pivot to a file server in this campaign depended on credential reuse.
- Plan Gen6 SonicWall hardware replacements now — end-of-life on April 16 means the next CVE on this platform has no patch coming.
- Assume initial access brokers are operating in your VPN logs even when no ransomware payload has fired; the absence of impact is not evidence of absence.