What happened
At 03:45 UTC on 4 August 2026, the SonicWall logged a credential spray, and at 03:52:42 UTC a VPN login succeeded against an account without MFA. The operator later accessed the domain controller, enumerated Active Directory, used WinRAR to stage mapped file shares, uploaded stolen material with s5cmd and established AnyDesk remote access. Huntress said credentials and file shares had been exfiltrated before the encryption attempt.
At 06:29:21 UTC, the operator ran msconfig.exe and forced the host to reboot into Safe Mode with Networking. Safe Mode was evidenced by Kernel-Boot event ID 27 with LoadOptions = NOEXECUTE=OPTOUT SAFEBOOT:NETWORK and Kernel-General event ID 12 with BootMode = 2. The operator ran “C:\Windows\system32\reg.exe” add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\AnyDesk /ve /d Service to enable AnyDesk in Safe Mode. Windows Defender logged event ID 3002 with error 0x8007043c because the service could not start in Safe Mode.
akira.exe launched at 06:34:29 UTC, memory errors appeared seconds later, and Defender quarantined the binary at 08:12:28 UTC after normal mode returned. Defender detected Ransom:Win32/Akira.B!ibt at 07:43:50 UTC, but cleanup failed with 0x80004005 until normal mode returned. Huntress did not publish the external IP addresses or the victim organisation’s identity in the cited report. Attribution posture: Huntress assesses the operator as an Akira ransomware affiliate; no individual or state sponsor was identified.
Why this matters now
The incident demonstrates why ransomware outcome cannot be measured only by encryption. The affiliate had already gained VPN access, reached the domain controller, enumerated Active Directory, staged files and exfiltrated data before the encryptor failed. A recovery team celebrating intact files could close too early while extortion, credential reuse and regulatory exposure remain unresolved.
Safe Mode is a trusted diagnostic state that intentionally excludes many third-party controls. Monitoring focused on malware signatures or service tampering during normal operation may miss the transition that creates the attacker’s blind window. Boot-state telemetry, registry changes and remote-access persistence therefore need to enter ransomware detection and server-hardening standards.
The decision for security leaders
Require ransomware playbooks to separate encryption, exfiltration, identity compromise and control impairment. Failure in one attacker objective does not close the others.
Assign detection engineering to monitor the transition into Safe Mode, not merely the resulting service failures. Boot events and SafeBoot registry modifications provide earlier, more durable evidence.
Make MFA absence on an external VPN an executive exception with an owner and expiry date. The observed sequence began with credential spraying against an account lacking MFA.
Evidence of closure
- Detection validation produces alerts for Kernel-Boot event ID 27 and Kernel-General event ID 12 Safe Mode evidence.
- Registry assurance confirms no unauthorised services exist beneath approved SafeBoot keys.
- Identity review documents revoked sessions, rotated credentials and MFA enforcement for the affected access path.
- Data-exposure assessment records the confirmed scope or an approved limitation statement.
The Security.io assessment
This is a detailed single-incident report rather than evidence that all Akira affiliates have adopted the technique. The Safe Mode transition and control failure are strongly evidenced by event records, while the future reliability of the encryptor in that state remains unresolved.
The defensive lesson is not that Safe Mode protects systems by starving ransomware of memory. The attacker successfully disabled EDR and Defender real-time protection; encryption failed because of conditions that may differ on another host. Defender detected Ransom:Win32/Akira.B!ibt at 07:43:50 UTC, but cleanup failed with 0x80004005 until normal mode returned.
Attribution posture: Huntress assesses the operator as an Akira ransomware affiliate; no individual or state sponsor was identified. Security.io assesses the material enterprise change as a new Akira-linked control-evasion observation and a reminder that exfiltration evidence, not encryption outcome, governs closure.
Questions for the morning meeting
- Can the SOC alert on Safe Mode boots and boot-configuration changes across servers and privileged workstations?
- Does ransomware closure continue after encryption fails when credentials and file shares were already stolen?
- Which remote-access services can start in Safe Mode, and who reviews changes to those service keys?