Akira Ransomware Affiliate Bypasses EDR via Safe Mode, Botches Encryption

What Happened

According to BleepingComputer, an affiliate of the Akira ransomware operation disabled endpoint detection and response (EDR) tooling on a compromised host by rebooting the machine into Windows Safe Mode with Networking. Many EDR agents do not load as part of the minimal driver/service set that runs in Safe Mode, effectively blinding the security stack while the attacker continued operating. The reporting indicates the actor succeeded in exfiltrating data from the target but failed to successfully encrypt files during this intrusion — the specific reason for the encryption failure was not detailed in the source.

Why It Matters

Safe Mode abuse to evade EDR is a known technique among ransomware crews (including prior Akira and other affiliate activity), and this report is a fresh confirmation that it remains an active, working method against at least some EDR deployments. It matters because Safe Mode boot is a native, unauthenticated-at-the-OS-level Windows capability — no exploit or novel malware is required, only local admin access, which ransomware affiliates typically already have by the time they reach this stage. Organizations relying solely on endpoint agents for detection and blocking are exposed during any window where the agent isn't loaded, regardless of vendor.

What Defenders Should Watch For

• Unexpected reboots into Safe Mode with Networking on servers or workstations, especially outside patch/maintenance windows — correlate boot configuration changes (e.g., bcdedit safeboot modifications) with subsequent EDR agent silence.
• Gaps or dropouts in EDR heartbeat/telemetry that coincide with a reboot event, rather than assuming a gap is benign connectivity loss.
• Registry or boot configuration data (BCD) modifications that add services to the Safe Mode driver/service allow-list, a common precursor to this technique.
• Network and identity-layer telemetry (auth logs, network flow, DNS, proxy/firewall logs) as a compensating control, since these often continue operating independently of host-based EDR agents during Safe Mode.
• Restricting or alerting on local admin rights needed to force a Safe Mode boot, and reviewing whether your EDR vendor supports early-launch/boot-start driver protections that persist into Safe Mode.

This is developing, net-new intelligence based on a single reported incident, and details such as the specific EDR product, initial access vector, and why encryption ultimately failed have not been disclosed. Defenders should treat this as a reminder to validate Safe Mode resilience of their own EDR deployment rather than a fully characterized campaign. Read the original report at BleepingComputer.