The risk is not only an unpatched VPN#
Attackers have reportedly bypassed multi-factor authentication on SonicWall Gen6 SSL-VPN appliances after organizations applied firmware updates but did not complete the required manual remediation steps.
BleepingComputer, citing ReliaQuest research and SonicWall’s advisory for CVE-2024-12802, reports that threat actors brute-forced VPN credentials and then authenticated in a way that avoided MFA enforcement. The activity was observed across multiple intrusions between February and March. ReliaQuest assessed with medium confidence that these incidents represented the first in-the-wild exploitation of CVE-2024-12802 across multiple environments.
The important detail is operational. In the environments ReliaQuest investigated, the SonicWall devices appeared patched because they were running updated firmware. But on Gen6 appliances, the firmware update alone did not fully remove the exposure. SonicWall says administrators also need to reconfigure LDAP settings manually. If that step is missed, MFA bypass can remain possible.
This is the kind of failure that looks clean on a patch report and dirty in a real incident.
What CVE-2024-12802 changes in practice#
CVE-2024-12802 involves missing MFA enforcement for the UPN login format. In plain terms, an attacker with valid credentials may be able to authenticate directly without triggering the expected MFA requirement.
That condition matters because VPN accounts are often exposed to credential attacks. Password reuse, weak passwords, previously stolen credentials, and brute-force attempts all become more dangerous when MFA can be bypassed under a specific login path.
ReliaQuest said the intrusions it responded to followed a fast but controlled pattern. In some cases, the attacker took between 30 and 60 minutes to log in, perform network reconnaissance, test credential reuse against internal systems, and log out. In one incident, the attacker reportedly reached a domain-joined file server in about half an hour, then established an RDP connection using a shared local administrator password.
The researchers also observed attempted deployment of tools associated with ransomware intrusions. That included a Cobalt Strike beacon for command-and-control and a vulnerable driver, likely intended for a Bring Your Own Vulnerable Driver technique to interfere with endpoint protection. In the reported case, the EDR product blocked both the beacon and the driver load.
That does not prove every related intrusion reached ransomware deployment. It does show why a VPN MFA bypass should be treated as an initial access risk, not as a narrow authentication bug.
The Gen6 remediation gap#
The patching story differs by SonicWall generation.
For Gen7 and Gen8 devices, BleepingComputer reports that updating to a newer firmware version is enough to remove the risk from CVE-2024-12802 exploitation.
For Gen6 devices, the firmware update is only part of the fix. SonicWall’s advisory requires administrators to update firmware and then complete LDAP remediation steps. Based on the source material, those steps include:
- Delete the existing LDAP configuration that uses userPrincipalName in the “Qualified login name” field.
- Remove locally cached or listed LDAP users.
- Remove the configured SSL VPN “User Domain,” which reverts it to LocalDomain.
- Recreate the LDAP configuration without userPrincipalName in the “Qualified login name” field.
- Create a fresh backup so the vulnerable LDAP configuration is not restored later.
That last point is easy to miss. A device can be fixed and then made vulnerable again if an old backup restores the previous LDAP configuration.
There is also a lifecycle issue. Gen6 SSL-VPN appliances reached end of life on April 16 this year, according to the report. End-of-life remote access infrastructure is a poor place to carry unresolved authentication edge cases. Even where a manual mitigation exists, organizations should treat migration to supported hardware as the cleaner long-term control.
Why defenders may miss it#
ReliaQuest noted a logging problem that makes the issue more dangerous. The rogue login attempts in investigated incidents still appeared as a normal MFA flow in logs. That can lead defenders to believe MFA worked when it did not.
This is the deeper lesson. Security teams often verify that a control exists, not that it enforced correctly under every authentication path. A dashboard showing “MFA enabled” may not answer the question that matters: did this login actually require and pass MFA?
ReliaQuest pointed to several signals administrators can check. One key indicator is sess="CLI", which may suggest scripted or automated VPN authentication. Other strong signals include event IDs 238 and 1080, and VPN logins from suspicious VPS or VPN infrastructure.
None of these indicators should be treated as proof by themselves. But they give defenders a practical hunting path, especially where Gen6 SonicWall SSL-VPN appliances were patched without a confirmed LDAP reconfiguration.
What to check now#
Organizations using SonicWall SSL-VPN should first identify the appliance generation and firmware state. The response differs depending on whether the device is Gen6, Gen7, or Gen8.
For Gen6 environments, do not stop at “latest firmware installed.” Confirm that the LDAP configuration was changed according to SonicWall’s advisory. Also check whether any backups taken before remediation could restore the vulnerable configuration.
Security teams should also review VPN logs for unusual login flows and infrastructure patterns. Look for:
sess="CLI"in relevant VPN authentication logs.- Event IDs 238 and 1080.
- Successful VPN logins from unusual VPS, proxy, or VPN provider infrastructure.
- Logins using different accounts from similar source infrastructure.
- Follow-on RDP activity, especially with shared local administrator credentials.
- Attempts to stage Cobalt Strike, vulnerable drivers, or other post-exploitation tooling.
Credential hygiene matters here. The reported intrusions involved brute-forced credentials and credential reuse testing. If there is evidence of suspicious VPN access, password resets should not be limited to the single account that logged in. Review adjacent accounts, privileged users, shared local administrator passwords, and any systems touched after VPN access.
Endpoint controls also matter, but they are not the first line of defense. In the incident described by ReliaQuest, EDR blocked the attempted Cobalt Strike beacon and vulnerable driver. That is a useful backstop. It is not a reason to tolerate a bypassable VPN entry point.
What not to overclaim#
The source material does not establish that every SonicWall Gen6 device is currently being exploited. It also does not prove that every observed intrusion led to ransomware deployment.
ReliaQuest assessed with medium confidence that the activity it investigated was the first in-the-wild exploitation of CVE-2024-12802. The researchers also believe the threat actor may be an initial access broker, based on behavior such as deliberate logouts and later logins using different accounts. That is an assessment, not a court finding or attribution certainty.
BleepingComputer also notes prior Akira ransomware activity against SonicWall SSL VPN devices where logins occurred despite MFA being enabled, but the method was not confirmed. That detail should be treated as contextual risk, not proof that the same technique was used.
The solid conclusion is narrower and still serious: for SonicWall Gen6 SSL-VPN appliances, patching firmware alone may leave MFA bypass exposure in place unless the LDAP remediation is completed. Defenders should verify configuration state, not only patch state.