Akira Ransomware Is Rocketing Through SonicWall SSL VPNs (Even with MFA)

TL/DR:
Since late July 2025, Akira affiliates have ramped up intrusions via SonicWall SSL VPN logins, often bypassing OTP-based MFA—likely using stolen OTP seeds. Dwell time can be under one hour from VPN login to ransomware deployment. Patch CVE-2024-40766, reset VPN credentials, revoke/replace OTP seeds, and enforce network segmentation with per‑app MFA (not just VPN). Monitor for anomalous VPN logins and lateral movement within minutes of authentication.

What we’re seeing

• Akira’s playbook: security researchers observed a surge of malicious SSL VPN logins targeting SonicWall firewalls, with “smash-and-grab” speed—ransomware in an hour or less after initial access [1].
• MFA isn’t saving victims: multiple reports show successful logins despite OTP‑MFA, with researchers assessing attackers are using previously stolen OTP seeds to generate valid codes [2].
• Root of access: SonicWall states recent SSLVPN activity correlates with CVE‑2024‑40766 (Improper Access Control) disclosed in 2024—not a new zero‑day—meaning unpatched or historically compromised devices are high‑risk [3].
• Related activity: Google’s Threat Intelligence Group documented UNC6148 targeting fully patched, end‑of‑life SMA 100 series boxes and re‑using stolen credentials/OTP seeds—consistent with today’s Akira intrusions [4].

What is CVE‑2024‑40766?
An improper access control flaw in SonicOS (Gen 5/6 and certain Gen 7 versions) affecting management access and SSLVPN. It can allow unauthorized resource access (and under conditions, a device crash). It was added to CISA’s Known Exploited Vulnerabilities list in 2024 and is widely tracked by vendors [3][5].

Why orgs still get hit after patching

• Credential/seed theft lag: attackers who harvested usernames, passwords and OTP seeds earlier can walk in later even after firmware updates [2][4].
• EOL appliances: SMA 100 series devices at end‑of‑life lack long‑term hardening and visibility; threat intelligence reports tailored backdoors on such devices [4].
• EDR blind spots: network appliances rarely run endpoint agents; post‑VPN activity can go unnoticed until encryption starts [1].

Likely MITRE ATT&CK chain

• T1133 – External Remote Services: SSL VPN access [1].
• T1078 – Valid Accounts: use of stolen credentials/OTP seeds [2].
• T1021/T1046 – Lateral Movement/Discovery within minutes of login [1].
• T1486 – Data Encrypted for Impact: Akira payload execution.

Fast triage (first 60 minutes)

1. Block & reset: disable SSLVPN for affected realms; force password resets and re‑enroll OTP seeds (not just regenerate recovery codes) [2].
2. Session hunt: pull VPN logs for bursts of logins from new ASNs/geo locations, especially followed by SMB/RDP authentications or domain controller queries within less than an hour [1].
3. Endpoint sweep: look for Akira TTPs (shadow copy deletion, backup tampering) on first‑hopped hosts.
4. Patch posture: validate firmware against 40766‑fixed releases on all Gen 5/6/7; prioritize internet‑exposed portals [3][5].

Containment & hardening (short term)

• VPN posture: enforce per‑app or zero trust network access (don’t treat “VPN = trusted”). Restrict portals by source IP and device posture; monitor failed OTP attempts per account. Expire all OTP seeds on portals that were internet‑exposed during 2024‑2025; re‑issue via hardware tokens where possible [2][4].
• Identity & auth: require phishing‑resistant MFA (WebAuthn) for admin access; ban SMS/voice OTP for VPN. Add impossible‑travel and MFA‑fatigue detections to VPN auth logs.
• Network controls: segment domain controllers and file servers; block lateral RDP by default. Rate‑limit or temporarily disable high‑risk service accounts discovered post‑login.
• Backups: verify offline backups and test restore; enforce write‑once snapshots.
• Monitoring: alert on post‑VPN spikes such as lsass.exe access, shadow copy deletions, mass file renames and encryption notes.

Medium‑term actions

• Replace end‑of‑life SMA 100 appliances; adopt centralized logging for all edge devices [4].
• Implement passwordless authentication for admins; require step‑up MFA for sensitive apps.
• Tabletop an “hour‑to‑impact” scenario specific to Akira’s tempo.

FAQs your execs will ask
Is this a new zero‑day?
SonicWall says recent SSLVPN activity maps to CVE‑2024‑40766, not a new zero‑day. Many incidents likely involve stolen credentials or OTP seeds [3][2].

Why did MFA fail?
If OTP seed material is stolen, attackers can generate valid codes indefinitely until seeds are re‑issued—password resets alone won’t help [2][4].

How fast can this move?
Reported dwell time can be less than one hour from login to encryption—plan for minutes, not days [1].

References
[1] ThaiCERT – “Akira ransomware attacks SonicWall VPN devices and bypasses MFA by using stolen one‑time password seeds” (https://www.thaicert.or.th/papers/20250910.html)
[2] Smarter MSP – “Akira ransomware campaigns abusing SonicWall VPNs: MFA bypass and response checklist” (https://smartermsp.com/akira-ransomware-and-sonicwall-mfa-bypass/)
[3] BleepingComputer – “SonicWall: Akira ransomware breaches SSLVPN via CVE‑2024‑40766; this is not a zero‑day” (https://www.bleepingcomputer.com/news/security/akira-ransomware-breaches-sonicwall-cve-2024-40766/)
[4] Google Threat Intelligence – “UNC6148 targeting EOL SonicWall SMA 100 devices with stolen credentials and OTP seeds” (https://cloud.google.com/blog/products/identity-security/unc6148)
[5] NVD – Vulnerability detail for CVE‑2024‑40766 (https://nvd.nist.gov/vuln/detail/CVE-2024-40766)
[6] BleepingComputer – “SonicWall clarifies no zero‑day after Akira ransomware attacks” (https://www.bleepingcomputer.com/news/security/sonicwall-clarifies-no-zero-day-after-akira-ransomware-attacks/)