Published · 5d agoSecurity8 min read
The Agent Was Not Tampered With. It Was Never Loaded.
An Akira affiliate rebooted a host into Safe Mode to shed its sensors. Two other ransomware families cannot decrypt what they encrypt. All three cases end at a restore you have to own.
Not a builder's beat, but builders have a standing stake in it.See today for builders

What happened
- Akira was the most active ransomware group Huntress observed in 2025, and its affiliates follow a settled playbook: entry through an exposed VPN, usually SonicWall, pivot to the domain controller, enumerate Active Directory, stage and exfiltrate data, then detonate, all within a few hours.
- An incident Huntress observed in early August followed that chain almost beat for beat: the same SonicWall SSL VPN entry, the same AdUsers.txt/AdComp.txt Active Directory dumps opened in Notepad, and the same WinRAR-then-cloud-upload exfiltration.
- Instead of dodging EDR by building a clean VM, the threat actor rebooted the compromised host into Safe Mode with Networking enabled, a diagnostic startup mode that loads only core Windows drivers and services while still permitting network connectivity.
- Because third-party security products are excluded from Safe Mode's minimal driver set by design, the reboot took both the Huntress agent and Windows Defender real-time protection offline in a single move, while preserving the network access needed to continue the attack.
- Beginning around 03:45 UTC on August 4, 2026, the SonicWall logged a burst of failed logins against multiple usernames from several external IPs, a straightforward credential spray.
Compiled by The WatchSomething wrong?How this is made
Why it matters
An Akira affiliate who already had a domain controller in hand rebooted the compromised host into Safe Mode with Networking, a diagnostic startup mode that loads only core Windows drivers and services while keeping network connectivity, and in that single move the Huntress agent and Windows Defender real-time protection went offline [3][4]. Separately, Check Point Research and Coveware have each pulled apart a ransomware family whose encryption cannot be reversed by anyone, operator included [16][29]. Read the three together and one control is left carrying the weight: a restore performed with no endpoint telemetry from the detonation host and no possibility of a decryptor.
Not a disabled agent. An absent one.
Akira was the most active group Huntress observed in 2025, and its affiliates run a settled playbook: in through an exposed VPN, usually SonicWall, pivot to the domain controller, enumerate Active Directory, stage and exfiltrate data, then detonate, all within a few hours [1]. Huntress has separately documented active exploitation of SonicWall SSL VPN appliances as an initial-access vector [14]. The early-August intrusion followed that chain almost beat for beat: the same SonicWall SSL VPN entry, the same AdUsers.txt and AdComp.txt dumps opened in Notepad, the same WinRAR-then-cloud-upload exfiltration [2].
The variation came at the end, and it matters more than the novelty suggests. Third-party security products are excluded from Safe Mode's minimal driver set by design, which is why the reboot took both the Huntress agent and Defender's real-time protection down at once while preserving the network access the attacker still needed [4]. Nothing was killed, unloaded or unhooked. The distinction is operational rather than semantic: a defence built to alert on tamper events has nothing to fire on, because the sensor was never started. What remains observable is an absence, telemetry stopping from a host that is still reachable on the network [5].
That is the second time Huntress has recorded an Akira affiliate solving the sensor problem by relocating rather than fighting. In an earlier case, an affiliate spun up a brand-new virtual machine on the victim's hypervisor specifically to run the encryptor somewhere Huntress was not installed [12]. New VM, or old host booted without third-party drivers: both are the same move, which is to run the payload where no agent exists. Detection engineering that treats agent coverage as a property of the estate rather than of the running boot instance will keep missing it.
The clock around that move is short and cheap. Beginning around 03:45 UTC on August 4, 2026, the SonicWall logged a burst of failed logins against multiple usernames from several external IPs, a straightforward credential spray; roughly seven minutes later, at 03:52:42 UTC, a valid VPN account authenticated from an external IP to an SSL VPN with no multi-factor authentication in front of it [5][6]. Then nearly two hours of nothing before hands-on-keyboard activity began: RDP to the domain controller, an elevated cmd.exe, a ping to confirm reachability [7].
The map is drawn before the encryption starts
What the operator did next is the part that connects this incident to the recovery question. The enumeration wrote a full-property dump of every user and every computer in the domain to C:\ProgramData via Get-ADUser and Get-ADComputer [8]. The `$formatenumerationlimit = -1` line is the tell Huntress calls out: it removes PowerShell's default four-item truncation on multi-valued attributes such as MemberOf, so every group membership is captured rather than the first four [9]. Per Huntress, the user export harvests credentials-adjacent and PII fields including PasswordLastSet, LastLogonDate, email addresses, phone numbers and mailbox location, while the computer export maps every host, operating system and IP, producing a target list for lateral movement and mass encryption [10]. Collection followed on an application server, where WinRAR was downloaded and installed mid-intrusion and used to recursively archive the mapped file shares [11].
Follow that through. If the dump is a full-property export of every user with untruncated group memberships, then every account that exists in that directory is in the attacker's copy of it, along with the groups that give it power [4]. A backup console whose administrative access is granted through the same directory is therefore inside the map the operator built two hours after logging in with one sprayed password, before anything was encrypted. That is the argument for keeping backup authorisation out of the identity plane the attacker just enumerated, and it is an argument from the intrusion's own artefacts rather than from a framework.
Two families that cannot give the data back
The other half of the standard plan is the decryptor, and two independent analyses now say it can be a fiction.
Check Point Research reports that VECT 2.0 discards three of four decryption nonces for every file above 131,072 bytes, or 128 KB, with the flaw identical across the Windows, Linux and ESXi variants [15]. CPR's conclusion is that full recovery is impossible for anyone including the attacker, and that at a 128 KB threshold this makes VECT effectively a wiper for virtually any file containing meaningful data, naming VM disks, databases, documents and backups as examples [16]. CPR confirmed the flaw is present across all publicly available VECT versions [17]. Two details compound it. The cipher has been misidentified in public reporting: CPR says VECT uses raw ChaCha20-IETF with no authentication, not the ChaCha20-Poly1305 AEAD claimed in several widely cited threat intelligence reports and in VECT's own initial advertisement, meaning there is no MAC and no integrity protection [18]. And the advertised `--fast`, `--medium` and `--secure` flags on the Linux and ESXi builds are parsed and then silently ignored, so every execution applies the same hardcoded thresholds [19]. Since the nonce flaw is in every public version and the mode flags do nothing, no operator setting changes whether large files come back [3].
Coveware's finding on Nitrogen has a different root and the same end state. Nitrogen was derived from the leaked Conti 2 builder code, and a coding mistake in the ESXi variant makes it encrypt every file with the wrong public key [26]. The design is conventional: a per-file Curve25519 keypair, exchanged against a master public key to derive a shared secret used as a ChaCha8 key, with the file public key written to the footer for the decryptor to reverse [27]. The bug is four bytes. The public key sits at stack offset rsp+0x20, and a later QWORD write at rsp+0x1c spans rsp+0x1c to rsp+0x24, overwriting the first four bytes of the key [28]. Coveware's point is that the corrupted key was never derived from any private key, so no matching private key exists to be recovered, purchased or subpoenaed; the actor will fail their own test decryption [29]. Coveware states plainly that victims without viable backups have no ability to recover their ESXi encrypted servers, that paying will not assist, and that encrypted files must be analysed alongside the malware that encrypted them to establish their status [30].
Provenance predicted nothing here. VECT claims to have built all three lockers from scratch, having appeared on a Russian-language forum in December 2025 and shipped version 2.0 in February 2026 [20]; Nitrogen inherited a leaked Conti builder [26]. One wrote its own engine, one reused a proven one, and both broke the file loop. VECT's other defects run in the same direction, with CPR listing self-cancelling string obfuscation, permanently unreachable anti-analysis code and a thread scheduler that degrades the encryption performance it was meant to improve [23]. CPR obtained the panel and builder through a BreachForums account, which is possible because VECT's partnership with the forum makes every registered user an affiliate, in full effect since April 2026, alongside a partnership with TeamPCP, the actor behind March 2026 supply-chain attacks that injected malware into Trivy, Checkmarx's KICS, LiteLLM and Telnyx [21][25]. An affiliate pool with no vetting and a locker that destroys large files is a combination in which the victim's counterparty may be unable to deliver even in good faith. VECT's leak site lists only two victims, both from the TeamPCP supply-chain attacks [22].
What the restore actually has to survive
Combine the two halves and the recovery assumption inverts. For VECT files over 128 KB and for Nitrogen-encrypted ESXi files, restore from backup is not the preferred path, it is the only one [2]. And in the Akira case, Huntress says the attacker's own anti-EDR trick appears to have sabotaged their ransomware [13], which is a third instance of the encryption stage not doing what the operator intended [1]. Across three vendors, the pattern is that what the payload leaves behind may be neither cleanly encrypted nor cleanly intact.
That is exactly the shape the NCSC's principles for ransomware-resistant cloud backups address, and the specific ones earn their place here. The guidance lists five: backups resilient to destructive actions; a backup system configured so that it is not possible to deny all customer access; the ability to restore from a backup version even if later versions become corrupted; robust key management for data-at-rest protection; and alerts triggered when significant changes are made or privileged actions attempted [31]. Principle three is the wiper principle. If VECT destroys documents and databases above 128 KB and your backup system faithfully ingested the destroyed versions [16], recovery depends entirely on reaching an earlier version. Principle five is the Safe Mode principle: when the endpoint sensor is absent by design rather than disabled by force [4], privileged-action alerting from a system the attacker does not control is the surviving detection surface. Principle two is the negotiation principle, because a backup plane the attacker can lock you out of returns you to the decryptor that may not exist [29].
Three things are worth tracking. Whether CPR's correction on the cipher propagates into the threat intelligence that IR firms and insurers consult, since a family profile that describes authenticated AEAD encryption when the reality is unauthenticated ChaCha20 with no integrity protection will mislead exactly the person deciding whether to pay [18]. Whether VECT ships the dedicated Cloud Lockers mentioned in its forum posts, promised to affiliates who pass a quiz or puzzle challenge, since the same nonce logic applied to cloud storage would land on the backup copies themselves [24]. And whether Safe Mode with Networking shows up in more Akira intrusions, given that the group has now been seen twice choosing to run the encryptor where the agent is not, rather than fighting the agent where it is [3][12].
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Akira was the most active ransomware group Huntress observed in 2025, and its affiliates follow a settled playbook: entry through an exposed VPN, usually SonicWall, pivot to the domain controller, enumerate Active Directory, stage and exfiltrate data, then detonate, all within a few hours.
ReportedView cited source - [2]
An incident Huntress observed in early August followed that chain almost beat for beat: the same SonicWall SSL VPN entry, the same AdUsers.txt/AdComp.txt Active Directory dumps opened in Notepad, and the same WinRAR-then-cloud-upload exfiltration.
ReportedView cited source - [3]
Instead of dodging EDR by building a clean VM, the threat actor rebooted the compromised host into Safe Mode with Networking enabled, a diagnostic startup mode that loads only core Windows drivers and services while still permitting network connectivity.
ReportedView cited source - [4]
Because third-party security products are excluded from Safe Mode's minimal driver set by design, the reboot took both the Huntress agent and Windows Defender real-time protection offline in a single move, while preserving the network access needed to continue the attack.
ReportedView cited source - [5]
Beginning around 03:45 UTC on August 4, 2026, the SonicWall logged a burst of failed logins against multiple usernames from several external IPs, a straightforward credential spray.
ReportedView cited source - [6]
Roughly seven minutes later, at 03:52:42 UTC, an attempt succeeded: a valid VPN account logged in from an external IP to an SSL VPN with no multi-factor authentication in front of it.
ReportedView cited source
Sources & coverage · 5 publishers
The reporting this story was synthesized from, earliest first. Every link goes to the original.
- thehackernews.com6d agoEvooo1Bot Linux Botnet Exploits Known Flaws to Turn Edge Devices Into SOCKS5 Proxies
- thehackernews.com6d agoSuspected China-Nexus Actor Exploits VMware vCenter Flaw, Deploys Babuk-Derived Ransomware
- thehackernews.com6d agoHow MCP Servers Can Expose Enterprise Secrets



