Ransomware Evasion, a Nation-State Rootkit, and an Active 0-Day

Akira Ransomware Used Safe Mode to Go Dark, and Still Won

A recent Akira ransomware intrusion shows just how little the actual ransomware payload matters when everything before it goes right for the attacker. This post walks through how one affiliate got in, how they blinded endpoint defenses, and why the ransomware itself failing to run didn't save the victim from a bad day.

What You Need to Know

An Akira affiliate broke into a network through an exposed SonicWall VPN account that had no MFA, then used Windows Safe Mode with Networking to knock out endpoint detection and response tools before attempting to encrypt data. The ransomware payload itself failed due to memory errors, but the attacker still stole credentials and sensitive data in under five hours. The lesson here isn't about a patch. It's about a technique: forcing a host into Safe Mode is an effective, repeatable way to blind EDR, and most organizations aren't watching for it.

What Happened

The intrusion started with a successful login to a SonicWall VPN account that lacked multi-factor authentication. From there, the operator moved to RDP access on a domain controller, enumerated Active Directory, and pivoted to an application server. Once inside, they collected data from mapped file shares, archived it with WinRAR, and exfiltrated it using s5cmd to an attacker-controlled S3 bucket. AnyDesk was installed to maintain remote access throughout.

The Technique

Rather than trying to fight through active EDR, the attacker forced the compromised host into Safe Mode with Networking, a state where most third-party EDR services don't load and Microsoft Defender's real-time protection is disabled. They also modified the Windows registry so AnyDesk would run in Safe Mode, preserving their remote access even while the host's defenses were down. Huntress observed roughly 10 minutes where the host had no functioning EDR and reduced antivirus visibility.

The Akira payload itself, akira[.]exe, ran into low virtual-memory and out-of-memory errors in Safe Mode and failed to encrypt anything. A scheduled Defender scan later flagged the payload but couldn't remove it until the host rebooted normally and real-time protection came back online. By then, the affiliate had already finished stealing credentials and data.

Why This Matters

This case is a reminder that ransomware "success" isn't measured by whether encryption worked. The affiliate walked away with stolen credentials and exfiltrated data in under five hours, leaving the victim exposed to data-extortion demands regardless of the failed encryption. Akira has also shown before that it adapts when endpoint defenses get in the way, including using unmanaged, network-connected devices to reach SMB shares. Safe Mode abuse is just the latest version of that same pattern: find the gap where defenses don't reach, and operate there.

What to Do

Prioritize MFA on all VPN access, especially on externally exposed appliances like SonicWall, and monitor for credential-spraying activity against those accounts. Detection engineering should specifically cover unusual Safe Mode boot configuration changes, including registry modifications that register remote-access tools like AnyDesk to start in Safe Mode, unexpected RDP connections to domain controllers, archive creation from file shares, and command-line transfers to cloud storage. None of these are exotic behaviors on their own, which is exactly why they're easy to miss without dedicated detection logic built around this pattern.

Encryption failing isn't a win if the data already walked out the door. The real defense here starts well before Safe Mode ever comes into play, at the VPN login that should have needed a second factor.

Mustang Panda's CoolClient Backdoor Now Comes With a Signed Kernel Rootkit

The China-linked threat actor HoneyMyte, also known as Mustang Panda, has added a new trick to its CoolClient backdoor: a signed Windows kernel-mode rootkit built to keep the malware hidden from the tools defenders rely on to find it. Here's what changed, how the group is getting in, and what defenders should be watching for.

What You Need to Know

HoneyMyte has updated CoolClient with a kernel-mode driver, tracked as msagent.sys, that conceals malicious processes, files, registry objects, and command-and-control traffic at the operating system level. That kind of kernel-level stealth is harder to detect with conventional endpoint tools and helps the backdoor stay active while leaving fewer visible traces. The update was observed in a campaign targeting Myanmar, and researchers linked the rootkit's signing certificate to a company called Nanjing Ranyi Technology Co., Ltd.

What Happened

In the campaign researchers examined, HoneyMyte used PlugX as an initial post-compromise implant before deploying CoolClient. The actor built a fake Windows Defender directory, added Microsoft Defender exclusions covering that location, and copied malicious components into it. From there, they renamed a legitimate Sangfor executable to defender.exe and used it to sideload a malicious DLL, libngs.dll. That DLL decrypted and ran additional components responsible for persistence, registry modifications, UAC bypass, process injection, driver installation, and CoolClient's command-and-control activity. Persistence was locked in through a scheduled task configured to launch at system startup with SYSTEM privileges.

The Rootkit

The new driver, msagent.sys, was signed with a certificate issued to Nanjing Ranyi Technology Co., Ltd. that was valid from August 2013 through September 2014. Researchers found older malicious drivers signed with the same certificate, though they weren't able to establish a direct connection between those earlier samples and this CoolClient activity. Whether or not the samples are linked, the reuse of an old, still-trusted signing certificate for a new rootkit shows how signed drivers can quietly extend an actor's toolkit well past their original use.

Why This Matters

A signed kernel-mode driver is a meaningfully different problem than a typical user-mode implant. It runs with a level of trust and system access that most endpoint security tools aren't built to question, which is exactly why HoneyMyte added it. Combine that with a Defender exclusion, a renamed legitimate executable, and DLL sideloading, and this campaign was built specifically to blend into normal-looking Windows Defender activity rather than stand out as obviously malicious. That's a deliberate evasion strategy, not an accident, and it's one that a nation-state-linked actor like Mustang Panda has the resources to keep refining.

What to Do

Defenders should investigate any signed driver installations that don't align with approved software, especially unfamiliar services like msagent. Watch for scheduled tasks launching binaries from unusual Windows Defender-like paths, and pay attention when legitimate applications load DLLs from directories they wouldn't normally use. Monitoring for changes to Microsoft Defender exclusions, new or unexpected driver services, suspicious DLL sideloading, and parent-child process relationships involving renamed security-themed executables can help catch this intrusion chain before the rootkit has a chance to reduce endpoint visibility.

The most dangerous part of this campaign isn't the rootkit itself, it's how ordinary everything looked right up until it wasn't.

No CVE, No Patch, No Time to Wait: GeoServer 0-day Under Active Attack

A newly disclosed zero-day in GeoServer is already being probed by attackers, and there's no patch to fall back on yet. Here's what the vulnerability is, what active exploitation looks like right now, and what to do about it in the meantime.

What You Need to Know

Researchers have disclosed an unauthenticated SQL injection vulnerability in GeoServer's jsonArrayContains function, and exploitation attempts started within hours of the disclosure going public. The flaw has no CVE identifier yet and remains unpatched, which means organizations can't rely on conventional patch management as an immediate fix. Anyone running internet-facing GeoServer instances, particularly organizations publishing or managing geospatial data, should treat this as an active, unfolding risk rather than a theoretical one.

What's Vulnerable

The vulnerability lives in jsonArrayContains, a GeoServer function used to query JSON array fields, and it doesn't require authentication to exploit. On its own, that's already a serious SQL injection issue. It becomes more dangerous depending on how GeoServer is configured on the backend. When GeoServer is connected to Microsoft SQL Server and the database account has elevated permissions, an attacker may be able to use the flaw to execute operating system commands, turning a SQL injection bug into full remote code execution. The affected function can also come into play with PostGIS and Oracle JDBC data stores, so the real level of risk depends heavily on each organization's specific database configuration and exposure.

What Happened

Researchers observed hundreds of exploitation attempts within hours of the vulnerability becoming public. So far, the activity looks focused on probing exposed systems and triggering errors to identify which deployments are vulnerable, rather than confirmed delivery of follow-on payloads. That distinction matters, but it shouldn't be read as reassuring. It's reconnaissance, and reconnaissance at this volume, this fast, usually means more targeted exploitation is coming next.

Why This Matters

GeoServer has been through this before. CVE-2024-36401 led to widespread exploitation once attackers moved past the probing stage, and the pattern playing out now looks similar: rapid, broad scanning immediately after disclosure, with no patch available to close the door. Without a CVE or vendor fix yet, defenders are stuck relying entirely on access restrictions and monitoring until that changes, which is exactly the kind of window attackers count on.

What to Do

Start by identifying every GeoServer instance in your environment, and prioritize any that are exposed to the public internet. Restrict access wherever possible until a vendor fix is available, using network controls to limit connections to trusted users, applications, and administrative networks. Make sure database accounts supporting GeoServer are running with the minimum permissions required, since the path to remote code execution depends directly on how much access that account has. On the monitoring side, review GeoServer, reverse proxy, web application firewall, and database logs for unexpected requests involving jsonArrayContains, unusual database errors, anomalous query patterns, or any signs of command execution.

Treat the probing happening right now as the opening move, not the whole game. GeoServer's history with CVE-2024-36401 suggests the next phase won't stay quiet for long.

Researchers Show AI Agents Can Rebuild Malware Without the Source Code

New research shows that agentic AI systems can reconstruct working malware from behavioral descriptions and partial technical details alone, without ever touching the original source code. Here's what the researchers demonstrated, how the process works, and what it means for how defenders should be prioritizing detection.

What You Need to Know

Researchers have demonstrated that agentic AI systems can reconstruct malicious functionality from behavioral descriptions and partial technical artifacts, lowering the effort required to reproduce malware that already exists in the wild. Instead of needing a complete malware sample, an agentic system can plan the objective, write code, test the output, catch its own failures, and revise components until the result matches the observed behavior. That means malware analysis reports, sandbox telemetry, and publicly available technical writeups, the exact kind of material security researchers publish to help defenders, may now also help threat actors recreate tools they never had direct access to.

What Happened

The research focused on rebuilding specific malware functions through automated planning, coding, execution, and iterative debugging, all handled by the agentic system itself. These models can operate with access to development tools and isolated environments, which lets them translate a description of observed technique into an actual working component rather than just a theoretical outline. The point isn't that the AI invented new attack methods. It's that a known technique, once documented anywhere in enough behavioral detail, can be turned back into functional code far faster than a human developer starting from scratch.

How It Works

The approach breaks a malware objective into individual implementation tasks rather than treating it as one big problem. Functions like persistence, credential theft, command-and-control communication, process discovery, and data collection can each be built as separate pieces and then assembled into a complete operational workflow. That task-by-task structure is exactly what makes iterative debugging possible: the system can test each piece against expected behavior, find where it falls short, and revise until it matches, the same loop a human malware developer would run, just automated and faster.

Why This Matters

This development doesn't lower the bar for inventing new attacks, but it does lower the bar for replicating and adapting known ones. Malware analysis writeups and sandbox telemetry that used to require real skill to weaponize can now feed directly into an automated rebuild process. Practically, that likely means more variants of existing malware families showing up faster, which shortens the useful life of detections built around static indicators like file hashes, filenames, or known malware-family signatures. Those indicators were already a rear-view mirror. This makes the mirror smaller.

What to Do

Prioritize behavioral detection over static indicators. Signature-based detection isn't useless, but it's increasingly a lagging measure against AI-assisted variant generation. Security teams should focus monitoring on suspicious command execution, unusual persistence mechanisms, credential access activity, network connections to newly registered or low-reputation infrastructure, and anomalous data staging or exfiltration behavior, the actual operational footprint of an intrusion rather than the specific file that carries it out. AI-assisted malware development may increase variant volume, but it doesn't remove the operational requirements of running an actual intrusion. Identity controls, MFA, least privilege, endpoint telemetry, egress monitoring, and a practiced incident response plan remain the fundamentals that catch adapted malware before it causes material impact.

Faster malware generation doesn't mean a faster intrusion. It still has to move, persist, and communicate, and those are the moments defenders can still catch it.

Dysphoria Botnet Splits Into DDoS and Proxy-Relay Variants

The Dysphoria botnet is spreading across vulnerable routers, gateways, cameras, and other internet-connected Linux devices, and it's no longer a one-size-fits-all payload. Here's how it's evolved, why a compromised router is now more than an availability problem, and what to do about it.

What You Need to Know

Dysphoria now ships as separate builds rather than a single payload: one variant carries out distributed denial-of-service attacks, and the other turns compromised devices into proxy relays. That split lets operators use the same pool of hijacked edge devices for direct disruption in one case and as concealed routing infrastructure in the other. The botnet spreads through weak Telnet and SSH credentials along with known remote code execution flaws in internet-exposed IoT equipment, and it's built to be harder to take down than a typical botnet, which is the part defenders should pay closest attention to.

What Happened

Dysphoria gets onto devices the way a lot of IoT botnets do: weak or default Telnet and SSH credentials, plus known RCE vulnerabilities in equipment that's exposed directly to the internet. What's different is what happens after infection. Once installed, the malware can use blockchain-based name services, including Ethereum Name Service and Solana Name Service, to locate its command-and-control infrastructure. Storing encoded infrastructure details in blockchain records instead of conventional DNS makes traditional domain takedowns and static domain blocklists significantly less effective, since there's no central registrar to pressure or static domain to blocklist.

The relay-focused variant skips DDoS functionality entirely. Instead, it uses UPnP to create port mappings on the local gateway, which can expose services on the infected device to external connections and relay traffic between remote operators and internal systems.

Why This Matters

A device running the relay variant isn't just compromised, it's infrastructure. The risk here goes beyond the device itself becoming unavailable or getting drafted into a DDoS attack. A compromised router can become a staging point for proxy traffic, helping attackers obscure their true origin and potentially supporting follow-on intrusion activity into whatever network that router sits in front of. Combined with blockchain-based C2 resolution that sidesteps normal takedown methods, Dysphoria is built to be both harder to trace and harder to remove at scale.

What to Do

Start with an inventory of externally reachable routers and IoT devices, apply vendor firmware updates, and replace end-of-life hardware that no longer receives security fixes. Disable Telnet outright, limit password-based SSH access, and replace default or reused administrator credentials with unique, strong passwords. Review UPnP settings and port-forwarding rules for entries you don't recognize, disable remote management from the public internet, and segment IoT equipment away from systems that handle sensitive data. On the monitoring side, watch outbound traffic from network devices for connections to unfamiliar destinations or unexpected DNS infrastructure, since that's often the clearest sign a device has been turned into a persistent relay node.

A router doesn't need to go offline for it to be doing damage. Sometimes the more dangerous outcome is that it keeps working perfectly, just not for you.