On August 4, an Akira ransomware affiliate logged into a company’s SonicWall VPN. The account didn’t have multi-factor authentication enabled. It was a normal VPN login with valid credentials, and nothing flagged it as suspicious.

Two hours later, the attacker was on the domain controller. Five hours after login, they had archived the company’s file shares, uploaded everything to a cloud storage bucket, and attempted to encrypt the network. The encryption actually failed (low memory on the target machine, of all things), but the data was already gone.

Managed detection company Huntress documented the full timeline, and it’s worth walking through because every step in it maps to something we see in small and mid-size professional services firms.

The timeline

Hour 0: VPN login. The attacker logged in through a SonicWall SSL VPN appliance using valid credentials. No MFA prompt, no challenge, no additional verification. Just a username and password. Where did they get the credentials? The usual places: credential stuffing from a previous breach, a password spray, or an infostealer on someone’s home computer. The method doesn’t matter as much as the fact that nothing stopped them at the door.

Hour 2: Domain controller. Using the VPN connection, the attacker connected to the domain controller via remote desktop. They enumerated all Active Directory users and computers, then moved laterally to an application server. Two hours from login to full visibility of the network.

Hours 3-4: Data exfiltration. The attacker used WinRAR to compress mapped file shares and a command-line tool to upload the archives to an attacker-controlled Amazon S3 bucket. They also installed AnyDesk (a remote access tool) so they could maintain access even if the VPN connection was closed.

Hour 5: EDR bypass and encryption attempt. The attacker used AnyDesk to force the compromised machine to reboot into Windows Safe Mode with Networking. Safe Mode loads only essential drivers and services, which means most security tools don’t start. For roughly 10 minutes, both the EDR agent and Microsoft Defender’s real-time protection were disabled. The attacker tried to launch their ransomware payload during that window, but it failed because the machine didn’t have enough memory to execute it.

The encryption failed. The data theft didn’t. Everything they wanted was already in their S3 bucket by the time anyone could respond.

Where the defenses failed

The first failure was MFA. If the VPN had required a second factor, stolen credentials alone wouldn’t have been enough. This is the control that cyber insurance carriers ask about first, and it’s the one that would have stopped this attack before it started.

The second failure was monitoring. Two hours passed between the initial VPN login and the attacker reaching the domain controller. That’s not fast by attacker standards, but nobody noticed. No alert on the unusual login time, no flag on the lateral movement to the domain controller, no detection of the Active Directory enumeration. If the firm had 24/7 monitoring, there would have been a window to intervene.

The third failure was endpoint hardening. The attacker rebooted into Safe Mode specifically to bypass security tools. This technique isn’t new (the Snatch and AvosLocker ransomware groups have used it for years), but it’s effective because most EDR products don’t load in Safe Mode. Huntress recommends monitoring for Safe Mode boot configuration changes and preventing remote-access tools from being added to the Safe Mode service registry.

Why this matters for your firm

If your firm uses a VPN for remote access, check whether every account has MFA enabled. Not most accounts. Every account. The attacker in this case only needed one.

If your VPN appliance is a SonicWall, this is especially relevant. Akira has been targeting SonicWall devices for over a year, exploiting both known vulnerabilities and stolen credentials. But the broader point applies regardless of hardware brand: any VPN without MFA is an open invitation.

We wrote in April about how most attacks start with a login, not an exploit. This is another case study proving the same thing. The attacker didn’t break through a firewall or exploit a zero-day. They logged in. The technical sophistication came later, once they were already inside.

What to check this week

Is MFA actually enforced on your VPN? “We set it up” isn’t the same as “it’s required for every account.” Have your IT provider confirm that MFA is enabled for every user who has VPN access, with no exceptions. If your VPN platform doesn’t support MFA (some legacy appliances don’t), that’s a bigger conversation about replacement.

Do you know what “normal” VPN activity looks like? If a login happens at 2 AM from an unfamiliar location, does anyone get alerted? Most VPN appliances can log this information, but if nobody is watching the logs, the data just accumulates until a forensic investigator reads it after the fact.

Is your remote access audited regularly? How many people have VPN access who don’t need it anymore? Former employees, contractors who finished a project, staff who switched to in-office only. Every active VPN account is a potential entry point. The fewer there are, the smaller the attack surface.

What does your insurance application say about MFA? Most cyber liability applications ask specifically whether MFA is enforced on remote access. If you attested “yes” but your VPN has exceptions, that’s an attestation gap that could affect a claim. We covered this in more detail in our post on why ransomware groups target law firms.

This attack failed to encrypt anything, but only because the target machine ran out of memory. The data was already stolen, the credentials were already compromised, and the firm was already looking at a breach notification, extortion demand, and insurance claim.

The fix is boring and well-understood: MFA on remote access, monitoring for anomalous logins, regular access reviews. The firms that do those things aren’t the ones showing up in incident reports.

If your firm uses a VPN and you’re not sure whether MFA is enforced on every account, that’s something we can check for you.