Akira ransomware affiliates now reboot compromised Windows machines into Safe Mode with Networking to knock endpoint detection offline. Huntress investigated an incident where the operator ran msconfig.exe to force the reboot instead of trying to kill security agents directly. Both the Huntress agent and Microsoft Defender's real-time protection stopped running, which gave the attacker a window to work on the host with no endpoint defenses watching. Details in this article come from analysis published by CSO Online.

Safe Mode loads only essential drivers and services, and most third-party security products are excluded from that minimal startup set. That is the entire point of the technique. Your EDR is installed, licensed, and correctly configured, and it still produces no telemetry because Windows never started it.

The intrusion started on August 4 with credential spraying against an exposed SonicWall SSL VPN. Huntress analyst James Northey reported that the attacker authenticated successfully to an account that had no MFA enabled.

About seven minutes passed between the first failed login attempts and a successful authentication to an unprotected account.

From there the operator worked quickly. Two hours after logging in, they reached the domain controller over RDP, ran extensive Active Directory enumeration, then moved to an application server and archived mapped file shares with WinRAR. The archives went to an attacker-controlled S3 bucket using s5cmd, which supplied the data-theft half of a double-extortion case. AnyDesk was then installed for persistent remote access and to stage the Akira payload.

The attackers also anticipated that AnyDesk would not run in Safe Mode, so they added the remote-access service to the Safe Boot registry configuration to keep their access alive through the reboot. Huntress says this is the first time it has observed Akira using Safe Mode boot, tracked by MITRE ATT&CK as T1688, Impair Defenses: Safe Mode Boot. For your firm, the practical consequence is that data left the network before any encryption was attempted, so an extortion demand follows even if files stay readable.

Attack Chain: Initial Access Through Credential Compromise to Safe Mode Execution

The intrusion started on August 4 with credential spraying against an internet-exposed SonicWall SSL VPN. Roughly seven minutes after the failed login attempts began, the operator authenticated successfully to an account with no multi-factor authentication enabled. That single gap converted a noisy brute-force attempt into a valid session, and every action that followed carried the authorization of a legitimate user.

The forensic marker for this stage is the pairing itself: a burst of failed VPN authentications followed within minutes by a success on one of the sprayed accounts, from the same source. On its own, a successful VPN login generates no alert. In context, it is the first and cleanest indicator in the entire chain.

Two hours passed between authentication and the next observed activity. The operator then reached the domain controller over RDP and ran extensive Active Directory enumeration, mapping accounts, groups, and trust relationships before touching anything else. Reconnaissance against a domain controller from a VPN-assigned address is rarely normal traffic, and the enumeration volume left artifacts on the DC itself.

From there the operator pivoted to an application server and began collection. Mapped file shares were archived with WinRAR, and the resulting archives were pushed to an attacker-controlled S3 bucket using s5cmd, a fast command-line S3 client. That is the exfiltration half of a double-extortion operation, and it completed before any encryption attempt. Data leaves the environment first, which means the extortion leverage exists whether or not the ransomware ever runs.

Stage-by-stage artifacts worth pulling during an investigation of this pattern:

• Initial access: VPN authentication logs showing failed-then-successful sequences on non-MFA accounts
• Discovery: RDP session establishment to the domain controller followed by bulk AD query activity
• Collection: WinRAR process execution on a file or application server, with archive files staged against mapped share paths
• Exfiltration: s5cmd execution and outbound connections to S3 endpoints that have no business relationship with your environment
• Persistence: AnyDesk installation and service registration on the target host

AnyDesk gave the operator remote access independent of the compromised VPN account, and served as the delivery channel for the ransomware payload. The operator anticipated a problem with the next step and solved it in advance: additions were made to the Safe Boot registry configuration so the AnyDesk service would start in an environment that normally excludes it. Those registry additions are a high-fidelity artifact. Legitimate administration almost never writes third-party remote-access services into the Safe Boot key set.

Boot configuration tampering is tracked by MITRE ATT&CK as T1688, Impair Defenses: Safe Mode Boot, and the same behavior appears in Snatch and AvosLocker intrusions going back years. Command-line boot editors such as bcdedit serve the same purpose, so both the GUI and CLI paths belong in your timeline reconstruction.

Execution of akira.exe in the reduced environment produced its own evidence trail. The host logged Virtual Memory Minimum Too Low and Out of Virtual Memory errors, followed by PowerShell failures, as the encryptor exhausted available memory. Defender identified the binary but could not act on it, and quarantine only completed after the operator returned the machine to normal boot.

Huntress notes that the encryption failure came from Akira's resource requirements. More memory, a larger page file, or a revised encryptor changes that outcome, so the memory errors are a forensic detail rather than a defensive property.

Why Safe Mode Deployment Defeats Standard EDR and Backup Protections

Safe Mode with Networking loads only the drivers and services Windows considers essential to boot, and that minimal set excludes most of the software you rely on to see and stop an attack. Your EDR sensor, your antivirus filter driver, and in many environments your backup agent and shadow copy service all sit outside that list. They remain installed and licensed on the disk while the host runs without them.

The Huntress case shows the attacker treated that exclusion as a configuration problem to be managed, not a coin flip. Expecting AnyDesk to be dropped from the minimal startup set alongside the security tools, the operator edited the Safe Boot registry configuration so the remote-access service would launch anyway. The practical result for the victim: the intruder kept an interactive remote session on a domain-joined host while every defensive agent on that host was inert.

That asymmetry defines the window. From the moment the machine comes back up in Safe Mode until someone returns it to a normal boot, your security console receives nothing from that endpoint. A sensor that stops checking in reads the same as a laptop that was powered off, a server mid-patch, or a NIC that dropped, which is why the gap can sit open through an entire night shift without anyone treating it as an incident.

What happened next in this intrusion is the detail worth carrying to your leadership. Microsoft Defender did identify the Akira binary on disk, and it still could not act on it, because remediation depends on real-time protection that Safe Mode had already taken offline. The file was quarantined only after the operator rebooted back into normal Windows. Detection without the ability to remediate produces an alert record and an encrypted file share, which is the worst of both outcomes for your incident timeline.

Encryption failed here for reasons that have nothing to do with your controls. The system threw Virtual Memory Minimum Too Low and Out of Virtual Memory errors after akira.exe launched, followed by PowerShell failures, because Safe Mode's constrained environment could not satisfy the encryptor's resource demands. Huntress is explicit that this is a side effect of Akira's memory requirements and not a defense you can plan around. A host with more RAM, a larger page file, or a tuned encryptor build changes the result.

Even in the failure case, the extortion leverage was already in place. The data theft finished before the reboot, so the operator held the files regardless of whether the encryption stage completed. If you restore cleanly from backups, you recover availability and you still face a disclosure claim, the associated notification obligations, and negotiation pressure that has nothing to do with your recovery time objective.

Think about which of your systems would produce the worst outcome under those conditions. Domain controllers, file servers, hypervisor hosts, and backup servers are the hosts where an attacker gains the most from a period of unmonitored access, and they are also the hosts where an unexplained reboot is least likely to be questioned. If your backup agent and your EDR both live outside the Safe Boot service list on those machines, a single reboot removes your prevention layer and your recovery layer in the same step.

Detection and Immediate Response Actions for Akira Safe Mode Reboots

The single highest-value detection here is the boot configuration change, because it happens while the host is still running normally and still has endpoint visibility. Alert on any execution of bcdedit.exe carrying a safeboot argument, such as bcdedit /set {default} safeboot network, and on msconfig.exe launching on a server. Neither belongs in routine server administration, and both give you a window to act before the reboot removes your sensors from the picture.

Pair that with write monitoring on the Safe Boot registry configuration under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot. New service entries added there are the operator preparing a remote-access tool to survive the minimal startup set, which is a step no administrator performs during normal maintenance.

In environments Capstone manages, SentinelOne flags the endpoint-protection tampering and boot-configuration changes described above and can isolate the host at that stage, before the encryptor stages on disk.

For the next 24 hours, work through a short list:

• Search your endpoint telemetry for bcdedit and msconfig.exe executions across all servers and workstations for the past 30 days.
• Query the Windows System log for boot type transitions showing a host started in Safe Mode without a corresponding change ticket.
• Pull AnyDesk connection logs from every host where the client is installed, and confirm each inbound session maps to a known technician and a known source address.
• Network-isolate any host showing an unexplained Safe Mode boot rather than rebooting it, so you preserve the disk state for investigation.
• Alert on security service stop events, since agents going quiet in a cluster across several hosts is the same signal in a different form.

Over the next one to two weeks, shift to coverage and account questions. Reconcile your EDR install list against your asset inventory and find the hosts with no sensor at all, since an operator who cannot reach a monitored machine will look for an unmonitored one. Review privileged account usage on domain controllers and application servers, focusing on accounts that authenticated interactively from a VPN session, and confirm each one still needs the access it holds.

Also test what your own tooling actually does in this scenario. Boot a lab host into Safe Mode with Networking and watch which agents, log forwarders, and backup services start. Adlumin monitoring covers the identity side of the same intrusion, correlating a burst of failed remote-access authentications with a subsequent success on one of the sprayed accounts, so credential abuse surfaces as an alert instead of a normal-looking login.

Longer term, restrict who can reach this technique at all. Group Policy and application control can block bcdedit.exe and msconfig.exe for standard users and limit them to a named administrative group on servers. Enforce UEFI Secure Boot so boot-time changes are constrained and auditable, and require multi-factor authentication on the remote-access tools themselves, not only the VPN, so an installed AnyDesk or similar client does not become an unauthenticated back door.

Treat the encryption failure Huntress observed as a coincidence of resource limits, not a control. More memory, a larger page file, or a revised encryptor changes that outcome. Your detection needs to fire on the boot configuration change, and your response needs to isolate the host before it restarts.

Hardening Windows Boot and Limiting Remote Access Tools

The control with the best return here is application allowlisting on servers. The operator in the Huntress case did not need a custom loader for persistence, they installed AnyDesk on the host and used it as their remote hands. If WDAC or AppLocker runs in enforce mode on your domain controllers, application servers, and file servers with publisher-based rules, an unapproved remote access binary never executes, no matter which account launched it.

Pick one supported remote support tool, sign the policy to allow only that publisher, and treat every other RMM agent as unauthorized software. This also removes a category of shadow IT that helpdesk teams accumulate over years, so you get inventory cleanup alongside the security benefit.

Back that with egress filtering on server VLANs. Data theft is the half of double extortion that still hurts you even when encryption fails, so cutting the outbound path limits the damage independently of whether the payload runs.

Setting a safeboot flag and writing new service entries under the Safe Boot key both require local administrator rights on the host. That makes standing admin access the real enabler of MITRE technique T1688, and reducing it is more effective than any single boot setting:

• Remove day-to-day accounts from the local Administrators group on servers and enforce unique, rotated local admin passwords through LAPS.
• Move privileged credentials into a vault with checkout approval and time-bound elevation, so a stolen VPN session does not carry a reusable domain admin password with it.
• Apply a tiered model in Group Policy using Deny log on through Remote Desktop Services to stop server and workstation admin accounts from authenticating to domain controllers at all.

Enable Secure Boot and set a UEFI firmware password with a locked boot order on every server you can reach, including hypervisor hosts. That prevents booting alternate media and unsigned bootloaders. It does not stop an administrator from flipping a safeboot flag inside a running Windows install, which is exactly why the privilege work above comes first.

Restrict administrative access to domain controllers to a single hardened jump host, enforced at the network layer rather than by convention. RDP into a domain controller from a general-purpose application server should fail at the firewall. Segment file servers away from user subnets, restrict server-to-server SMB with host firewall rules, and review which service accounts can mount mapped shares in bulk. An operator who lands on one application server should not be able to enumerate and archive everything the organization stores.

For recovery, keep at least one copy of your data where a compromised host cannot reach it. N-able Cove holds backups in cloud storage separate from the protected server across managed environments, so restore capability does not depend on a local agent that Safe Mode leaves out of the startup set. Test restores on a schedule and document how long a full file server rebuild actually takes, because that number is what determines your downtime if an encryptor does complete.

Order of work: allowlisting and egress rules first because they deploy quickly and block the tooling, then local admin reduction and credential vaulting, then segmentation and firmware settings as scheduled maintenance.

Key Takeaway: Safe Mode as an EDR Bypass Requires Multi-Layer Defense

The core risk here is structural. Your endpoint sensors are software that Windows chooses whether or not to start, and Safe Mode is a supported boot path that leaves most of that software on disk and unloaded. MITRE tracks the behavior as T1688, Impair Defenses: Safe Mode Boot, and Snatch and AvosLocker operators have used it for years, so this is a known Windows design being applied by a new family.

Do not read the encryption failure in this case as a control. Huntress was explicit that the virtual memory errors that stalled the encryptor were a side effect of Akira's resource demands inside a stripped-down boot environment, not a dependable defense. A larger page file, more RAM, or a revised encryptor changes that outcome, and the same operator playbook then works end to end.

The more important point for your risk calculation is that the encryption failing did not undo the intrusion. The archived file shares were already staged and pushed to attacker-controlled cloud storage before the reboot happened, so the extortion leverage existed regardless of whether a single file was encrypted. If you measure a ransomware incident only by whether files came back, you will understate what this kind of compromise costs you.

Every step in this chain depended on the operator holding a valid account with administrative rights on the host. Safe Mode boot, remote access tool installation, and boot configuration changes are all privileged operations. Your operational priority is knowing which accounts in your environment can reach servers without MFA, and where remote access agents such as AnyDesk are running outside your approved list.