The Patch Landed. The Keys Were Already Copied.

INC ransomware stole MFA seeds from SonicWall VPN gear before the fix shipped. Patching closed the door — it didn’t change the locks on what’s inside.

Somewhere this month, a security team pulled up their patch compliance dashboard, saw green next to their SonicWall SMA 1000 appliances, and moved on to the next item on the change board. They’d done the right thing. The vulnerability pair had been public since mid-July, the fix had been out for weeks, and the appliance was current. By every normal measure, that box was closed.

It wasn’t. Volexity had already caught exploitation of the flaw pair in the wild starting in late June — three weeks before SonicWall shipped a fix. INC ransomware picked up the technique and ran with it through the rest of the summer, chaining an unauthenticated WebSocket tunnel bug with a privilege-escalation flaw to reach root on the appliance, and from there pulling credentials and TOTP seeds used for MFA. Patching the appliance in August didn’t undo any of that. If an attacker already has the seed your authenticator app is deriving codes from, your MFA prompt isn’t checking “is this really you” anymore — it’s checking “does this person have the number I gave them in June,” and the answer is yes, because you gave it to them without knowing it.

That’s the part of this story worth sitting with longer than the CVE numbers. A patched, compliant, fully up-to-date edge device can still be a live foothold, because the thing that made the appliance trustworthy — the secret backing MFA — left the building before the fix did. INC’s leak site lists 885 victims and counting as of early August, and a meaningful chunk of them are organizations that believe, correctly, that they patched on time.

What a stolen secret means for the network behind it

The instinct after news like this is to check patch status and call it done. The harder question is what that VPN appliance was allowed to reach once someone was inside it with valid-looking credentials. An SMA 1000 box terminates remote access into the internal network — that’s its entire job — so an attacker who walks in through it with real MFA codes doesn’t look like an intrusion. They look like an employee working from home. Whatever segmentation exists behind that VPN concentrator is the only thing standing between “we got past the edge” and “we’re in the file servers.”

This is where vDefend’s Distributed Firewall earns its keep in a story like this: policy enforced at the vNIC of every workload means the VPN-terminated segment doesn’t get a free pass just because the traffic arrived authenticated. A rule that scopes what a remote-access session can reach — specific application tiers, not the whole flat internal network — holds regardless of whether the credentials backing that session are legitimate or stolen. Identity Firewall rules built around the actual service accounts and user groups that should be using that VPN path add a second constraint: even a correctly-authenticated session from an unexpected identity, at an unexpected hour, reaching an unexpected host, is a rule violation before it’s an alert someone has to notice.

Why deployment speed just became the story, not just the detection

Broadcom shipped vDefend SSP 5.2 this month, and the headline feature isn’t a new detection signature — it’s how fast a team can stand up the detection stack at all. The release introduces what it calls vDefend 1-2-3: a staged rollout of Distributed IDS/IPS, network traffic analysis, and NDR across shared-services segments and then production zones, compressing what the vendor describes as a months-long deployment into weeks. Paired with that is on-premises malware analysis (no more uploading files to an external cloud service to get a verdict, which matters for anyone with data-sovereignty constraints) and a leaner two-node platform footprint that cuts hardware requirements by roughly a third.

Deployment speed sounds like an operations footnote next to a ransomware story, but it isn’t. CrowdStrike’s 2026 threat reporting put average eCrime breakout time — the gap between initial access and the first lateral movement — at 29 minutes, down 65% year over year, with the fastest observed case at 27 seconds. A segmentation and detection rollout that takes eight months to reach your production VPN-facing segment was already losing to a 29-minute attacker before this SonicWall story ever happened. It just wasn’t obvious until an appliance sitting in the “we’ll segment that properly next quarter” pile turned out to be exactly the one an attacker walked through.

Where to spend the next two weeks

Pull your SMA 1000s — or any remote-access appliance — off the “patched, therefore done” list and check what they were exposed to during the exploitation window that started in late June, not just whether the fix is installed now. If any were vulnerable during that stretch, rotate the credentials and MFA seeds behind them; reissuing enrollment is the only way to invalidate a stolen TOTP secret, and a patch alone doesn’t touch it. Separately, look at the DFW policy governing whatever segment your VPN concentrators land traffic in — if a remote session can reach the same breadth of the network an on-site workstation can, that’s the gap this specific incident would have walked straight through. And if a lateral-security rollout has been sitting half-finished because the deployment timeline kept slipping, vDefend 1-2-3 is worth a look specifically because it’s aimed at that problem: getting shared-services and production segments covered in weeks instead of the quarter-plus timeline that let this kind of gap persist in the first place.

None of this closes the SonicWall vulnerability faster than the vendor already did. What it does is make sure the next appliance that gets quietly compromised before its patch ships doesn’t turn into a straight line to production.

The Patch Landed. The Keys Were Already Copied.

What a stolen secret means for the network behind it

Why deployment speed just became the story, not just the detection

Where to spend the next two weeks

Further reading