Credential spray against a SonicWall SSL VPN — timeline and entry
Huntress began responding to the incident in early August. On August 4, a SonicWall SSL VPN logged a credential-spray attack: a clustered set of failed logins that the appliance initially denied. Seven minutes after that burst, an attacker succeeded by authenticating with a valid VPN account that lacked multi-factor authentication (MFA). That single account provided the foothold that allowed the intruder to move deeper into the environment.
Remote Desktop access and Active Directory enumeration
Once inside, the attacker used Remote Desktop Protocol (RDP) to reach the domain controller and ran an extensive query of Active Directory. Northey reported that “the enumeration was a full-property dump of every user and every computer in the domain.” The attacker collected detailed information about users, groups and computers — the precise inventory and relationships that facilitate lateral movement and broad ransomware deployment.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageTools for theft and persistence: WinRAR, s5cmd, AnyDesk and akira.exe
The affiliate harvested data from an application server and from mapped file shares. The attacker downloaded WinRAR to archive stolen file shares, then used s5cmd — a fast S3 transfer utility — to ship those archives to cloud storage. For remote control and persistence they installed AnyDesk, configured to start with Windows, and abused that legitimate remote-desktop product as a remote-access trojan and command-and-control channel to drop additional malware. Among the binaries deployed was akira.exe, the Akira encryptor.
Safe Mode reboot: disabling EDR but also breaking the encryptor
About three hours into the intrusion the attacker forced a reboot into Safe Mode with Networking — a technique used to prevent endpoint detection and response products and other security tools from loading. In this incident the Safe Mode boot stopped the Huntress agent and disabled Microsoft Defender’s real-time protection, creating the “blind window” attackers seek.
But the Safe Mode environment also constrained virtual memory, and thirteen seconds after the reboot the system began producing memory errors. The limited startup configuration did not provide enough virtual memory for akira.exe to complete mass encryption; in effect, Safe Mode simultaneously disabled the defender and sabotaged the attacker’s encryptor. Northey cautioned this was likely a memory-configuration issue and not a reliable defensive technique: “It’s possible that a host with more physical memory or a larger page file might give akira.exe enough virtual memory to encrypt the endpoint in Safe Mode,” he wrote. He also warned that “Akira’s developers or affiliates could retool the encryptor to reduce its memory demands or make its Safe Mode launch sequence more reliable,” meaning the same failure may not recur.
Huntress mitigation recommendations: MFA and boot-change alerting
Huntress’ immediate takeaways were pragmatic and narrow. First: require MFA on every VPN account — a point made bluntly in the incident write-up: “For the love of all that is holy, turn on multi-factor authentication (MFA).” Second: tune detection and alerting to catch the Safe Mode play and boot-configuration changes. Northey suggested specific signals to monitor: activity invoking msconfig.exe or bcdedit, Kernel-Boot Event ID 27 with a SAFEBOOT load option, Kernel-General Event ID 12 with BootMode=2, and system events showing third-party security services stopping (System Event ID 7036). He also advised watching for tooling being added to the Safe Mode minimal-service registry list.
What this means for VPN administrators, security teams, and attackers
- VPN administrators: The successful login came through a valid account that lacked MFA; requiring MFA on every VPN account is the clearest preventative step the incident report highlights.
- Security teams and incident responders: Monitor boot-configuration changes and Safe Mode boots (the specific EIDs and commands above), and alert on abrupt stopping of security services to detect this attacker technique earlier.
- Attackers and affiliates: The incident demonstrates both a usable operational play — rebooting into Safe Mode to kill EDR — and a fragility: constrained Safe Mode memory can break an encryptor. Northey notes that affiliates or developers could adapt the encryptor to succeed under Safe Mode in future intrusions.
The episode is a cautionary vignette: the breach lifecycle can separate theft from encryption. Even when an encryptor fails, attackers may already have taken credentials and archives to cloud storage. The simple technical fixes urged by Huntress — mandatory MFA on VPN accounts and targeted alerting for Safe Mode-related activity and boot changes — address the precise gaps this intruder exploited. Whether attackers will change tactics or code remains an open question; for now, defenders have a concrete set of signals to watch and a blunt prevention step to implement.
