Akira Ransomware Is Walking In Through Your VPN Appliance: A SonicWall, Fortinet, and Cisco Defense Guide for 2026

Almost every Akira ransomware case I have helped scope over the past two years started the same way: not with a phishing email, but with a login. A valid VPN session, often from a residential IP address in another country, connecting to an edge appliance that was either missing a patch or missing multi-factor authentication. By the time anyone noticed, the operators had already moved laterally, stolen credentials, exfiltrated data, and were minutes away from dropping akira_readme.txt on every server.

Akira has been one of the most prolific ransomware operations since it surfaced in March 2023. It runs as ransomware-as-a-service, uses double extortion (steal first, then encrypt), and has consistently favored one initial access method over all others: your perimeter VPN. If you run a SonicWall, Fortinet, or Cisco gateway and you treat this as a generic best-practices article, you will miss the point. This is about closing the specific doors that this specific group is using right now.

Why VPN appliances became the front door

Ransomware crews are pragmatic. Phishing requires a user to take the bait, and endpoint detection has gotten good at catching the payloads that follow. An internet-facing VPN gateway, by contrast, is reachable by anyone, runs firmware that is awkward to patch, and frequently protects accounts that have no second factor. If the operator has working credentials or a usable exploit, they land directly inside the network with no malware on disk and no user interaction to flag.

Akira affiliates have leaned into this in three distinct ways: exploiting known vulnerabilities in the appliance firmware, brute-forcing or replaying credentials on accounts without MFA, and reusing credentials harvested from infostealer logs sold on criminal marketplaces. Each one maps to a separate set of defenses, so let us take the major vendors in turn.

SonicWall: CVE-2024-40766 and the credential reset everyone skipped

The vulnerability that fed a large wave of Akira intrusions is CVE-2024-40766, an improper access control flaw in SonicWall SonicOS rated CVSS 9.3. It affects the management interface and SSL VPN on Gen 5, Gen 6, and some Gen 7 firewalls. SonicWall patched it and then issued a follow-up advisory making a point that a lot of administrators ignored: patching alone is not enough. If local user accounts existed before the upgrade, their passwords needed to be reset, because credentials could have already been exposed.

In incident after incident, the firewall was patched but the local SSL VPN accounts were never rotated. The operators logged in with credentials they had already captured. The patch was applied and the network still fell. If you run SonicWall and you applied the fix but never forced a password reset on every local account, you are not protected. Do it now.

Fortinet: FortiOS SSL VPN remote code execution

Fortinet's SSL VPN has a long history of pre-authentication flaws, and Akira and adjacent groups have exploited several. CVE-2024-21762 is an out-of-bounds write in FortiOS SSL VPN that allows unauthenticated remote code execution, rated CVSS 9.8. Earlier flaws like CVE-2022-42475 and CVE-2023-27997 sit in the same category. The pattern is consistent: a memory-corruption bug in the SSL VPN service that lets an attacker run code before they ever authenticate.

If you cannot patch a Fortinet SSL VPN immediately, Fortinet's own mitigation is to disable the SSL VPN service entirely until you can. That is a real, supported control, not a last resort. An exposed unpatched FortiGate SSL VPN should be considered a question of when, not if.

Cisco: ASA/FTD VPN brute force and CVE-2023-20269

On the Cisco side, Akira affiliates exploited CVE-2023-20269, a flaw in the remote access VPN feature of Cisco ASA and FTD that allowed an unauthenticated attacker to conduct brute-force attacks against existing accounts, or in some configurations establish a clientless SSL VPN session. The common thread across the Cisco cases was the absence of MFA. Where a second factor was enforced, brute-forcing a password got the attacker nowhere. Where it was not, a weak or reused password was all that stood between them and the internal network.

What happens after they are inside

Understanding the post-access playbook matters because it gives you a second and third chance to catch an intrusion even if the perimeter fails. Across Akira engagements the sequence is remarkably consistent:

• Remote access tooling. Operators deploy legitimate remote management software such as AnyDesk, RustDesk, or LogMeIn so they have persistence that blends in with normal admin activity.
• Discovery. They run network scanners like Advanced IP Scanner and SoftPerfect, enumerate Active Directory, and identify backup servers and domain controllers.
• Credential theft. They dump LSASS memory for cached credentials, abuse Veeam backup configurations (the Veeam flaw CVE-2023-27532 exposes stored credentials), and grab anything that gives them domain admin.
• Lateral movement. RDP and SMB across flat internal networks let them reach every server quickly. Tools like PCHunter and PowerTool are used to disable security software.
• Exfiltration. Data leaves through rclone, WinSCP, or FileZilla to attacker-controlled storage, usually hours before encryption.
• Encryption. Files are encrypted, often with an .akira extension, and akira_readme.txt ransom notes are dropped. Volume shadow copies are deleted to block easy recovery.

The gap between initial access and encryption can be short, sometimes under a day, but it is not instantaneous. That window is where detection earns its keep.

Closing the perimeter doors

These steps are ordered by impact. If you do nothing else, do the first three.

1. Enforce MFA on every VPN account, with no exceptions

This single control would have stopped the majority of the brute-force and credential-replay intrusions I have seen. Every remote access account, including service accounts and break-glass accounts, needs a second factor. Push-based MFA is acceptable but be aware of push fatigue; number matching or a FIDO2 hardware key is stronger. After you enable it, audit for accounts that bypass it. A single exempted account is the one the operator will find.

2. Patch the appliance firmware and treat it as urgent

Build an inventory of every internet-facing edge device, the vendor, model, and current firmware version. Cross-check against the vendor advisories for the CVEs above and apply the latest stable firmware. Edge appliances are not part of most patch cycles because they are owned by networking rather than IT, which is exactly why they fall behind. Assign an owner and a recurring review.

3. Rotate credentials after patching

For SonicWall specifically, follow the vendor guidance: after upgrading, reset the passwords for all local SSL VPN users. More broadly, assume that any appliance which was exposed and unpatched for a meaningful period has had its credentials captured. Rotate them. Patching a compromised credential store without changing the credentials leaves the door open.

4. Restrict who can even reach the VPN

If your remote workforce connects only from known countries, geo-fence the VPN to those regions. Better still, restrict SSL VPN and management interfaces to an allowlist of known IP ranges where the business model allows it. The management interface of a firewall should never be exposed to the open internet, full stop. A login portal that an attacker cannot reach cannot be brute-forced.

5. Disable unused VPN and management services

If you are not using SSL VPN, turn it off. If a feature is enabled by default and unused, disable it. Reducing the exposed attack surface is the cheapest control you have, and it removes entire vulnerability classes in one step.

Building the inside defenses

Assume the perimeter will eventually be bypassed and make the attacker's post-access life difficult.

Segment the network

Flat networks are why Akira can go from one VPN session to full-domain encryption in hours. Separate user subnets from server subnets, put backup infrastructure in its own isolated segment, and restrict RDP and SMB between zones to only what is required. Lateral movement should generate friction and alerts, not glide unimpeded.

Protect and test your backups

Follow the 3-2-1-1 model: three copies of data, on two different media, one off-site, and one immutable or offline. Immutability matters because Akira operators specifically hunt for and delete backups, and they target Veeam. Patch your backup software, store backup credentials separately from the domain, and remove the backup server from the standard domain trust where possible. Most importantly, test a full restore on a schedule. A backup you have never restored is a hope, not a plan.

Deploy EDR and harden against credential theft

Endpoint detection and response on servers and workstations will flag LSASS dumping, the deployment of unexpected remote management tools, and the discovery scanners that precede encryption. Enable LSA protection (RunAsPPL) and Credential Guard on Windows to make credential dumping harder. Restrict and monitor the local administrator accounts; consider Microsoft LAPS so every machine has a unique local admin password.

Control remote management software

Akira's reliance on AnyDesk and RustDesk gives you a high-signal detection opportunity. If your organization standardizes on one remote tool, alert on the installation or execution of any other. Application control or allowlisting that blocks unsanctioned RMM binaries removes one of the operators' favorite persistence mechanisms.

What to watch in your logs

Detection of Akira-style intrusions is realistic if you are collecting and reviewing the right telemetry. Prioritize these signals:

• VPN logins from unusual locations or hosting ASNs. Authentications from cloud or residential proxy ranges, or impossible-travel patterns (a user in two countries minutes apart), are strong indicators.
• Successful VPN login after repeated failures on the same account, which suggests a brute force that finally succeeded.
• New remote management tools appearing on endpoints, especially on servers.
• Network scanning activity from internal hosts, such as a single workstation suddenly touching hundreds of internal addresses.
• Access to or deletion of volume shadow copies and backups. The command vssadmin delete shadows running anywhere in your environment is an emergency.
• Mass file modification with new or unusual extensions, which is the encryption phase itself.

Forward firewall and VPN authentication logs to a central system that retains them long enough to investigate. In several cases the only record of the initial access was in firewall logs that had already rolled over before anyone started looking.

If you suspect you are already in the window

If you see indicators that an intrusion is underway but encryption has not happened yet, you have a chance to break the chain. Isolate affected hosts from the network rather than powering them off, which preserves volatile evidence. Disable compromised accounts and force a password reset. Block the attacker's external IP addresses at the firewall. Do not delete logs or wipe systems in a panic, because you will need that data to understand scope. Engage incident response, whether internal or a retained firm, before you start remediating, so you do not tip off the operator or destroy the evidence you need to be sure they are gone.

A short checklist to run this week

• Inventory every internet-facing VPN and firewall, with model and firmware version.
• Confirm MFA is enforced on every remote access account, with zero exemptions.
• Patch to current firmware and rotate all local VPN credentials, SonicWall users especially.
• Remove the firewall management interface from public internet exposure.
• Verify your backups are immutable or offline, and run a test restore.
• Turn on EDR alerting for unauthorized remote management tools and LSASS access.
• Confirm VPN authentication logs are centralized and reviewed.

None of these defenses are exotic. That is the uncomfortable lesson of Akira. The group is not winning with novel exploits, although it uses them when available. It is winning because edge appliances go unpatched, credentials go un-rotated, and second factors go unenforced. The fixes are well understood. The work is in actually doing them, consistently, on the boxes that sit at the edge of your network and rarely get attention until the day they become the headline.