Akira Ransomware Bypasses EDR via Safe Mode After SonicWall VPN Attack

Published on 18 August 2026

An attacker simply logs in – no zero-day, no exploit, just guessed credentials. A few hours later he has read out your Active Directory, copied file shares to the cloud and switched off your security software by simply rebooting the server in safe mode. This exact sequence is at the heart of a recent ransomware incident documented by the security firm Huntress and reported by Security Affairs on 17 August 2026. For small and medium-sized enterprises with their own website and a SonicWall remote-access solution, this is a wake-up call – for several reasons.

What happened?

On 4 August 2026, a so-called Akira affiliate – a partner who deploys the Akira ransomware on commission or for a cut – gained access to a company's network. The point of entry was an internet-facing SonicWall SSL-VPN (an encrypted remote access channel through which employees dial into the corporate network from outside). Crucially: no two-factor authentication (MFA) was active for this access – meaning there was no second confirmation step in addition to the password.

The attacker used what is known as credential spraying: known or common passwords are tried automatically against many user accounts. This attack wave began at around 03:45 UTC, and by 03:52:42 UTC the first successful login had already succeeded. Important for context: in this particular case, no SonicWall vulnerability was exploited. There was no exploit, no specific vulnerable model and no named firmware level – the breach succeeded simply with valid credentials and without MFA protection.

After that, things moved fast and methodically:

• After just under two hours, the attacker switched via RDP (Remote Desktop, the graphical remote control of Windows) to the Domain Controller – the central server that manages user accounts and permissions in the corporate network.
• He exported comprehensive Active Directory data via PowerShell: user lists with group memberships, email addresses, phone numbers, timestamps of password changes and last logins, as well as computer lists with hostnames, operating systems and IP addresses.
• He archived mapped file shares with WinRAR and exfiltrated them using the tool s5cmd to an S3 bucket under his control (cloud storage at Amazon Web Services).
• Only afterwards was the actual encryption supposed to start.

The real trick: EDR evasion via safe mode

Before encrypting, the attacker installed the remote-maintenance software AnyDesk as a Windows service and configured it so that it also starts in safe mode with networking. Then came the central manoeuvre: via msconfig and a reboot, he forced the system into Safe Mode with Networking – safe mode with network access.

Why is this so dangerous? In safe mode, Windows deliberately loads only a minimal set of drivers and services. That is exactly what the attacker exploits: the Huntress EDR agent (EDR stands for "Endpoint Detection and Response", i.e. monitoring security software on the machine) and Microsoft Defender's real-time protection simply no longer started as a result. The watchers were blind.

This technique is catalogued in the MITRE ATT&CK framework as T1688 (Safe Mode Boot). James Northey of Huntress contextualises the incident as follows:

„After gaining access via an exposed SonicWall VPN, an Akira affiliate rebooted the victim host into Safe Mode with Networking to defeat EDR, a first for this ransomware variant in our telemetry.“ (James Northey, Huntress)

So this was the first time Huntress had observed this safe-mode technique with Akira in its own data.

Why the encryption failed – and why that's no comfort

In this particular case, the encryption failed. But not because a protective measure kicked in: the encryptor akira.exe started at 06:34:29 UTC, but in the stripped-down environment it produced virtual memory errors ("Virtual Memory Minimum Too Low" and "Out of Virtual Memory") and a PowerShell stack-guard error. Put simply: the ransomware ran out of working memory in the reduced environment.

A scheduled Defender scan did detect akira.exe at 07:43:50 UTC as Ransom:Win32/Akira.B!ibt, but with real-time protection disabled it could not clean up the file. Only after the return reboot into normal mode at 08:10:38 UTC was the quarantine achieved at 08:12:28 UTC. Huntress is unequivocal here:

„That's a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around.“ (James Northey, Huntress)

In other words: a lucky coincidence caused by a mistake by the attacker – not a protective effect you can rely on. With different memory conditions or an adapted encryptor, the next attempt could succeed.

And even this "luck" only prevents half the damage: the data – AD exports and file shares – had already been exfiltrated by that point. This enables what is known as double extortion: blackmail through the threatened publication of the stolen data, entirely regardless of whether encryption took place or not.

Who is affected?

Directly affected by this entry path are companies that operate a SonicWall SSL-VPN – themselves or via their IT/hosting provider – for administration, backups, file shares or domain access, especially if it is reachable without consistent MFA.

Important: the website itself was not the point of entry in this report. For website operators, the case is relevant if such remote-access infrastructure is used in the background – for example for server administration or backup access. According to CISA and the FBI, Akira targets above all small and medium-sized enterprises, but has also hit larger organisations.

To put the environment into perspective: CISA/FBI put the ransomware proceeds claimed by Akira through the end of September 2025 at around 244.17 million US dollars. The BSI reports, per the BKA, 950 reported ransomware attacks for the period 1 July 2024 to 30 June 2025, with the greatest damage still resulting from ransomware in combination with data leaks.

A word about CVE-2024-40766

In earlier Akira-SonicWall campaigns, the vulnerability CVE-2024-40766 played a role – a flaw in the access control of the SonicOS Management Access. SonicWall published it on 23 August 2024, and CISA added it to its catalogue of known exploited vulnerabilities on 9 September 2024. Affected are SonicOS levels up to and including 5.9.2.14-12o, 6.5.4.14-109n and 7.0.1-5035.

However: Huntress does not name CVE-2024-40766 as the cause of the August 2026 case. That case was demonstrably based on credential spraying against an MFA-less VPN. For the related SSL-VPN threat activity of 2025, SonicWall itself stated:

„We now have high confidence that the recent SSLVPN activity is not connected to a zero-day vulnerability. Instead, there is a significant correlation with threat activity related to CVE-2024-40766.“ (SonicWall)

Nevertheless, you should check CVE-2024-40766 against your own environment – it is a separate, actively exploited problem.

How to check whether you are affected

1. Take stock of remote access: Clarify with your IT team or your MSP/hosting partner whether a SonicWall firewall offers an SSL-VPN and whether the management interface or SSL-VPN are reachable from the internet.
2. Document model and firmware: For each SonicWall generation, note the exact SonicOS build and compare it with the SonicWall PSIRT advisory and the CVE register (affected by CVE-2024-40766: up to 5.9.2.14-12o, 6.5.4.14-109n, 7.0.1-5035). Check whether a Gen-6-to-Gen-7 migration carried over local accounts without a password reset.
3. Verify MFA: Check technically for every VPN account – especially administrators, external service providers and local SSL-VPN accounts – whether MFA is actually enforced and not merely optional. Review strong password policies, removed inactive accounts and working lockout thresholds.
4. Search logs for credential spraying: In SonicWall/SIEM logs, look for bursts of failed logins against multiple accounts, followed by a successful login from the same source IP – in this case from 2026-08-04. A missing hit does not, due to limited retention, prove the all-clear.
5. Look for safe-mode traces: Check for boot-configuration changes via msconfig.exe or bcdedit, for Kernel-Boot Event ID 27 with SAFEBOOT:NETWORK, Kernel-General Event ID 12 with BootMode=2, stopped security services, and new entries under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot.
6. Look for attacker artefacts: Check domain controllers and application servers for C:\ProgramData\AdUsers.txt and C:\ProgramData\AdComp.txt, unusual WinRAR archives of shares, s5cmd execution, newly installed AnyDesk instances or ones registered as a safe-boot service, and outbound S3 transfers. The named hashes: 414b9985f46714f44dd1bd63860d2a48dcfababcfe5c712a4b4f575378127a56 (akira.exe) and e2356c742c74cce5c6b6100162d0071a3f71e2fed2ed895c2011061a95b3299a (S5cmd.exe).
7. If you find a hit: Treat the environment as a possible incident. Do not hastily clean or reboot systems, restrict external access in a controlled manner, secure logs, and immediately involve qualified incident-response support as well as data-protection officers.

What you need to do now

1. Enforce MFA for all VPN and privileged accounts without exception. CISA/FBI prioritise phishing-resistant MFA; the BSI recommends remote access only via VPN in combination with two-factor authentication. This exact step would have made the documented entry considerably harder.
2. Disable unneeded SSL-VPN. If it is indispensable, restrict access to an IP allowlist or trusted management networks and enable botnet and geo-IP filters as well as account lockout in accordance with the vendor documentation.
3. Reset and rotate credentials. Reset local SSL-VPN passwords, remove unused accounts and, if suspicious activity is present, rotate all VPN and AD credentials. If you find AdUsers.txt or AdComp.txt, the information they contain is to be considered exposed.
4. Establish risk-based patch management with short deadlines for exposed firewalls, VPN gateways and web servers. Check CVE-2024-40766 against your SonicOS version and implement the latest vendor guidance; if no mitigation is available, the function must be taken out of service.
5. Set up central log analysis. Forward SonicWall VPN, Windows and EDR logs to a SIEM or a monitored log service and alert on credential-spraying patterns, successful logins after failed attempts, RDP access to domain controllers, bulk AD queries, safe-mode boots, BCD/registry changes, service installations and unusual cloud uploads.
6. Limit the consequences of a successful login: separate administration accounts from everyday accounts, protect privileged accounts with MFA, harden Active Directory, segment networks and restrict write permissions on file shares. The BSI explicitly emphasises network segmentation and AD hardening.
7. Keep offline backups and test recovery. Backups limit the consequences of an outage but do not prevent data-leak extortion – which is why you also need egress controls, logging and incident response.
8. Incorporate data-protection steps into the emergency plan: responsibilities, contact with the data-protection authority, evidence preservation, risk analysis, a draft notification and informing processors must be clarified in advance so that the 72-hour deadline can be met.

GDPR: Why the data exfiltration matters – even without encryption

If the exfiltrated AD exports or file shares contained personal data, there is in principle a personal data breach through unauthorised access and disclosure. The European Data Protection Board (EDPB) makes clear: an impairment of confidentiality, integrity or availability – and ransomware encryption itself – can also be a data breach. A data exfiltration is therefore not the only triggering threshold.

Every incident must be documented. If a risk to the rights and freedoms of natural persons is likely, the competent authority must be informed without undue delay and, where feasible, within 72 hours of becoming aware; delays must be justified. If there is a high risk, the affected individuals must be notified without delay. Processors – such as hosters – must inform the controller without undue delay.

Because of the exfiltration of AD data and shares documented here, an individual, documented risk analysis is mandatory. Whether a notification actually has to be made depends on the nature, scope, encryption and sensitivity of the specifically affected data. The notification must include at least the nature of the incident, where possible the categories and approximate numbers of affected persons/records, the contact point, the likely consequences, and remedial measures.

On the fines framework: breaches of obligations under Articles 25 to 39 GDPR – including the security obligation (Art. 32) and the notification obligation (Art. 33) – can, under Art. 83(4) GDPR, amount to up to 10 million euros or 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher. As an example of mitigating factors: in 2018, the LfDI Baden-Württemberg imposed a fine of 20,000 euros after a hacker attack that exfiltrated data of around 330,000 users, and treated transparent cooperation and comprehensive security improvements as significantly mitigating. This case is neither Akira- nor VPN-specific and does not allow any prediction for other circumstances.

Conclusion

This incident reveals two uncomfortable truths. First: attackers don't need a spectacular zero-day when a remote-access channel stands open without MFA – guessed credentials are enough. Second: even good security software can be defeated by an attacker booting the server into safe mode and thereby preventing the watchers from loading in the first place.

That the encryption here failed only due to a lack of memory is luck – not protection. The truly critical stage, the theft of credentials and files, had long since taken place. For German SMEs, this means specifically: enforce MFA everywhere, minimise exposed VPNs, log centrally, test offline backups and prepare the GDPR emergency process. Those who implement these basics now make their organisation a considerably less attractive target – before the next attacker simply logs in.