A recent Akira ransomware intrusion should be required reading for every SOC lead and incident responder. On August 4, an Akira affiliate gained initial access to a victim organization through a SonicWall SSL VPN appliance that had no multi-factor authentication enabled. From there, the attacker harvested credentials, moved laterally, staged and exfiltrated file shares — and then did something that defeats most endpoint security stacks outright: they rebooted the compromised host into Safe Mode with Networking before launching the encryptor.
The logic is brutally simple. In Safe Mode, Windows loads only a minimal set of drivers and services. The vast majority of EDR and antivirus agents — including their kernel-mode sensors — never start. The attacker gets a fully networked, attacker-controlled host with no telemetry, no blocking, and no one watching. It is a documented Akira TTP (MITRE ATT&CK T1562.001 — Impair Defenses: Disable or Modify Tools) that other families like Black Basta and AvosLocker have also used, and it works against almost every commercial EDR that isn't explicitly registered in the SafeBoot service lists.
The silver lining in this case: the encryptor reportedly failed due to memory issues. The defenders got lucky. Luck is not a control. If your detection strategy assumes your EDR agent will see the encryption phase, this tradecraft invalidates that assumption — you must detect the preparation for Safe Mode execution, not the encryption itself.
Technical Analysis
Attack Chain Observed
- Initial Access (T1078 — Valid Accounts): Authentication through an internet-facing SonicWall SSL VPN with no MFA. A single valid credential pair — phished, brute-forced, or purchased — is all that's required. Akira has aggressively targeted perimeter VPN appliances throughout 2024–2026 for exactly this reason.
- Credential Theft (T1003): Dumping credentials from memory and registry hives to enable lateral movement as legitimate users, which blends into normal admin traffic.
- Collection & Exfiltration (T1560/T1048): File shares were staged and exfiltrated — the double-extortion leverage — before any encryption attempt. This means your data leaves even if the encryptor fails, as it did here.
- Defense Evasion (T1562.001): The attacker modified the boot configuration to force Safe Mode with Networking on next boot — typically via
bcdedit /set {current} safeboot network— then triggered a reboot (e.g.,shutdown /r /t 0orRestart-Computer -Force). - Impact (T1486): The encryptor was launched post-reboot on a host with no EDR coverage. In this incident, it failed on memory constraints — an operational error by the affiliate, not a defensive success.
Why Safe Mode Defeats EDR
Windows maintains two service allow-lists for Safe Mode under the registry:
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal(plain Safe Mode)HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network(Safe Mode with Networking)
Only services and drivers explicitly listed under these keys are started. No mainstream EDR registers itself there by default (doing so would create recovery-path risks). Sophisticated attackers go one step further: they delete or rename security-related subkeys under SafeBoot so that even Safe Mode-capable defensive tooling (e.g., offline AV scanners, some forensic agents) won't load. Any write to these keys outside of a planned maintenance window is a high-fidelity indicator.
Affected Platforms and Exploitation Status
- Platforms: All Windows client and server versions where an attacker achieves administrative or SYSTEM-level control (required to modify boot configuration). Safe Mode abuse requires elevated privileges — which is exactly why it appears late in the kill chain, after credential theft and privilege escalation.
- Perimeter exposure: Unpatched or MFA-less SonicWall SSL VPN appliances remain a top Akira initial-access vector in 2025–2026 intrusions.
- Exploitation status: This is confirmed active exploitation in the wild as part of ongoing Akira ransomware-as-a-service operations. Akira is a named threat in CISA's #StopRansomware advisories, and Safe Mode defense evasion is an observed, repeatable affiliate TTP — not a theoretical technique.
Detection & Response
The critical defensive insight: you cannot detect encryption in Safe Mode — you must detect the pivot to Safe Mode. The observable artifacts are (a) boot configuration modification, (b) tampering with SafeBoot registry keys, and (c) anomalous forced reboots on servers and workstations. All three occur while your EDR is still alive, giving you a detection window measured in seconds to minutes.
Sigma Rules
---
title: Boot Configuration Modified to Force Safe Mode
description: Detects use of bcdedit.exe or reagentc.exe to configure safeboot, a technique used by Akira and other ransomware operators to reboot into Safe Mode and disable EDR before encryption. Legitimate use of safeboot flags is extremely rare outside of break/fix maintenance.
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\bcdedit.exe'
- '\reagentc.exe'
selection_cli:
CommandLine|contains:
- 'safeboot'
- 'safebootalternateshell'
condition: selection_img and selection_cli
falsepositives:
- Administrators troubleshooting boot issues during documented change windows
- Niche OEM recovery tooling
level: high
---
title: Tampering With SafeBoot Service Registry Keys
description: Detects deletion or modification of registry keys under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot, which controls which services and drivers load in Safe Mode. Ransomware operators remove security tool entries or add their own payload entries to persist through a Safe Mode reboot.
logsource:
category: registry_set
product: windows
detection:
selection:
TargetObject|contains:
- '\Control\SafeBoot\Minimal'
- '\Control\SafeBoot\Network'
filter_known_tools:
Image|endswith:
- '\msiexec.exe'
- '\svchost.exe'
condition: selection and not filter_known_tools
falsepositives:
- Security software installation/upgrade registering itself for Safe Mode
- Windows feature updates rebuilding SafeBoot lists (correlate with servicing activity)
level: high
---
title: Forced System Reboot Following Boot Configuration Change
description: Detects shutdown.exe or native reboot commands executed with the force flag by non-standard accounts, particularly on servers. Akira affiliates force an immediate reboot after setting safeboot flags to reach the EDR-free Safe Mode environment before defenders respond.
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\shutdown.exe'
CommandLine|contains:
- '/r'
- '-r'
CommandLine|contains:
- '/f'
- '/t 0'
- '/t 1'
filter_initiators:
ParentImage|endswith:
- '\msiexec.exe'
- '\TiWorker.exe'
- '\svchost.exe'
condition: selection and not filter_initiators
falsepositives:
- Patch management and software deployment tools forcing reboots (tune filters to your RMM/SCCM binaries)
- Scheduled maintenance scripts
level: medium
Tuning note from the field: Rule 1 (bcdedit safeboot) is the highest-fidelity signal of the three — in most enterprise environments, bcdedit with safeboot arguments fires zero times per year legitimately. Page on it. Rule 3 is your correlation anchor: a forced reboot from an interactive session on a server, followed within 10 minutes by an SMB/RDP session from an unusual source, is a pre-encryption playbook.
KQL — Microsoft Sentinel / Defender
// Hunt 1: Boot config tampering and forced reboots (process telemetry)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("safeboot"))
or (FileName =~ "shutdown.exe" and ProcessCommandLine has_any ("/r", "-r") and ProcessCommandLine has_any ("/f", "/t 0", "/t 1"))
| extend Indicator = iff(FileName =~ "bcdedit.exe", "SafeBootFlagSet", "ForcedReboot")
| project TimeGenerated, Indicator, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessAccountName, InitiatingProcessCommandLine, ReportId
| sort by TimeGenerated desc
// Hunt 2: SafeBoot registry key tampering (removal of security tools / persistence)
DeviceRegistryEvents
| where TimeGenerated > ago(7d)
| where RegistryKey has @"SYSTEM\CurrentControlSet\Control\SafeBoot"
| where ActionType in ("RegistryKeyDeleted", "RegistryValueDeleted", "RegistryValueSet", "RegistryKeyCreated")
| where not(InitiatingProcessFileName in~ ("msiexec.exe", "svchost.exe", "TiWorker.exe"))
| project TimeGenerated, ActionType, DeviceName, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName
| sort by TimeGenerated desc
// Hunt 3: Correlate — Safe Mode pivot followed by inbound session within 15 minutes
let SafeModePivot = DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName =~ "bcdedit.exe" and ProcessCommandLine has "safeboot"
| project PivotTime = TimeGenerated, DeviceName, AccountName;
DeviceLogonEvents
| where TimeGenerated > ago(14d)
| where LogonType in ("Network", "RemoteInteractive")
| join kind=inner SafeModePivot on DeviceName
| where TimeGenerated between (PivotTime .. PivotTime + 15m)
| project PivotTime, DeviceName, AccountName, TimeGenerated, RemoteIP, RemoteDeviceName, LogonType
| sort by PivotTime desc
Velociraptor VQL
Use this artifact for rapid triage across the fleet to find hosts with anomalous SafeBoot registry content — attacker-added persistence entries or missing security tool entries — plus live bcdedit execution during an active hunt.
-- Akira Safe Mode pivot hunt: SafeBoot registry anomalies + live boot-config tampering
-- Column A: hosts currently attempting bcdedit/shutdown Safe Mode behavior
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)bcdedit|reagentc' AND CommandLine =~ '(?i)safeboot')
OR (Name =~ '(?i)shutdown' AND CommandLine =~ '(?i)/(r|f)')
-- Column B (run as separate artifact): enumerate SafeBoot allow-lists for anomalies
-- Expected: drivers/services like '\Disk', '\Fve', '\NetBt'; unexpected .exe service names are suspect
SELECT Key.FullPath AS SafeBootKey,
Key.Name AS EntryName,
Key.Mtime AS ModifiedTime
FROM glob(globs='HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/SafeBoot/*/*',
accessor='raw_reg')
ORDER BY ModifiedTime DESC
Baseline the SafeBoot lists on a gold image first. Entries with recent ModifiedTime on a production server, or service entries pointing to executables in C:\Users\, C:\ProgramData\, or temp paths, are almost certainly attacker-planted persistence designed to survive the Safe Mode reboot.
Remediation & Hardening Script
The following PowerShell (run elevated) verifies the current boot configuration for unauthorized safeboot flags, audits SafeBoot registry keys for unexpected entries, and restores normal boot if a safeboot flag is found. Deploy it via your RMM as an automated response action when the Sigma rules above fire.
# === Security Arsenal: Safe Mode Pivot Response & Audit ===
# Requires elevation. Run via RMM/EDR response on any host that trips the Safe Mode detection rules.
$report = [ordered]@{}
# 1. Check active boot configuration for safeboot flags
$bcdOut = & bcdedit /enum '{current}' 2>$null | Out-String
$report['SafeBootFlagPresent'] = ($bcdOut -match 'safeboot')
$report['SafeBootValue'] = ([regex]::Match($bcdOut, 'safeboot\s+(\w+)')).Groups[1].Value
# 2. If a safeboot flag exists and this is NOT a sanctioned maintenance host, remove it
if ($report['SafeBootFlagPresent'] -and -not $env:SAFEBOOT_MAINT_APPROVED) {
Write-Warning "Unauthorized safeboot flag detected — removing to prevent Safe Mode reboot."
& bcdedit /deletevalue '{current}' safeboot | Out-Null
$report['RemediationAction'] = 'safeboot flag deleted'
} else {
$report['RemediationAction'] = 'none required'
}
# 3. Audit SafeBoot Minimal/Network allow-lists for entries added in the last 30 days
$cutoff = (Get-Date).AddDays(-30)
$recentEntries = foreach ($list in 'Minimal','Network') {
$basePath = "HKLM:\SYSTEM\CurrentControlSet\Control\SafeBoot\$list"
Get-ChildItem $basePath -ErrorAction SilentlyContinue | Where-Object {
$_.Property -or (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue)
} | ForEach-Object {
[PSCustomObject]@{
List = $list
EntryName = $_.PSChildName
FullPath = $_.Name
}
}
}
$report['SafeBootEntryCount'] = ($recentEntries | Measure-Object).Count
$report['SuspiciousEntries'] = ($recentEntries | Where-Object {
$_.EntryName -match '\.(exe|dll|bat|ps1)$' -or $_.EntryName -match '(?i)tmp|temp|appdata|programdata'
}).EntryName
# 4. Verify LSA protection and Credential Guard status (limits post-compromise credential theft)
$report['LsaProtection'] = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL -ErrorAction SilentlyContinue).RunAsPPL
$report['CredentialGuard'] = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LsaCfgFlags -ErrorAction SilentlyContinue).LsaCfgFlags
# 5. Output JSON report for ingestion by your SIEM/RMM
$report | ConvertTo-Json -Compress | Write-Output
Remediation
Immediate (24–48 hours):
- Enable MFA on every SonicWall SSL VPN — no exceptions. This single control would have prevented this intrusion. Audit all local SSL VPN accounts for MFA enrollment, disable unused accounts, and restrict VPN authentication to directory-integrated accounts under conditional access. Follow the current SonicWall PSIRT guidance for your appliance generation and ensure firmware is current; legacy SSL VPN portals should be migrated or decommissioned.
- Alert on the Safe Mode pivot now. Deploy the Sigma/KQL detections above. Treat
bcdedit /set {current} safeboot networkon a server as a P1 — you have one reboot cycle to respond. - Audit
SafeBoot\MinimalandSafeBoot\Networkregistry keys fleet-wide against a gold-image baseline. Remove unauthorized entries; investigate any deletions.
Short term (1–2 weeks):
- Harden boot configuration change authorization. Restrict
bcdeditand registry writes underHKLM\SYSTEM\CurrentControlSet\Control\SafeBootto a dedicated Tier-0 admin group via WDAC/AppLocker rules and registry ACLs, and alert on any use outside approved accounts. - Restrict local admin and interactive logon on servers. The Safe Mode pivot requires elevated rights — credential theft from the VPN ingress is what bought the attacker those rights. Enforce LSA Protection (RunAsPPL) and Credential Guard, and deploy gMSA/LAPS for local accounts.
- Verify your EDR's tamper protection and Safe Mode posture. Ask your vendor explicitly: does the sensor register under SafeBoot Minimal/Network? Can policy prevent service stop by local admin? If the answer is no, the detections above are your compensating control — treat them accordingly.
Strategic:
- Test the assumption that encryption will be seen. Run a tabletop (or purple-team the Safe Mode reboot with Atomic Red Team-style tests) and measure: did the boot-config change alert fire? Who got paged? Was the host isolated before the reboot completed?
- Assume exfiltration precedes encryption. In this incident the encryptor failed and the data was still stolen. DLP, egress monitoring, and anomaly alerting on bulk SMB read/compression activity matter as much as ransomware blocking.
- Segment and snapshot. Immutable, offline, or air-gapped backups with tested restore procedures remain the control that converts a ransomware incident from existential to expensive.
If you find evidence of a Safe Mode pivot in your environment — safeboot flags, SafeBoot key tampering, unexplained forced reboots clustered around off-hours — treat it as an active intrusion, not an IT anomaly. Isolate the host via network controls (not the EDR, which the attacker may already have disabled), acquire memory and triage images from other hosts on the same segment, and engage IR support before the attacker comes back with a working encryptor.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.