An Akira affiliate got into a network on 4 August through an exposed SonicWall SSL VPN using a valid account and no multi-factor authentication. The ransomware eventually failed to encrypt the host, but by then the attacker had already reached the domain controller, enumerated Active Directory, archived file shares, and sent data to attacker-controlled cloud storage.
The interesting failure is not that endpoint detection was imperfect. Huntress and Microsoft Defender both mattered later. The earlier question is why an external network with nothing to do with the organization was allowed to reach the VPN login surface in the first place.
What actually happened
Huntress reconstructed the intrusion from VPN and Windows telemetry. BleepingComputer independently reported the same initial access path and the subsequent move to the domain controller.
| Time on 4 August 2026 | Event |
|---|---|
| About 03:45 UTC | Multiple external IPs spray usernames at the SSL VPN |
| 03:52:42 UTC | A valid VPN account successfully logs in with no MFA |
| About two hours later | The operator connects to the domain controller over RDP |
| Later in the intrusion | File shares are archived and uploaded to attacker-controlled S3 storage |
| 06:29 UTC | The operator forces a reboot into Safe Mode with Networking |
| 06:34 UTC onward | The Akira payload launches, then hits memory failures |
| 08:12 UTC | Defender successfully quarantines the payload after a reboot back to normal mode |
There was no CVE in the initial access path described by Huntress. This was a credential attack against a published remote-access service. Huntress observed failed logins against multiple usernames, followed roughly seven minutes later by a successful login from an external IP.
The later Safe Mode behavior got the headline because it was unusual. Huntress observed the reboot disable its agent and Defender real-time protection, while the constrained environment also appears to have broken the ransomware process. That was fortunate, but the stolen data had already left.
The gap: the useful controls started after the first answer
MFA would have materially raised the cost of this intrusion. Its absence is a genuine security gap, and Huntress explicitly recommends requiring it on every VPN account.
But MFA is still a control that starts after the VPN service has answered a connection and accepted an authentication attempt. The credential spray only existed as an attack path because the SSL VPN was willing to conduct that conversation with arbitrary external networks.
EDR started even later. It had useful visibility once the attacker reached Windows systems, and Defender ultimately removed the ransomware binary. Those are good controls doing the jobs they were built to do. They were simply downstream of the event that created the foothold.
The ransomware failing is not the same as the intrusion failing. The attacker had already crossed the VPN boundary and taken data.
Huntress's own remediation language is important here: during active attacks, disable or IP-allowlist the SSL VPN. That advice identifies a control point before credentials, MFA, RDP, EDR, or ransomware ever enter the sequence.
What would have had to be true
The legitimate population for a corporate SSL VPN is bounded: the organization's authorized remote users, not the public internet. Those users can realistically connect from managed Windows, macOS, iOS, or Android devices while working from changing networks.
For the credential spray to fail before authentication, the VPN would have needed to answer only networks currently associated with those trusted devices. The attacker could still possess or guess a valid password. The difference is that an unrecognized network would never reach the point where the password could be tested.
This is operationally different from a public website or an SMTP server that must accept arbitrary outside traffic. A workforce VPN is specifically intended for an authorized population. Huntress's recommendation to IP-allowlist the SSL VPN during active attacks confirms that source restriction is a viable defensive measure, even if static lists are difficult to maintain for mobile users.
Where Veribound would have fitted
Veribound is a Pre-session Edge Access Control platform and an intelligence layer. It does not replace the SonicWall firewall, the VPN, MFA, EDR, SIEM, or patching. The customer's own edge equipment continues to enforce its own policy.
An agent continuously attests each authorized device. What the customer's edge receives is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. The firewall's own policy can then use those current origins instead of a manually maintained static list.
Applied to this incident:
- The credential spray does not reach the VPN login surface from networks where no trusted device is active.
- The valid credential remains valid, but credentials alone are no longer enough to make the VPN answer the attacker's network.
- MFA remains in place and still matters for connections that do come from trusted origins.
- EDR and Defender remain unchanged, protecting the endpoints and responding if a trusted path is abused or an attacker gets in another way.
What this would not have done: it would not have prevented password theft or guessing, it would not have fixed weak authentication, and it would not help if the attacker were operating through a device and network the organization already trusted. It also would not replace the need for Huntress, Defender, logging, segmentation, or incident response. It moves one decision earlier: whether the VPN should answer that origin at all.
Source: Akira hackers disable EDR with Safe Mode, steal data but fail to encrypt, BleepingComputer, 13 August 2026.