SonicWall Gen6 SSL-VPN MFA Bypass: Incomplete Remediation Leaves Patched Devices Exposed

Threat actors are actively targeting SonicWall Gen6 SSL-VPN appliances by abusing a vulnerability that can allow multi-factor authentication to be bypassed, even on devices that appear to be running updated firmware.

The attacks are tied to CVE-2024-12802, a SonicWall SSL-VPN vulnerability affecting certain Gen6 configurations. According to recent incident response findings, attackers used valid VPN credentials, bypassed MFA enforcement, and moved quickly into internal environments to perform reconnaissance and test access to additional systems.

The most concerning detail is that some impacted SonicWall appliances had already been updated. However, on Gen6 devices, the firmware update alone does not fully resolve the issue. SonicWall’s remediation also requires manual cleanup and reconfiguration of LDAP settings. Without that extra step, organizations may believe they are protected while the VPN remains exposed.

Patched Firmware Was Not Enough

The vulnerability is related to MFA not being properly enforced when authentication uses the UPN login format. In affected LDAP configurations, an attacker with valid credentials may be able to authenticate through SSL-VPN without completing the expected MFA challenge.

This creates a dangerous gap for organizations relying on MFA as their final protection layer against compromised credentials.

Security researchers observed multiple intrusions where SonicWall devices appeared to be patched but were still vulnerable because the required LDAP remediation steps had not been completed. In other words, the firewall firmware was updated, but the authentication configuration still carried the risk forward.

Fast-Moving VPN Intrusions

During the investigated attacks, the threat actor moved quickly after gaining access. In some cases, the full intrusion window lasted only 30 to 60 minutes.

Once connected through VPN, the attacker performed internal network reconnaissance, tested reused credentials, attempted access to internal systems, and then logged out. In one incident, the attacker reached a domain-joined file server within roughly 30 minutes and used RDP with a shared local administrator password.

Researchers also observed attempts to deploy more advanced post-exploitation tooling, including a Cobalt Strike beacon for command-and-control access and a vulnerable driver likely intended to weaken or disable endpoint security through a Bring Your Own Vulnerable Driver technique.

In that case, the organization’s EDR blocked both the beacon and the driver load attempt.

Possible Initial Access Broker Activity

The attacker’s behavior suggests they may not have been the final ransomware operator. The deliberate logouts, return activity days later, and use of different accounts point to possible initial access broker activity.

Initial access brokers specialize in gaining entry into corporate networks and then selling that access to ransomware crews or other cybercriminal groups.

This makes the SonicWall VPN activity especially important for defenders. A short login session may not immediately result in ransomware deployment, but it could represent the first stage of a larger attack chain.

Logs May Make MFA Look Successful

One of the more troubling findings is that the suspicious login activity may appear in logs as if MFA worked normally.

That means administrators reviewing SonicWall logs could see what looks like a normal authentication flow, even though MFA enforcement was effectively bypassed.

Defenders are being urged to look beyond basic successful-login entries and review stronger indicators, including:

• sess="CLI" entries, which may suggest scripted or automated VPN authentication
• Event IDs 238 and 1080
• VPN access from suspicious VPS, proxy, or commercial VPN infrastructure
• Logins from unusual countries or IP addresses
• Multiple accounts authenticating from the same external source
• VPN access followed quickly by RDP, file server access, or internal scanning

Gen6 Devices Require Manual LDAP Remediation

For SonicWall Gen6 SSL-VPN appliances, administrators must complete both the firmware update and the manual LDAP remediation process.

The required steps include deleting the existing LDAP configuration that uses userPrincipalName in the Qualified login name field, removing cached LDAP users, clearing the SSL VPN User Domain, rebooting the firewall, and recreating the LDAP configuration without userPrincipalName in that field.

Administrators should also create a fresh backup afterward to avoid accidentally restoring the vulnerable configuration later.

For SonicWall Gen7 and Gen8 devices, updating to a newer firmware version is enough to fully address the issue.

Gen6 End-of-Life Raises the Risk

SonicWall Gen6 SSL-VPN appliances reached end-of-life on April 16, meaning they no longer receive ongoing security updates.

Organizations still using Gen6 appliances should treat this as a priority security issue. Even if firmware appears current, administrators should verify that the LDAP remediation was completed exactly as required.