Akira Ransomware Affiliate Uses Safe Mode with Networking to Bypass EDR — Detection and Hardening Guide

In a recent Akira ransomware intrusion investigated by incident responders, an affiliate executed one of the most brutally simple EDR evasion techniques in the playbook: they restarted a compromised Windows endpoint into Safe Mode with Networking, effectively neutering the installed endpoint detection and response solution, and then proceeded to exfiltrate sensitive data over the still-active network connection.

The twist in this case — and the only reason the victim dodged catastrophic impact — is that the attackers failed to complete the encryption phase. Data was stolen, but the ransomware payload never successfully detonated. Under Akira's double-extortion model, that still means a data breach, potential leak-site publication, and regulatory exposure. This was not a win. It was a near-miss that defenders should treat as a full-severity incident.

If your detection strategy assumes your EDR agent is always running, this incident is your wake-up call. Safe Mode evasion is a well-documented technique (used historically by Snatch, REvil, and BlackMatter operators, and now actively wielded by Akira affiliates), and it defeats a meaningful percentage of endpoint security stacks because most security services and drivers simply do not load in Safe Mode.

Technical Analysis

How the Attack Works

Safe Mode is a diagnostic boot configuration in Windows that starts the operating system with a minimal set of drivers and services. Critically:

• Most third-party EDR/AV services do not start in Safe Mode. Unless the vendor has explicitly registered its drivers and services under the Safe Boot configuration keys (HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal and ...\Network), the sensor never loads.
• Safe Mode with Networking (safeboot: network) loads network drivers and services — giving the attacker exactly what they need: a running OS, access to the file system, and outbound connectivity, all without the EDR watching.

The attack chain observed in this incident follows a consistent pattern:

1. Initial access and privilege escalation — Akira affiliates commonly gain entry via compromised VPN credentials (particularly on edge appliances without MFA), exposed RDP, or valid accounts. Administrative privileges on the endpoint are required to modify boot configuration.
2. Boot configuration tampering — The attacker modifies the Boot Configuration Data (BCD) store to force a Safe Mode with Networking boot on next restart. This is typically done with bcdedit.exe /set {current} safeboot network or via the msconfig.exe GUI (Boot tab → Safe boot → Network).
3. Forced reboot — The system is restarted, either gracefully (shutdown /r) or abruptly. On reboot, the EDR agent does not load.
4. Exfiltration and attempted encryption — With the sensor blind, the attacker stages and exfiltrates data (Akira affiliates favor tools like Rclone, WinRAR/7-Zip for staging, and FileZilla/WinSCP for transfer) and then attempts to run the Akira encryptor.

In this engagement, the encryption stage failed — meaning the victim retained data availability but still suffered a confirmed data theft. The organization was left in the double-extortion blast radius regardless.

Why This Defeats Most Endpoint Stacks

The uncomfortable truth: Safe Mode evasion works against a large share of deployed EDR products. Vendors differ on whether their sensors register for Safe Boot operation, and even those that do may run with reduced telemetry in that mode. The technique requires no exploit, no driver abuse (BYOVD), no signed-binary tricks — just native Windows functionality and local admin rights. That makes it attractive, reliable, and cheap.

Exploitation Status

This is confirmed active, in-the-wild tradecraft by Akira ransomware affiliates — not theoretical. Akira remains one of the most prolific ransomware operations targeting small-to-midsize enterprises, and its affiliates have repeatedly demonstrated willingness to use low-sophistication, high-effectiveness evasion. There is no CVE associated with this technique; it abuses intended Windows behavior, which is precisely why configuration hardening and behavioral detection — not patching — are the correct defensive responses.

Detection & Response

The good news: this technique is loud if you're watching the right telemetry. Modifying the BCD store, forcing a reboot, and booting into Safe Mode all generate distinct, high-fidelity signals. A machine that reboots into Safe Mode with Networking outside of a documented change window should page your on-call responder — full stop.

Sigma Rules

---
title: BCD Modified to Enable Safe Mode Boot
description: Detects modification of the Boot Configuration Data store to enable Safe Mode or Safe Mode with Networking, a known Akira ransomware affiliate technique to bypass EDR solutions that do not load in Safe Mode.
id: 8f2c1a94-3b7e-4d5a-9c61-7e4f2b8d0a15
status: experimental
author: Security Arsenal
date: 2026/01/15
references:
  - https://attack.mitre.org/techniques/T1562/001/
  - https://www.bleepingcomputer.com/news/security/akira-hackers-disable-edr-with-safe-mode-steal-data-but-fail-to-encrypt/
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\bcdedit.exe'
  selection_cmd:
    CommandLine|contains:
      - 'safeboot'
      - 'safebootalternateshell'
  condition: selection_img and selection_cmd
falsepositives:
  - Legitimate IT troubleshooting or OS recovery operations — these should be rare, ticketed, and verifiable
level: high
---
title: Suspicious Forced System Restart Following Admin Tool Activity
description: Detects shutdown or restart commands with short timeouts and no user-facing warning, consistent with ransomware operators forcing a reboot into Safe Mode after tampering with boot configuration.
id: 3d9e6b27-1f48-4c2a-b794-5a1c8e3d6f92
status: experimental
author: Security Arsenal
date: 2026/01/15
references:
  - https://attack.mitre.org/techniques/T1529/
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\shutdown.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_cmd:
    CommandLine|contains:
      - '/r /t 0'
      - '/r /f /t'
      - 'Restart-Computer'
      - '-Force'
  condition: selection_img and selection_cmd
falsepositives:
  - Patch management and software deployment tooling (SCCM, Intune, RMM platforms) — filter by known service accounts and parent processes
level: medium
---
title: MSConfig Launched Interactively for Boot Modification
description: Detects execution of msconfig.exe, which can be used to configure Safe Mode boot via the GUI. Rare in normal end-user activity and noteworthy on servers and workstations in ransomware pre-encryption staging.
id: 6b4a2e18-9d35-4f7c-a852-1c9e4b7a3d06
status: experimental
author: Security Arsenal
date: 2026/01/15
references:
  - https://attack.mitre.org/techniques/T1562/001/
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\msconfig.exe'
  filter_admin_tools:
    ParentImage|endswith:
      - '\msiexec.exe'
      - '\TiWorker.exe'
  condition: selection and not filter_admin_tools
falsepositives:
  - Helpdesk troubleshooting of boot or startup issues
level: low

KQL Hunt — Microsoft Sentinel / Defender

This query hunts for boot-configuration tampering and suspicious reboot chains in a single pass. Run it across the last 14 days, then operationalize the BCD tampering portion as a scheduled analytic rule with high severity.

// Hunt: Safe Mode EDR bypass pre-staging — BCD tampering and forced reboots
let Lookback = 14d;
let BCdtampering = DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where FileName =~ "bcdedit.exe"
| where ProcessCommandLine has_any ("safeboot", "safebootalternateshell")
| project BCDTime = Timestamp, DeviceName, DeviceId, AccountName, ProcessCommandLine, InitiatingProcessAccountName, InitiatingProcessCommandLine;
let ForcedReboots = DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where FileName =~ "shutdown.exe" and ProcessCommandLine has_any ("/r", "-r")
| project RebootTime = Timestamp, DeviceName, DeviceId, ShutdownCmd = ProcessCommandLine, AccountName;
BCdtampering
| join kind=inner ForcedReboots on DeviceId
| extend TimeDeltaMinutes = datetime_diff("minute", RebootTime, BCDTime)
| project BCDTime, RebootTime, TimeDeltaMinutes, DeviceName, BCDAccount = AccountName, ProcessCommandLine, InitiatingProcessAccountName, InitiatingProcessCommandLine, ShutdownCmd
| order by BCDTime desc;
// Standalone variant for environments ingesting via SecurityEvent (4688)
// SecurityEvent
// | where TimeGenerated > ago(Lookback)
// | where Process has "bcdedit.exe" and CommandLine has "safeboot"
// | project TimeGenerated, Computer, Account, CommandLine, ParentProcessName
// | order by TimeGenerated desc

Velociraptor VQL Hunt

Use this artifact to sweep your fleet for live evidence of BCD tampering — both active command execution and the resulting boot state — plus any systems currently running in Safe Mode (a system in Safe Mode with an active user session during business hours is an incident, not a curiosity).

-- Hunt: Safe Mode EDR bypass artifacts
-- 1) Live processes modifying boot configuration or forcing reboots
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)safeboot|safebootalternateshell'
   OR (Name =~ '(?i)shutdown.exe' AND CommandLine =~ '(?i)/r|restart')

-- 2) Check current BCD state on each endpoint for safeboot flags
LET bcd = SELECT Stdout FROM execve(argv=['bcdedit.exe', '/enum', '{current}'])
SELECT Stdout,
       if(condition=Stdout =~ '(?i)safeboot',
          then='ALERT: safeboot flag present in BCD',
          else='OK') AS SafeBootState
FROM bcd

Note on the second query: pair the VQL with a host check for whether the machine is currently in Safe Mode. From a forensics standpoint, also review Windows.System.Boot artifacts and Event ID 1074 (user-initiated shutdown with reason/process), 6006 (clean shutdown), and 6008 (unexpected shutdown) in the System log around any suspected reboot.

Remediation and Hardening

Immediate Actions (If You Suspect This Technique Was Used)

1. Treat any unexplained Safe Mode boot as a security incident. Pull the host off the network (do not reboot it — preserve memory and boot artifacts), and investigate what executed while the EDR was blind. Check for staging archives, Rclone/FileZilla artifacts, and unusual outbound traffic during the Safe Mode session via firewall and proxy logs — your network telemetry becomes your primary source of truth when the endpoint sensor was dark.
2. Audit the BCD store fleet-wide for lingering safeboot flags. The script below does this at scale.
3. Review egress for exfiltration. In this incident the encryption failed — the exfiltration did not. Assume data theft occurred and scope it against NetFlow, proxy, and DNS logs.

Hardening Script

# Audit BCD store for safeboot flags and remove unauthorized Safe Mode boot config
$bcdOutput = bcdedit /enum '{current}'
if ($bcdOutput -match 'safeboot') {
    Write-Warning "safeboot flag detected on $env:COMPUTERNAME — investigating and removing"
    bcdedit /deletevalue '{current}' safeboot
    bcdedit /deletevalue '{current}' safebootalternateshell
    # Log to a central location for IR correlation
    "$((Get-Date).ToString('u')) - safeboot flag removed on $env:COMPUTERNAME" |
        Out-File -Append '\\your-log-share\safeboot-alerts.log'
} else {
    Write-Output "OK: no safeboot flag on $env:COMPUTERNAME"
}

# Verify EDR/AV Tamper Protection is enabled (Microsoft Defender example)
$tamper = Get-MpComputerStatus
if ($tamper.IsTamperProtected -ne $true) {
    Write-Warning "Defender Tamper Protection is DISABLED on $env:COMPUTERNAME — remediate via Intune/GPO"
}

# Report current boot state — flags machines already running in Safe Mode
$safeMode = Get-CimInstance Win32_ComputerSystem | Select-Object -ExpandProperty BootupState
Write-Output "BootupState: $safeMode"
if ($safeMode -ne 'Normal boot') {
    Write-Warning "$env:COMPUTERNAME is NOT in a normal boot state: $safeMode"
}

Strategic Hardening Measures

• Enable BitLocker with TPM + PIN or at minimum enforce recovery-key prompts. A machine protected by BitLocker will demand the recovery key after boot configuration changes — Safe Mode included — which can completely break this attack path for a remote operator without the key.
• Confirm your EDR vendor's Safe Mode behavior. Ask directly: does your sensor register under the SafeBoot Network key, and with what telemetry fidelity? If the answer is no, document the gap and compensate with network-layer detection (egress monitoring, NetFlow, DNS analytics).
• Alert on Event ID 1074 and boot-state changes as high-severity. Correlate with bcdedit/msconfig execution. A graceful reboot initiated by an interactive session on a server at 2 a.m. is pageable.
• Restrict local admin rights. This technique requires the ability to modify the BCD store. Tiered administration and removal of standing local admin materially raise the cost for the affiliate.
• Enforce MFA on all remote access paths — especially VPN concentrators and edge appliances, which remain Akira's most consistent entry vector. Boot evasion only matters if they get in; break the chain earlier.
• Deploy network-level exfiltration detection. Rclone-style uploads to cloud storage endpoints, large compressed archive creation followed by sustained outbound transfer, and connections to known file-transfer services should alert independent of endpoint telemetry. This is what saves you when the endpoint sensor gets dark.
• Tabletop this scenario. Your IR runbook should explicitly cover "EDR blind window" investigations: what telemetry survives (network, identity, mail, cloud), who owns the response, and how you scope activity during the gap.

The Bottom Line

Akira's affiliate didn't need a zero-day, a signed driver, or an exotic loader. They used a checkbox in Windows. The fact that encryption failed in this case was luck, not defense — and the data was still stolen. The organizations that survive this technique are the ones that (a) detect boot-configuration tampering in near-real-time, (b) treat unexplained Safe Mode boots as incidents, and (c) maintain network and identity telemetry that doesn't go blind when the endpoint agent does.

Build the detections above into your SIEM this week. Then call your EDR vendor and ask the Safe Mode question.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub