Through late July and into early August 2026, the INC Ransomware operation emerged as the dominant threat actor weaponising two vulnerabilities in SonicWall Secure Mobile Access (SMA) 1000 series appliances. The group has claimed 885 victims to date, with activity accelerating markedly since the start of August and the most recent listing on 2 August 2026.

Recent victims span private and government organisations across Australia, the United States, the United Arab Emirates, Colombia, and Switzerland.

The vulnerabilities:

  • CVE-2026-15409 — server-side request forgery in the SMA 1000 Workplace interface, CVSS 10.0, allowing a remote unauthenticated attacker to direct network requests to locations of the attacker’s choosing.
  • CVE-2026-15410 — remote code execution, CVSS 7.2.

Chained, they produce unauthenticated arbitrary command execution and full device takeover.

The timeline is the part most organisations got wrong. Exploitation by the actor tracked as UTA0533 began no later than 22 June 2026 — weeks before public disclosure. SonicWall released fixes in mid-July 2026. CISA added both CVEs to the Known Exploited Vulnerabilities catalog on 14 July 2026, with a remediation date of 17 July — a three-day window, one of the shortest CISA has issued.

That compressed window was justified. But it also created a widespread misunderstanding, because for this particular vulnerability pair, meeting the KEV deadline did not remediate the compromise.

What the attackers actually take

This is the detail that separates this campaign from routine edge-device exploitation, and it is the detail that determines your response plan.

Researchers analysing the intrusions found that the operators are not primarily interested in deploying encryption on the appliance. They are interested in what the appliance stores. Specifically, they extract:

  • High-value credentials cached or stored by the appliance
  • Active session databases — live authenticated sessions
  • TOTP multi-factor authentication seed configurations — the shared secrets that generate one-time codes

Read that last item again. The seed is the secret from which every future TOTP code for that user is derived. An attacker holding a user’s TOTP seed can generate valid six-digit codes indefinitely, on demand, offline, without any interaction with the user or the appliance.

The tooling observed reflects the objective: a Python script named KNUCKLEBALL, the Suo5 HTTP proxy for tunnelling, and a custom Java web shell called ORANGETAIL. The exploitation activity concentrates on the /wsproxy endpoint.

The operators have also employed social engineering alongside the technical intrusion, with individuals using the phone number +1 (304) 384-0401 contacting victims claiming to offer ransomware assistance — a pressure tactic that has become common as a second stage after data theft.

Why patching is not remediation here

The standard vulnerability management reflex is: identify affected assets, apply the vendor fix, close the ticket, record the remediation date for audit. For most CVEs, that is correct and sufficient.

It is insufficient here, and the reason is mechanical rather than theoretical.

The patch closes the door. It does not revoke what came through it.

If the appliance was exploited before you patched — and given that exploitation began 22 June, three weeks before the fix existed, a large proportion of exposed appliances were — the attacker now holds:

  1. Credentials that remain valid after patching, because patching does not rotate passwords.
  2. Session tokens that remain valid after patching, because patching does not invalidate sessions.
  3. TOTP seeds that remain valid after patching, because patching does not re-provision MFA enrolments.

An organisation that patched inside CISA’s 17 July deadline, recorded compliance, and moved on has an appliance that is no longer vulnerable and an attacker who no longer needs it to be. The next authentication looks entirely legitimate: correct username, correct password, correct MFA code, from a VPN exit node.

This is precisely the failure mode that makes MFA-seed theft so much more damaging than credential theft. Credential theft is defeated by MFA. Seed theft defeats MFA. And unlike a phishing-resistant factor, a TOTP seed leaves no trace of misuse — the code is arithmetically correct.

The four actions that constitute actual remediation

For any SMA 1000 appliance that was internet-reachable and unpatched at any point between 22 June and the date you applied the fix, assume compromise and execute all four:

1. Patch. Apply SonicWall’s mid-July fixes. This is necessary and it is step one of four, not the whole task.

2. Rotate every credential the appliance could reach. Not only local appliance accounts. Any account that authenticated through the appliance, any service account configured on it, and any directory-integration credential it held. If the appliance was domain-joined or held a directory bind account, that account’s exposure extends to the directory.

3. Invalidate all sessions and re-provision all MFA enrolments. This is the step organisations skip because it is disruptive and because the connection between “VPN appliance compromised” and “every user must re-enrol their authenticator app” is not intuitive. It is nonetheless the step that determines whether the attacker retains access. Every TOTP secret provisioned through or stored by that appliance must be treated as public and regenerated. Users must re-scan.

4. Hunt, specifically. Look for requests to /wsproxy. Look for the tooling signatures — KNUCKLEBALL, Suo5 proxy traffic patterns, ORANGETAIL web shell artefacts. Look for authentication events that are individually valid but contextually anomalous: correct credentials and correct MFA from unfamiliar geography, at unusual hours, or from hosting-provider address space. Verify appliance file system integrity against a known-good baseline rather than trusting the running system to report on itself.

The compliance framing

CISA BOD 22-01 and the KEV catalog

For Federal Civilian Executive Branch agencies, Binding Operational Directive 22-01 makes KEV remediation mandatory within the catalog’s stated date. Both SonicWall CVEs carried a 17 July 2026 due date.

BOD 22-01 speaks in terms of remediating the vulnerability. Where exploitation preceded patching and the exploitation objective was credential and seed exfiltration, an agency that patched but did not rotate has satisfied the letter of the directive while leaving the adversary’s access intact. The directive was never intended to substitute for incident response, and the KEV entry is a signal that exploitation is occurring — which is to say, a signal to check whether it occurred to you.

For non-federal organisations, KEV is not binding, but it has become the de facto standard reference in contract terms, cyber insurance questionnaires, and regulatory examination. “Was it on KEV, and when did you remediate?” is now a routine question. It is worth being able to answer the follow-up: “and did you rotate?”

We covered the mechanics of KEV-driven prioritisation and the risk-based alternative in our analysis of BOD 26-04 and the 7 August deadline.

Breach notification exposure

An appliance compromise that yields credentials and session data is not automatically a reportable breach. It becomes one when the attacker used that access to reach regulated data. The analysis differs by regime:

  • HIPAA — under 45 CFR § 164.402, an impermissible acquisition, access, use, or disclosure of PHI is presumed to be a breach unless the entity demonstrates a low probability of compromise through a four-factor risk assessment. Where an attacker held valid credentials and MFA seeds for systems containing ePHI, demonstrating low probability requires evidence — access logs that affirmatively show what was and was not reached — not the absence of evidence.
  • GDPR — Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to data subjects. The 72 hours runs from awareness, and awareness of an appliance compromise that exposed session data to systems holding personal data is enough to start it.
  • NIS2 — for essential and important entities, the 24-hour early warning and 72-hour incident notification obligations apply to significant incidents. A ransomware actor with authenticated access to a remote access gateway will generally meet the significance threshold.
  • SEC Item 1.05 — for U.S. registrants, a materiality determination must be made without unreasonable delay, with an 8-K within four business days of that determination. Ransomware with confirmed data exfiltration is the paradigm case.
  • DORA — for EU financial entities, the major ICT-related incident reporting regime under Articles 17–19 applies, with initial notification on a compressed timeline.

The common thread: every one of these clocks starts on awareness, and awareness of exploitation of a KEV-listed edge device with confirmed credential theft is not something an organisation can defer by declining to investigate.

The structural problem with edge devices

INC’s 885 claimed victims did not arise from an unusual level of sophistication. They arose from a structural property of security appliances that the industry has not resolved.

They are exposed by design. A remote access gateway that is not internet-reachable does not perform its function. There is no network segmentation answer to this.

They are credential concentrators. The appliance sits at the authentication boundary, which means it necessarily holds or brokers the material that authentication depends on. Compromise of the device is therefore compromise of the authentication system, not merely of one host.

They are opaque to standard tooling. Most SSL VPN and secure access appliances are closed systems that do not accept an EDR agent. Detection depends on the appliance’s own logs — logs written by a system the attacker controls.

Their patch cycles are slow. Appliance patching often requires a maintenance window, carries availability risk, and touches the exact system every remote worker depends on. That friction is why the interval between fix availability and fix deployment is measured in weeks.

The consequence: exploitation began 22 June, disclosure and patch arrived mid-July, and mass ransomware deployment followed in early August. The attacker had a three-week head start on the patch and a further window while organisations scheduled maintenance.

The practical mitigations are unglamorous:

  • Maintain an accurate inventory of internet-facing appliances, including model, firmware version, and exposure. The most common reason a KEV deadline is missed is that nobody knew the device existed.
  • Treat appliance patching as emergency change, with a pre-approved pathway that does not require a normal CAB cycle.
  • Move toward phishing-resistant, hardware-bound authentication. A FIDO2 or WebAuthn credential is bound to hardware and cannot be exfiltrated from an appliance database. The TOTP seed theft in this campaign is only possible because TOTP is a shared secret. This is the single change that would have neutralised the campaign’s primary objective.
  • Ship appliance logs off the appliance in real time, to a system the appliance cannot write to. If the only record of what happened lives on the compromised device, you have no record.
  • Pre-write the credential rotation runbook. The organisations that struggled most in this campaign were not those that failed to detect. They were those that detected, understood the seed theft implication, and then discovered that mass MFA re-enrolment had no owner, no procedure, and no communications plan.

The question to answer today

For any organisation running SMA 1000 appliances, one question governs everything else:

Was the appliance internet-reachable and unpatched at any point between 22 June 2026 and the date the fix was applied?

If yes, patching was step one. Credential rotation, session invalidation, and MFA re-provisioning are steps two through four, and they are not optional. Until they are complete, the attacker’s access persists in a form that looks, to every log and every control you operate, exactly like a legitimate user signing in.

If you cannot answer the question because you do not have the exposure history, that is itself the finding, and the safe assumption is yes.

Conclusion

The SonicWall SMA 1000 campaign is a clean illustration of a distinction that vulnerability management programmes routinely collapse: patching closes a vulnerability; it does not undo an exploitation.

CISA’s three-day remediation window was aggressive and correct. But a KEV listing is not only an instruction to patch — it is notification that the vulnerability is being exploited in the wild, which is to say, notification to determine whether it was exploited against you. An organisation that treats KEV entries purely as a patch queue will keep meeting deadlines and keep getting breached by attackers who were already inside when the deadline was set.

The specific lesson of this campaign is narrower and sharper. When the exploitation objective is MFA seed material, the compromise survives every remediation step except re-provisioning. An attacker with your users’ TOTP seeds does not need your vulnerability. They have your authentication.

This article is provided for informational purposes only and does not constitute legal advice.