2026-07-30 · view entry permalink →
Huntress: a three-day credential-stuffing run logged into 92 SonicWall VPN and firewall accounts across 30 organisations, with no follow-on activity observed
Huntress detected what it describes as an out-of-the-ordinary spike in successful SonicWall VPN and firewall logins starting on 2026-07-25 and continuing over the following two days (Huntress, 2026-07-28). The scale is stated day by day: "July 25: 26 unique user accounts compromised across 6 distinct organizations. July 26: 34 unique user accounts compromised across 16 distinct organizations. July 27: 32 unique user accounts compromised across 8 distinct organizations" (Huntress, 2026-07-28), 92 accounts and 30 organisations in total, which CyberScoop frames as 92 unique accounts compromised over 41 hours (CyberScoop, 2026-07-29).
The mechanism matters more than the numbers, because there is no vulnerability in it. These were successful authentications using credentials that already worked, not exploitation of a flaw in SonicOS, which means no patch addresses the exposure and no version check tells an operator whether they were affected. The traffic was also not distributed: Huntress states it "identified five primary malicious IP addresses driving this attack, all of which are registered to DigitalOcean, LLC" (Huntress, 2026-07-28), a handful of commodity cloud hosts rather than a residential-proxy pool or a botnet, which is the detail that makes retrospective log review practical.
The most operationally significant finding is what did not happen. Huntress states plainly: "We did not observe any post-compromise hands-on-keyboard activity from these attacks" (Huntress, 2026-07-28). An attacker validated working access to 92 accounts and then stopped. CyberScoop reads that pattern as intrusions that "could be pre-positioning for future attacks" (CyberScoop, 2026-07-29), that inference is CyberScoop's own, not something Huntress asserts, and the distinction is worth preserving because the two readings imply different urgency. What is not in dispute is the consequence of an unused valid credential: it stays valid. A Huntress analyst put the downstream risk as "with local network access, the sky is essentially the limit for most networks that do not have proper topology controls in place" (CyberScoop, 2026-07-29).
Where the credentials came from is unresolved and should be treated that way. Huntress's principal tactical response analyst offered candidate explanations; "this could be an aggregation of stealer malware logs, previously compromised SonicWall configuration files, or historic CVE compromise that resulted in more credentials than the adversary could use at the time" (CyberScoop, 2026-07-29), but that is explicitly hedged speculation, not a determination. SonicWall itself has not weighed in: "SonicWall hasn't released a security advisory about the malicious activity as of press time. A spokesperson told CyberScoop the company is still investigating and hopes to have more information soon" (CyberScoop, 2026-07-29).
Detection here is authentication-log work, not network-anomaly work. The telemetry class is remote-access authentication events with source-address attribution: successful logins to a VPN or firewall management portal whose source falls in cloud-hosting address space rather than the residential and mobile ranges legitimate remote users come from, clustered tightly in time across multiple accounts. Because the logins succeeded on the first or an early attempt, the classic brute-force signal (a burst of failures preceding a success) may be weak or absent, so keying detection on failure volume will miss this shape entirely. Hardening levers are credential-side rather than patch-side: rotate what may be burned, and constrain where remote-access authentication is accepted from.
Triage: a genuine remote worker authenticating to a SonicWall VPN arrives from a consumer ISP or mobile carrier range, at a plausible hour, usually to the same account over time. The discriminators for this activity are the source class and the fan-out: authentication from datacentre address space, several distinct accounts inside one organisation succeeding within a short window, and no subsequent session activity of the kind a real user generates after connecting. Any one of those alone is weak (a travelling user behind a VPN service can look like the first) but a datacentre-sourced success followed by silence is the shape to pull.
We did not observe any post-compromise hands-on-keyboard activity from these attacks.
July 25: 26 unique user accounts compromised across 6 distinct organizations. July 26: 34 unique user accounts compromised across 16 distinct organizations. July 27: 32 unique user accounts compromised across 8 distinct organizations.
We have identified five primary malicious IP addresses driving this attack, all of which are registered to DigitalOcean, LLC
SonicWall hasn't released a security advisory about the malicious activity as of press time. A spokesperson told CyberScoop the company is still investigating and hopes to have more information soon.