RoguePlanet - A Zero-day

RoguePlanet: How a Windows Zero-Day Turns Microsoft Defender Into a Privilege Escalation Weapon

Category: Vulnerability Research | Windows Security | Zero-Day Analysis

Published: June 10, 2026

---

Table of Contents

1. The Setup: Seven Zero-Days in Ten Weeks
2. Who Is Nightmare-Eclipse?
3. What Is RoguePlanet?
4. Why Defender's Quarantine Pipeline Is the Target
5. The Seven-Stage Attack Chain Explained
6. The Poseidon I/O System: Turning a Race Condition Into a Reliable Exploit
7. Why This Is Not a Typical Privilege Escalation Bug
8. Current Patch Status and the Defender Signature Limitation
9. The Attacker's Own Words
10. MITRE ATT&CK Mapping
11. Detection and Hunting Guidance for Defenders
12. IOC Reference
13. The Bigger Picture: A Sustained Campaign Against Windows Security
14. References

---

1. The Setup: Seven Zero-Days in Ten Weeks

On June 10, 2026 hours after Microsoft shipped its June Patch Tuesday updates a new GitHub repository appeared under the handle MSNightmare. The repository contained RoguePlanet, a working proof-of-concept for a Windows local privilege escalation zero-day. The timing was deliberate. Three of the researcher's prior exploits had just received patches in the same Patch Tuesday release. The response was to drop a new one the same day.

This is not an isolated vulnerability disclosure. RoguePlanet is the seventh exploit targeting Windows security components released by the same researcher across a span of roughly ten weeks. The first dropped on April 3, 2026. The researcher has operated under three aliases: Nightmare-Eclipse, Chaotic Eclipse, and now MSNightmare. None of these releases went through coordinated disclosure with Microsoft. All were published directly to GitHub or mirrors with full proof-of-concept code.

The prior six tools in this cluster:

Tool	CVE	Patch Status	Notes
BlueHammer	CVE-2026-33825 (CVSS 7.8)	Patched April 14, 2026	Added to CISA KEV. Confirmed real-world exploitation.
RedSun	CVE-2026-41091	Patched May 21, 2026 (out-of-band)	Added to CISA KEV. Confirmed exploitation.
UnDefend	CVE-2026-45498	Patched May 21, 2026 (out-of-band)	Added to CISA KEV.
YellowKey	CVE-2026-45585	Patched June 9, 2026 (Patch Tuesday)
GreenPlasma	CVE-2026-45586	Patched June 9, 2026 (Patch Tuesday)
MiniPlasma	CVE-2020-17103 (researcher-attributed)	Patched June 9, 2026 (Patch Tuesday)	Described as a comprehensive re-exploitation of an incomplete 2020 fix.
RoguePlanet	No CVE assigned	No patch available	PoC publicly available as of June 10, 2026.

BlueHammer, RedSun, and UnDefend have already been documented in real-world attack chains by Huntress researchers. The threat from the earlier tools has moved beyond proof-of-concept into active exploitation. RoguePlanet, as a new unpatched release, begins at a higher threat level than most disclosures start from, precisely because the researcher's prior work has already demonstrated that these tools reach production attackers.

---

2. Who Is Nightmare-Eclipse?

The identity behind these releases is unknown. The researcher operates under the aliases Nightmare-Eclipse, Chaotic Eclipse, and Dead Eclipse across GitHub and a self-hosted Blogger site at deadeclipse666.blogspot.com. Their blog posts are cryptographically signed with PGP a detail that signals either genuine operational security awareness or a deliberate effort to establish authenticity for their public persona. The MSNightmare GitHub profile lists affiliation as "Microsoft," which appears to be a deliberate provocation rather than a factual claim.

The stated motivation is grievance. In signed posts on their blog, the researcher describes a history with Microsoft's Security Response Center (MSRC) that includes having portal access revoked, submitted vulnerability reports dismissed, bounties refused on confirmed findings, and what they characterize as defamation. Whether these claims are accurate cannot be independently verified, but they establish the researcher's public framing for why they chose not to coordinate disclosure.

The technical consistency across seven releases all targeting Microsoft Defender or closely related Windows security components, all using overlapping primitive sets around NTFS junction manipulation, opportunistic locks, and scheduled task abuse indicates a single researcher or small team with deep, sustained focus on one attack surface rather than a broad vulnerability hunter operating across different codebases.

Microsoft took action on the researcher's accounts:

• May 23, 2026: GitHub terminated the Nightmare-Eclipse account and removed all six prior exploit repositories.
• May 26, 2026: GitLab suspended the mirrored account and removed repositories.

Both takedowns appear to have accelerated distribution rather than slowing it. Within hours of the GitLab removal, copies of the repositories spread to paste sites, alternative Git hosts, and security forums. The new MSNightmare account and the self-hosted mirror at git.projectnightcrawler[.]dev/NightmareEclipse ensure the code remains accessible regardless of platform-level enforcement.

---

3. What Is RoguePlanet?

RoguePlanet is a local privilege escalation (LPE) exploit for Windows that elevates a standard, unprivileged user account to NT AUTHORITY\SYSTEM the highest privilege level on a Windows system. It has been confirmed working on a fully patched Windows 11 Pro host by the Cyderes Howler Cell Threat Research Team.

What makes it unusual is what it does not require:

• No kernel exploit
• No memory corruption bug
• No administrative rights
• No driver installation
• No software other than what is present in a default Windows installation with Defender active

The exploit works by threading together five legitimate Windows components Microsoft Defender's real-time scan and quarantine pipeline, NTFS directory junctions (reparse points), NTFS opportunistic locks (oplocks), Volume Shadow Copy Service (VSS), and the Windows Error Reporting (WER) QueueReporting scheduled task in a specific sequence that produces a result none of those components were individually designed to permit.

The vulnerability is in the gap between when Defender creates a quarantine artifact and when it validates where that artifact actually landed. That gap, which exists by design in Defender's quarantine workflow, is the entire attack surface.

The researcher's own description from their Blogger post captures the scope of effort: the original version was built as remote code execution targeting Defender's handling of files on SMB shares. A mid-May 2026 Defender engine update broke that approach along with many junction-based techniques used in prior exploits. The researcher spent the following three weeks rebuilding the exploit as a local privilege escalation race condition. The result is RoguePlanet.

---

4. Why Defender's Quarantine Pipeline Is the Target

Microsoft Defender's quarantine process is, at its core, a SYSTEM-level file operation. When Defender detects a malicious file, it does not simply delete it it moves the file into a protected quarantine store. This operation is performed under SYSTEM privileges because the quarantine store must be protected from tampering by the user.

The vulnerability emerges from a specific design characteristic of this workflow: Defender uses NTFS file paths to create and access the quarantine artifact, and NTFS paths can be transparently redirected by reparse points (junctions and symlinks) without the accessing process being aware of the redirection. Defender creates the quarantine artifact, but the path it used to create that artifact is not the same as where the artifact actually landed because an NTFS junction was switched between those two moments.

The result is a SYSTEM-owned file sitting in attacker-controlled directory space. From there, the exploit has one more task: find a SYSTEM-level process that will execute a file at the path where the injected artifact now lives. The WER QueueReporting scheduled task present on every standard Windows installation, running as SYSTEM, and triggerable by an unprivileged user through the Task Scheduler COM interface is that process.

The entire chain uses no vulnerabilities in the traditional sense of the word. Every individual operation is a documented, supported Windows feature working exactly as designed. The vulnerability is a sequencing problem a combination of features that produces an unintended outcome.

---

5. The Seven-Stage Attack Chain Explained

Here is a step-by-step walkthrough of how RoguePlanet elevates privileges from a standard user to SYSTEM.

Stage 1: Dual-Mode Entry Orchestrator or Payload?

The RoguePlanet binary is self-referential it contains both the unprivileged orchestration logic and the SYSTEM-level payload in a single executable. On startup, it checks its own token. If it is already running as SYSTEM (meaning the exploit has already succeeded), it takes the payload path: it connects to a named pipe it previously created (\\.\pipe\RoguePlanet), identifies the interactive session of the user who launched the original unprivileged process, and spawns conhost.exe inside that session with SYSTEM privileges delivering the elevated shell. If it is not running as SYSTEM, it enters the orchestrator path and begins the exploitation sequence.

Stage 2: I/O Thread Saturation and IPC Setup

Before doing anything to Defender, the exploit initializes its Poseidon I/O subsystem a purpose-built component for making the subsequent race condition reliable. One generator thread continuously produces random data via the system cryptographic RNG. One worker thread per logical CPU core continuously writes that data to UUID-named temporary files in tight loops. These threads are launched but held dormant on an event object until they are needed. Their sole purpose is to create sustained, controllable disk I/O pressure that makes the oplock race windows deterministic rather than probabilistic. The named pipe \\.\pipe\RoguePlanet is created immediately after and kept open for the lifetime of the process.

Stage 3: ISO Extraction, Working Directory, and Filesystem Setup

The exploit extracts an ISO image embedded in its own data section, writes it to a UUID-named temp file, and mounts it as a read-only virtual disk with no drive letter. The ISO is accessed via its raw NT kernel path (\Device\CdRom<N>), bypassing Win32 path restrictions. Inside the ISO is a wermgr.exe carrying the EICAR test signature the standard antivirus test string that triggers Defender's detection and quarantine pipeline without requiring an actual malicious payload.

A working directory named RP_<UUID> is created under %TEMP%. Two subdirectories are created inside it: one named wdtest_temp (the quarantine artifact capture zone) and one named System32 taking its name from the last path component of C:\Windows\System32. This naming is intentional: the scan path passed to Defender will be %TEMP%\RP_<UUID>\System32\wermgr.exe, which is structurally identical to the legitimate path C:\Windows\System32\wermgr.exe. This matters in Stage 7.

Stage 4: EICAR Delivery, VSS Discovery, and Oplock Placement

The EICAR-signed wermgr.exe is written to the System32 subdirectory. An NTFS Alternate Data Stream (ADS) named :WDFOO is also created on this file using low-level NT file APIs. The Poseidon I/O threads are released simultaneously. A separate thread calls directly into MpClient.dll via runtime-resolved exports to trigger a Defender scan of the EICAR file through the Defender RPC interface, with scan flags configured to activate the full remediation pipeline.

Simultaneously, a shadow copy finder thread begins polling the NT object manager directory \Device, watching for Defender to spin up a new Volume Shadow Copy as part of its remediation workflow. When the new HarddiskVolumeShadowCopy* device appears, the exploit constructs the full path to the EICAR file's :WDFOO ADS through that shadow copy volume and places an oplock on it. When Defender's internal processing reaches the point where it opens this file through the shadow copy, the oplock fires, pausing Defender mid-operation with a controlled and guaranteed window to perform the junction swaps that follow.

Stage 5: The Junction Swap Chain Capturing the SYSTEM-Owned Artifact

While Defender is paused on the oplock, the System32 subdirectory is converted into a reparse point junction targeting the mounted ISO. When Defender resumes, it follows the junction and sees the legitimate-looking wermgr.exe on the ISO rather than the EICAR file. Defender's internal state continues forward.

The exploit then watches C:\Windows recursively for Defender creating a temporary file matching the pattern Temp\TMP with exactly sixteen trailing characters the signal that Defender has entered its active quarantine workflow. On that signal, the junction is swapped again to point at wdtest_temp. A second EICAR is written through the junction path, landing inside wdtest_temp. The ISO's wermgr.exe is then byte-range locked, preventing Defender from removing it. Faced with a locked source file, Defender creates a quarantine placeholder instead which lands inside wdtest_temp through the active junction. The exploit captures the path of this placeholder file. The result: a SYSTEM-owned file sitting inside attacker-controlled directory space.

Stage 6: Payload Injection and Path Redirect to C:\Windows

The reparse point is removed from the System32 subdirectory handle, reverting it to a plain directory. The captured quarantine placeholder is opened with full write access and overwritten with the exploit binary read from the current process's own image on disk. The file now contains the exploit binary but retains the SYSTEM-level ownership and metadata that Defender assigned to it.

All working artifacts are then atomically renamed to random UUID paths using NtSetInformationFile with FileRenameInformationEx, preserving open handles while freeing the original paths. The root working directory %TEMP%\RP_<UUID> is converted into a reparse point junction targeting C:\Windows. After this operation, the path %TEMP%\RP_<UUID>\System32\wermgr.exe where the injected exploit binary now lives resolves transparently to C:\Windows\System32\wermgr.exe. Any path-based check will see a legitimate system binary location.

Stage 7: WER Task Execution and SYSTEM Shell Delivery

The Windows Task Scheduler COM interface is used to trigger the QueueReporting scheduled task inside the Windows Error Reporting task folder. This task is present on every standard Windows installation, runs as SYSTEM, and can be triggered programmatically by an unprivileged user through the Task Scheduler COM API. Its execution involves wermgr.exe at the System32 path. Because of the junction chain built in Stage 6, that path now resolves to the exploit binary.

The exploit binary launches as SYSTEM, enters the payload branch at the top of main, connects back to the \\.\pipe\RoguePlanet named pipe, identifies the interactive user's session, and spawns conhost.exe into that session with SYSTEM privileges. The main process unblocks from ConnectNamedPipe, prints success, and releases all COM resources cleanly. The unprivileged user now has a SYSTEM shell.

---

6. The Poseidon I/O System: Turning a Race Condition Into a Reliable Exploit

Race conditions in exploit development are notoriously hard to productize. A race condition that succeeds 10% of the time in a lab is essentially unusable in production. The researcher's investment in the Poseidon I/O subsystem is specifically designed to solve this problem.

By saturating disk I/O across all logical CPU cores with high-frequency random writes to temporary files, the Poseidon system creates predictable pressure on the Windows I/O scheduler. This pressure makes the timing windows around the oplock and the junction swaps consistent and reproducible in controlled lab conditions. The researcher themselves describes the PoC as "hit or miss" in production, with 100% success on some test machines and failure on others. Hardware configuration differences, variable background load, and scheduler behavior in real enterprise environments reintroduce timing uncertainty that the lab setup was engineered to remove.

This is an important caveat for both attacker and defender modeling: RoguePlanet is not a single-shot reliable LPE in all environments. It may require multiple attempts. But the detection signals from Poseidon I/O activity one generator thread plus per-core worker threads executing high-frequency writes to UUID-named temp files are also distinctive and useful for hunting.

---

7. Why This Is Not a Typical Privilege Escalation Bug

Most local privilege escalation vulnerabilities fall into recognizable categories: a buffer overflow in a privileged service, an integer overflow in a kernel driver, an unquoted service path, a DLL hijacking opportunity in a privileged process. All of these involve a coding error in some component that can be patched by fixing that component.

RoguePlanet does not fit any of these categories. There is no coding error to point to. Each individual component involved Defender's quarantine pipeline, NTFS junctions, oplocks, VSS, WER's scheduled task, the Task Scheduler COM interface is functioning exactly as it was designed to function. The vulnerability is in the interaction pattern between them: a design-level assumption in the quarantine pipeline that the path used to create an artifact is the same path that artifact occupies when later accessed. NTFS reparse points make that assumption false.

This has a significant implication for patching. A fix cannot target a specific API call or a buffer boundary. It requires a change to how Defender validates path integrity across the quarantine workflow either by using file handles rather than paths for the post-creation operations, by validating junction state before and after artifact creation, or by removing the condition where the WER task's execution path can be influenced by user-space reparse points. All of these are architectural changes, which is why no patch has been released.

---

8. Current Patch Status and the Defender Signature Limitation

As of June 10, 2026, no patch addressing the root cause of RoguePlanet has been released. No CVE has been assigned. Microsoft has issued a Defender signature update (Exploit:Win32/DfndrRugPlnt.BB) that detects the specific compiled proof-of-concept binary. However, this detection:

• Targets the compiled sample, not the underlying technique
• Is defeated by minor source code modifications and recompilation
• Does not detect the behavioral chain during execution
• Provides no protection against any actor who has adapted the technique from the published PoC

The Cyderes Howler Cell team confirmed that the behavioral chain survives recompilation with minimal source modification and remains undetected by static means. Signature-based detection of the PoC binary, while useful for blocking the exact published sample, is not a substitute for behavioral detection coverage.

An important platform limitation: RoguePlanet does not work on Windows Server editions because standard users on Server SKUs cannot mount ISO images. The exploit depends on ISO mounting to deliver the EICAR trigger without dropping it as a standalone file. However, this does not reduce urgency for Windows 10/11 workstation environments, which constitute the primary target surface for initial access followed by local privilege escalation in most enterprise attack chains.

---

9. The Attacker's Own Words

On June 9, 2026, the researcher posted to their Blogger site in a PGP-signed message, describing the development of RoguePlanet in terms that are unusual for a vulnerability researcher and worth reading as context for the level of commitment behind this campaign:

"I have worked on this non stop since the start of May... I did not eat, I did not drink water, I even forgot what outside looked like. I slept for 3 hours after 96 hours of non stop continuous work. Getting this PoC to work genuinely drained my soul, it severely degraded my mental and physical health but in the end of May, a full PoC was developed."

The post also includes a statement that contextualizes why account bans and repository takedowns have not slowed the releases:

"Microsoft forgot that even if they banned my GitLab and GitHub accounts, they cannot unwrite my code. Once it's public, you can't remove it."

The researcher also mentions a "batch of memory corruption vulnerabilities in Defender" and "other batches of vulnerabilities in several other components" as future disclosures. Whether this is credible or a bluff, the track record of seven working exploits in ten weeks multiple of which have been confirmed in real-world attack chains makes dismissal unreasonable.

---

10. MITRE ATT&CK Mapping

Technique ID	Technique Name	How RoguePlanet Uses It
T1068	Exploitation for Privilege Escalation	Core exploit: elevates unprivileged user to NT AUTHORITY\SYSTEM without kernel exploit or memory corruption
T1574.010	Hijack Execution Flow: Services File Permissions Weakness	Injects exploit binary into SYSTEM-owned quarantine artifact, later executed by WER scheduled task as SYSTEM
T1053.005	Scheduled Task/Job: Scheduled Task	WER QueueReporting task (SYSTEM) triggered via Task Scheduler COM interface by unprivileged user to execute injected payload
T1055	Process Injection	SYSTEM-level conhost.exe spawned into interactive user session after privilege elevation
T1564.004	Hide Artifacts: NTFS File Attributes	NTFS Alternate Data Stream (:WDFOO) created on EICAR wermgr.exe using low-level NT APIs to bypass Win32 ADS restrictions
T1480	Execution Guardrails	IsRunningAsLocalSystem() check gates payload vs. orchestrator execution path; ISO mounting limitation restricts execution to desktop Windows SKUs
T1036.005	Masquerading: Match Legitimate Name or Location	Working directory named System32; exploit binary injected at path resolving to C:\Windows\System32\wermgr.exe via junction chain
T1490	Inhibit System Recovery	VSS (Volume Shadow Copy) used as an attack primitive Defender's VSS access during remediation is used as the oplock trigger point
T1485	Data Destruction (indirect)	Embedded EICAR and byte-range locking force Defender into quarantine workflow, which is then subverted

---

11. Detection and Hunting Guidance for Defenders

Because no patch is available and the signature detection only covers the compiled PoC binary, behavioral detection is the primary defensive control. The following detection signals are ordered from most reliable to most environment-specific.

Tier 1 High Confidence, Low False-Positive Risk

• Named pipe \\.\pipe\RoguePlanet created by a non-SYSTEM process. No legitimate Windows software uses this pipe name. Against the published PoC, this is a near-certain indicator. Any actor adapting the technique will rename the pipe but this signal is valid for the current release.
• Filesystem artifact cluster under %TEMP%: Monitor for simultaneous creation of the following three paths by the same process:
  • %TEMP%\RP_<UUID>\wdtest_temp\
  • %TEMP%\RP_<UUID>\System32\
  • %TEMP%\RP_<UUID>\System32\wermgr.exe
  The RP_ prefix combined with this directory structure is consistent across all runs of the current PoC.
• wermgr.exe written to or executed from any path outside of C:\Windows\System32\ or C:\Windows\SysWOW64\. Legitimate wermgr.exe lives in System32. Any execution or write of wermgr.exe from an unusual path especially from under %TEMP% is highly suspicious.
• conhost.exe spawned from a SYSTEM-integrity parent with no associated cmd.exe or terminal host in the process tree, into an interactive user session. This is the SYSTEM shell delivery event. Conhost.exe is legitimately spawned by terminal processes; a SYSTEM-owned conhost with no terminal parent in the tree is anomalous.

Tier 2 Medium Confidence, Requires Baseline Tuning

• Poseidon I/O pattern: One generator thread plus per-core worker threads executing high-frequency random writes to UUID-named temporary files under %TEMP% simultaneously. This pattern has no common legitimate equivalent outside of disk benchmarking and storage stress tools. Combined with any of the Tier 1 indicators above, it becomes a high-confidence composite signal.
• VSS enumeration from non-SYSTEM, non-backup processes: NtQueryDirectoryObject calls targeting HarddiskVolumeShadowCopy* from user-space processes are rare outside of system and backup tooling. Tune this detection against known backup agent process names before operationalizing to reduce false positives.
• NTFS junction creation under %TEMP% pointing to system paths: A user-space process creating a reparse point junction under their own temp directory that redirects to C:\Windows or system volume paths has very few legitimate use cases.

Tier 3 Situational Awareness

• ISO mounting by non-admin user processes in close temporal proximity to Defender activity: Correlating ISO mount events with Defender scan triggers from the same process lineage narrows the detection surface significantly.
• Task Scheduler COM API calls triggering the WER QueueReporting task from a non-SYSTEM process: The Task Scheduler COM interface is used legitimately by many applications. This signal is useful as a correlating indicator combined with others, not as a standalone alert.

What Not to Rely On

• The Exploit:Win32/DfndrRugPlnt.BB Defender signature alone it covers the compiled PoC only, not adapted versions
• Hash-based detections for the PoC binary
• Blocking the GitHub or Git mirror URLs the code is already widely mirrored

---

12. IOC Reference

Indicator	Type	Notes
\\.\pipe\RoguePlanet	Named Pipe	Created by orchestrator; used as IPC success channel between unprivileged and SYSTEM instances
%TEMP%\RP_<UUID>\	File Path Pattern	Working directory root; UUID-named, contains wdtest_temp and System32 subdirectories
%TEMP%\RP_<UUID>\System32\wermgr.exe	File Path	EICAR-bearing wermgr.exe dropped here; later becomes the injected exploit binary post-junction chain
wermgr.exe:WDFOO	NTFS ADS	Alternate Data Stream created on EICAR file using low-level NT APIs
Exploit:Win32/DfndrRugPlnt.BB	Defender Signature	Detects compiled PoC binary only; does not detect behavioral chain or recompiled variants
hxxps[://]github[.]com/MSNightmare/RoguePlanet	PoC URL	Defanged. Original GitHub PoC repository.
hxxps[://]git.projectnightcrawler[.]dev/NightmareEclipse	Mirror URL	Defanged. Self-hosted Git mirror maintained by researcher.
hxxps[://]deadeclipse666.blogspot[.]com/	Attacker Blog	Defanged. PGP-signed posts track new releases and researcher communications.

---

13. The Bigger Picture: A Sustained Campaign Against Windows Security

RoguePlanet should not be evaluated in isolation. Viewed across the full ten-week release cycle, this is not a vulnerability researcher making occasional disclosures it is a systematic campaign against a single attack surface, executed at a pace and technical depth that has no recent parallel in public Windows exploit research.

Several observations are worth holding together:

The architectural consistency is deliberate. All seven tools target the intersection of Microsoft Defender, NTFS reparse point behavior, scheduled task infrastructure, and Windows security component internals. This is not breadth it is depth. The researcher has mapped a family of related design assumptions in this specific attack surface and is methodically exploiting each one.

Each patch enables the next exploit. The April 2026 Patch Tuesday fix for BlueHammer did not end the campaign it informed the next release. The mid-May Defender engine update that broke RoguePlanet's original remote code execution path was met with three weeks of continuous work to rebuild the exploit on a different primitive. The researcher is adapting to Microsoft's defensive responses in near-real-time.

The move to full public release changes the threat model. Responsible disclosure would have kept these exploits from public attackers for 90 days or more. Full immediate public release means every actor commodity ransomware, nation-state, and everything in between has access to working LPE code the moment it is published. The confirmation that BlueHammer, RedSun, and UnDefend appeared in real-world attack chains within weeks of their release shows this is not a hypothetical concern.

The stated pipeline of future disclosures deserves serious attention. A researcher who has delivered seven working exploits in ten weeks, and who explicitly describes holding additional batches targeting memory corruption and other Windows components, has earned the benefit of the doubt on the credibility of future release threats regardless of the unusual circumstances surrounding their motivation.

Until a patch addressing the root cause is available, behavioral detection against the TTPs described above is the primary and only reliable defensive control against RoguePlanet.

---

14. References

• Primary Technical Analysis: Reegun Jayapaul and Rahul Ramesh, Cyderes Howler Cell Threat Research Team "RoguePlanet: Windows Zero-Day That Weaponizes Defender's Own Quarantine Pipeline," June 10, 2026. https://www.cyderes.com/howler-cell/rogueplanet-windows-zero-day
• Researcher Disclosure Post: Nightmare Eclipse (MSNightmare / Dead Eclipse) "It's Patch Tuesday !!!", Blogger, June 9, 2026. https://deadeclipse666.blogspot.com/2026/06/its-patch-tuesday.html
• Cyderes Howler Cell BlueHammer (CVE-2026-33825) Analysis: https://www.cyderes.com/howler-cell/windows-zero-day-bluehammer
• Cyderes Howler Cell RedSun (CVE-2026-41091) Analysis: https://www.cyderes.com/howler-cell/redsun-zero-day

---

Tags: Windows Zero-Day, Privilege Escalation, Microsoft Defender, LPE, NTFS Junctions, Oplocks, Volume Shadow Copy, WER Scheduled Task, Nightmare-Eclipse, MSNightmare, RoguePlanet, MITRE ATT&CK, CVE, Patch Tuesday, Windows 11, Vulnerability Research, Zero-Day Exploit, Defender Quarantine, Threat Intelligence

Grixba Deep Dive: Tracking 26 Months of Play Ransomware's Custom Scanner Evolution

Posted in: Malware Analysis | Threat Intelligence | Ransomware

---

Research Credit: The foundational analysis and sample-level findings in this article are based on original research by RakeshKrish published at The Raven File on June 8, 2026. This post expands on that work with additional context, defender guidance, and structured analysis for practitioners. All credit for the sandbox execution findings, MITRE profiling, and version comparison framework belongs to the original researcher.

---

Table of Contents

1. Introduction: Why Play Ransomware Matters
2. What Is Grixba?
3. The Four Samples: SHA-256 Hashes and Timeline
4. Size Analysis: The Bloat-and-Shrink Strategy
5. Version-by-Version Feature Breakdown
   • v1 → v1.5: Adding the Network Scanner
   • v1.5 → v2: The Full Modular Overhaul
   • v2 → v3: Strategic Regression for Evasion
6. What Does Grixba Actually Hunt For? (Scanner Targets)
7. MITRE ATT&CK Analysis: What the Sandbox Revealed
8. The Mutex: CPFATE_2704_v4.0.30319
9. Capability Verdict: Which Version Is Most Dangerous?
10. Weakness Analysis: Where Defenders Can Win
11. The DPRK Connection
12. Detection Strategy and Hunting Guidance
13. IOC Reference Table
14. Conclusion

---

1. Introduction: Why Play Ransomware Matters

Play Ransomware is one of the most persistent and consistently active ransomware groups operating today. Since first appearing in 2022, the group has compromised more than 1,200 victims globally, with a heavy geographic focus on the United States (900+ victims), Canada, and the UK. The sectors most targeted include manufacturing, business services, and technology companies — organizations with high operational dependencies and low tolerance for downtime.

What separates Play from many ransomware-as-a-service (RaaS) operations is their investment in custom tooling. Most ransomware affiliates rely on commodity tools — off-the-shelf RATs, leaked builders, and publicly available post-exploitation frameworks. Play built their own. And one of those custom tools — a .NET-based infostealer and network scanner called Grixba — gives us a rare window into the operational maturity and evolving tradecraft of a sophisticated ransomware actor.

This article provides a practitioner-focused deep-dive into four versions of Grixba sampled across 26 months, from September 2022 through November 2024. The goal is not just to catalog indicators — it is to understand the reasoning behind each architectural change, identify persistent detection opportunities that survive version upgrades, and give defenders the context they need to build durable hunting rules rather than fragile signature-based detections.

---

2. What Is Grixba?

Grixba is a custom-built infostealer and network reconnaissance tool developed by the Play Ransomware group. It is written in .NET and was initially distributed as a single-executable binary packed using Costura — a .NET utility that embeds all assembly dependencies into a single portable EXE.

The tool's primary purpose is pre-encryption intelligence gathering. Before Play deploys its ransomware payload, Grixba is used to map everything relevant on the compromised network:

• Installed security software (AV, EDR, XDR products)
• Backup solutions and remote management tools
• Active user accounts and machine inventory
• Cached Remote Desktop Protocol (RDP) sessions
• Cryptocurrency wallet data
• Messaging application data
• Browser history (in v1.5 specifically)
• User credentials

The intelligence gathered by Grixba directly informs the ransomware operators' decisions about which systems to encrypt, which security tools to disable first, and which backup systems need to be wiped before the encryption phase begins. This is not opportunistic scanning — it is structured, deliberate pre-attack reconnaissance.

Grixba was first publicly identified in 2023, with CISA and the FBI referencing it in advisory AA23-352A and Symantec classifying it as Infostealer.Grixba. The original research by RakeshKrish at The Raven File is the most comprehensive multi-version analysis of this tool published to date.

---

3. The Four Samples: SHA-256 Hashes and Timeline

The analysis covers four distinct samples compiled across a 26-month window:

Version	Approx. Date	Size	SHA-256
v1 (Baseline)	September 2022	164 KB	453257c3494addafb39cb6815862403e827947a1e7737eb8168cd10522465deb
v1.5 (Network Scanner)	November 2022	175 KB	c59f3c8d61d940b56436c14bc148c1fe98862921b8f7bad97fbc96b31d71193c
v2 (Full Modular)	May 2023	727 KB	f8810179ab033a9b79cd7006c1a74fbcde6ed0451c92fbb8c7ce15b52499353a
v3 (Stripped/Staged)	November 2024	118 KB	3621468d188d4c3e2c6dfe3e9ddcfe3894701666bad918bc195aba0c44e46e94

The v1.5 label requires a note: this November 2022 sample is listed by CISA/FBI advisory AA23-352A as the "Play network scanner / Gt_net.exe" and by Symantec as Infostealer.Grixba. It sits seven weeks after v1 and predates the v2 architectural overhaul by approximately six months — consistent with an iterative build that added network scanning capability before the full modular redesign.

Together, these four samples tell a coherent story: rapid capability expansion, followed by a deliberate architectural regression. The binary grew from 164 KB to 727 KB across the first three versions, then was deliberately cut back to 118 KB — smaller than the original baseline. Each phase reflects a specific operational objective.

---

4. Size Analysis: The Bloat-and-Shrink Strategy

v1 → v1.5: +11 KB (+6.7%)

A minor but meaningful bump compiled just seven weeks after the baseline. The v1.5 build expanded network scanning breadth — CISA's advisory explicitly labels this hash as the "Play network scanner," distinguishing it from the pure infostealer framing of v1. Additional host enumeration paths and a wider software detection list were added, but the monolithic architecture and Costura bundling were preserved.

v1.5 → v2: +552 KB (+315%)

The jump to 727 KB is the most dramatic in the series, driven by four concurrent changes happening simultaneously:

• XOR-encrypted modular payload (inf_g.dll / data.dat): All scanning logic was extracted into a bundled DLL, XOR-encrypted and stored as data.dat. Decoding at runtime requires an embedded base64 XOR key.
• SQLite database engine: Output migrated from flat CSV files to a structured ExportData.db database, requiring bundling a database engine.
• Forged PE version-info resources: The binary impersonates SentinelOne with fake metadata strings embedded in the PE header.
• Greatly expanded scan radar: 14+ new AV/EDR products, 15+ new RMM tools, and 5+ new backup vendors added to the detection target list.

Notably, v2 was compiled approximately three weeks after Symantec's public Grixba disclosure in April 2023. The operators were clearly watching detection research and responded with a substantially more evasive build within weeks.

v2 → v3: −609 KB (−84%)

The November 2024 sample is smaller than even the 2022 baseline at 118 KB. This is not simplification — it is intentional architectural regression driven by operational security lessons learned after 18 months of public analysis of v2.

After v2 was publicly documented by Symantec (April 2023), Field Effect MDR (January 2025), and CISA (June 2025), the v2 IoC set became widely distributed: the 727 KB size, ExportData.db, data.dat, inf_g.dll, and the SentinelOne PE metadata became well-known hunting signatures.

v3 sidesteps all of these in a single architectural move: by stripping the bundled database engine and moving the heavy scanning logic into a separately-delivered module, the dropper binary becomes dramatically smaller, carries fewer static indicators, and evades size-based and hash-based signatures tuned for v2. The scanning payload can now be staged and delivered on demand.

Critical Defender Note: YARA rules, size thresholds, and file-name detections built for the v2 pattern (727 KB, ExportData.db, inf_g.dll, SentinelOne metadata) will silently miss v3. Defenders must pivot to behavioral detections: WMI/WinRM enumeration patterns, the C:\Users\Public\Music\ drop path, and PIA VPN egress — which remain consistent across all four versions.

---

5. Version-by-Version Feature Breakdown

v1 → v1.5: Adding the Network Scanner

Added: Network Scanner Mode (Explicit Host Scanning)
v1.5 expands Grixba's enumeration to include active host discovery across IP ranges, beyond just WMI enumeration. CISA labels it a "network scanner" alongside infostealer — it can now aggressively identify reachable hosts and services. This is the earliest confirmed use of host-range scanning in Grixba.

Added: Browser History Path Enumeration
CISA published Snort detection rules for this hash that trigger on a chain of nine SMB-accessed web browser history paths (GRXBA_webhist_path_1 through _9). v1.5 added browser history collection — scanning for Chrome, Firefox, Edge, and Internet Explorer history databases accessible over SMB.

Added: Wider Software Enumeration List
The 11 KB size increase is consistent with additional string tables covering security products not present in v1's scan list, while not yet reaching the full breadth of v2's expanded radar.

Retained: Monolithic architecture, CSV output (alive.csv, soft.csv, wm.csv, etc.), WinRAR-compressed export.zip without password protection. The modular XOR-encrypted DLL architecture and SQLite database output are not present yet.

v1.5 → v2: The Full Modular Overhaul

Added: XOR-Encrypted Modular Architecture
v2 extracts all scanning logic into inf_g.dll, XOR-encrypted and bundled as data.dat. At runtime, Grixba decodes data.dat using an embedded base64 XOR key to recover inf_g.dll, which hosts the inf_g.Core.CoreScanner class. Static analysis of the EXE alone reveals no scanning logic. It also means the operators can update the payload (inf_g.dll) independently of the dropper (GT_NET.exe).

Added: PE Masquerading as SentinelOne
The v2 binary is named GT_NET.exe with PE version-info forged to display as "SentinelOne Compatibility Wizard" version 1.1.6.0. This exploits defender trust in recognizable security tool names in Task Manager and basic triage — and the irony of impersonating one of the very products the tool is designed to detect is operationally deliberate.

Added: SQLite DB Output — ExportData.db
All reconnaissance output is consolidated into a single structured database with 18 tables: active hosts, browser history, installed software, processes, session information, network routes, cached credentials, and more. This eliminates the eight named CSV files that were prominent hunting artifacts in v1/v1.5.

Added: Obfuscated-Password Archive (data.zip)
v2 produces a password-protected data.zip. The password displayed at runtime is not the actual decryption password — it must be combined with the hard-coded GUID E8B10161-0849-4984-A6BF-3D1B267615CC- found in inf_g.dll to derive the real password. Capturing the console output alone is insufficient to open the archive.

Added: C2 via PIA VPN (84.239.41.12)
v2 communicates with a Private Internet Access (PIA) VPN exit node for anonymized exfiltration. v1 and v1.5 had no dedicated C2 infrastructure.

Added: Massively Expanded Scan List
New AV/EDR additions include CrowdStrike, SentinelOne, Carbon Black, Morphisec, MVISION, WithSecure, WatchGuard, FireEye, F-Secure, Heimdal, HitmanPro, VIPRE, DeepArmor, and Dr.Web. New RMM additions include NinjaOne, Kaseya VSA, ConnectWise, BeyondTrust, GoTo Resolve, Splashtop, Atera, Zoho Assist, Action1, Pulseway, DameWare, and Radmin. IDrive, Synology C2, and Dropbox added to backup vendor coverage.

v2 → v3: Strategic Regression for Evasion

Regressed: SQLite Engine Removed
The SQLite engine was the largest single contributor to v2's 727 KB size. v3 drops it entirely. Output returns to a compressed archive, retaining the password protection mechanism from v2.

Regressed: Payload Delivery Externalized
In v2, the XOR-encrypted inf_g.dll was carried inside data.dat alongside the EXE. v3 externalizes the scanning logic entirely — the dropper is now a lean loader stub that pulls the scanning payload as a separate stage. This makes the dropped EXE far smaller and removes data.dat as a detection artifact.

Regressed: SentinelOne PE Metadata Dropped
The elaborate SentinelOne version-info block is removed or significantly simplified. The GT_NET.exe filename convention is retained as a lighter-weight naming disguise, but the PE metadata that was the most-published static signature from v2 is gone.

Regressed: Costura Dependency Bundling Reduced
v3 drops below v1's baseline (118 KB vs 164 KB), which is only achievable by removing or drastically reducing Costura bundling. Dependencies are resolved at runtime via the target environment's .NET Framework installation.

Regressed: Expanded Scan List Trimmed to Core Targets
The aggressive v2 expansion is dialed back. Core targets (CrowdStrike, SentinelOne, Microsoft Defender, Veeam, TeamViewer, AnyDesk) are retained as the highest-value detections. Products added in v2 that proved rarely encountered in target environments are removed.

Retained across all versions:

• Core WMI/WinRM/Remote Registry/Remote Services enumeration
• Clr mode: EvtOpenLog/EvtClearLog log wiping (anti-forensics)
• C:\Users\Public\Music\ drop path via RDP
• Password-protected ZIP exfiltration (from v2 onward)

---

6. What Does Grixba Actually Hunt For?

Grixba's scanning targets fall into three categories: security products (AV/EDR), remote management tools (RMM), and backup solutions. Understanding what it scans for tells us exactly which defensive gaps the Play operators are looking to exploit before they detonate ransomware.

Security Products Targeted (AV/EDR): Windows Defender, CrowdStrike Falcon, SentinelOne, Carbon Black, Morphisec, Symantec, Malwarebytes, Kaspersky, ESET, Bitdefender, Sophos, Trend Micro, McAfee/Trellix, MVISION, WithSecure, WatchGuard, FireEye, F-Secure, Heimdal, HitmanPro, VIPRE, DeepArmor, Dr.Web, and others.

Remote Management Tools Targeted (RMM): TeamViewer, AnyDesk, ConnectWise Control, NinjaOne, Kaseya VSA, BeyondTrust, GoTo Resolve, Splashtop, Atera, Zoho Assist, Action1, Pulseway, DameWare, Radmin, and others. These tools can be weaponized for lateral movement or hijacked for persistence.

Backup Solutions Targeted: Veeam, Acronis, Backup Exec, IDrive, Synology C2, Dropbox backups, Windows Backup, shadow copy utilities (Play also uses a separate AlphaVSS-based companion tool for VSS wiping). Knowing what backup tools are present helps operators plan targeted disruption before encryption.

The color-coded version tracking in the original research shows that v1 covered the core list in grey, v1.5 expanded it (purple additions), v2 dramatically broadened it (green additions), and v3 pruned the v2 additions back (red removals), retaining only the most consistently valuable targets.

---

7. MITRE ATT&CK Analysis: What the Sandbox Revealed

The original researcher conducted direct sandbox execution of all four binaries rather than relying solely on public reports. The MITRE ATT&CK findings reflect actual runtime behavior. A notable trend: technique count decreases across versions — v1 and v1.5 each triggered 12 techniques, v2 triggered 10, and v3 triggered only 8. The tool becomes progressively quieter with each version, generating fewer detectable behaviors as the architecture is simplified.

Key Findings from Sandbox Analysis

1. Architecture flip: x86 → x64 → x86
v1 and v1.5 are 32-bit (x86) binaries. v2 upgraded to 64-bit (x64). v3 reverted back to 32-bit. This is significant: 32-bit .NET processes run under WOW64 on modern 64-bit Windows, adding a translation layer that some EDR hooks do not cover as comprehensively as native 64-bit processes. The reversion to 32-bit in v3 may be deliberate evasion engineering.

2. EDR unhooking present in all four versions — but the method changed
Every version modifies ntdll.dll memory protection to PAGE_READWRITE to unhook EDR instrumentation. However, in v1 and v1.5, this is paired with direct syscalls from unbacked memory — a more aggressive technique that calls kernel functions directly, bypassing ntdll entirely. In v2 and v3, the direct unbacked syscall technique is absent. The developers traded raw aggression for cleaner execution in later versions.

3. AMSI and WLDP loaded in v1, v1.5, v2 — completely absent in v3
v1 through v2 load amsi.dll (Antimalware Scan Interface) and wldp.dll (Windows Lockdown Policy) from unbacked callers — indicative of bypass attempts before executing the managed payload. v3 loads neither. This is the single most significant behavioral change between v2 and v3, eliminating a class of alerts that the first three versions consistently triggered.

4. Identical self-read offset in v1 and v1.5 — codebase fingerprint
Both v1 and v1.5 read from their binary images at the same offset (0x3030785c3030785c), confirming they share the same Costura bootstrapper code and identical packing. This confirms a direct code lineage between the two versions.

5. v3 added new locale/language APIs — not in any prior version
v3 resolves LCIDToLocaleName, GetUserDefaultLocaleName, GetLocaleInfoEx, GetUserPreferredUILanguages, LocaleNameToLCID, and GetConsoleCP. Combined with the persistent en-US geofencing registry check present in all four versions, this suggests v3 expanded its locale-awareness — possibly to avoid execution in non-English-language environments, or to support new targeting criteria introduced alongside the DPRK partnership context.

6. v2 uniquely added timezone and shell APIs
v2 resolves RtlGetSystemTimeAndBias, GetDynamicTimeZoneInformation, and loads shell32.dll, tzres.dll, and related APIs. None appear in v1, v1.5, or v3 — consistent with v2's expanded reconnaissance scope and its 18-table ExportData.db structure, which required timezone-aware and shell folder enumeration capabilities.

Universal Detection Rule (All Four Versions)

The original research identifies a four-behavior chain confirmed present across every version from September 2022 to November 2024:

1. Process modifies ntdll.dll to PAGE_READWRITE
2. Registers a Vectored Exception Handler (VEH)
3. Creates RWX (Read-Write-Execute) memory
4. Checks registry key: HKLM\SYSTEM\ControlSet001\Control\Nls\CustomLocale\en-US

Any process that executes this sequence in order is exhibiting Play's Grixba execution pattern. This is the most durable detection rule in the entire Grixba analysis corpus — it survives architectural changes, size regressions, and PE metadata changes across all four versions.

---

8. The Mutex: CPFATE_2704_v4.0.30319

A mutex named CPFATE_2704_v4.0.30319 was found in two of the four samples (v1 and v2). Breaking down the components:

• CPFATE: A custom operator-defined prefix. Not a Windows system mutex and not associated with any legitimate application.
• 2704: Likely a hardcoded build or version identifier, or a PID baked into the mutex name at runtime.
• v4.0.30319: The exact .NET Framework 4.0 runtime version string (Microsoft .NET Framework 4.0.30319), suggesting the mutex is constructed programmatically as: "CPFATE_" + hardcoded_id + "_" + Environment.Version.ToString()

The implications for defenders and analysts are significant:

• Same author confirmed: Finding an identical custom mutex prefix across a September 2022 and May 2023 build confirms the same person or team developed both — v2 is a direct evolution, not a separate tool that was relabeled.
• Shared code lineage: The mutex creation code was carried forward verbatim from v1 to v2, confirming direct codebase inheritance.
• OpSec failure: Any EDR or hunting query looking for mutex creation events containing CPFATE will catch both v1 and v2 regardless of filename, PE metadata, or binary size changes.
• .NET 4.x dependency confirmed: v4.0.30319 locks the runtime requirement — both samples require .NET Framework 4.x on the victim machine.

The mutex has not been observed in v1.5 or v3 analysis yet, but the pattern is a valuable hunting artifact for v1 and v2 detections.

---

9. Capability Verdict: Which Version Is Most Dangerous?

From an attacker's perspective, the original research concludes that v2 (727 KB, May 2023) is the strongest overall sample — it combines peak capability (ExportData.db with 18 intelligence tables, expanded scan list, encrypted modular architecture, anonymized C2) with moderate evasion. However, each version makes different trade-offs:

Version	Capability	Evasion	Operational Agility	Best For
v1	Moderate	Low	Low (monolithic)	Initial reconnaissance, simple targets
v1.5	Moderate+	Low	Low (monolithic)	Network-wide host discovery
v2	High	Moderate	Moderate	Deep pre-encryption intelligence gathering
v3	Moderate	High	High (staged)	Evading mature v2 detection stacks, varied deployment contexts

v3's reduced capability is a deliberate trade-off — the operators accepted less detailed intelligence output in exchange for dramatically improved evasion of the detection ecosystem that had built up around v2 over 18 months.

---

10. Weakness Analysis: Where Defenders Can Win

Every version of Grixba has structural weaknesses that defenders can exploit. Some were fixed across versions. The weaknesses that remain unfixed across all four versions are the most important for building durable detection.

Weaknesses Fixed in Later Versions

• Plaintext export.zip (v1, v1.5): All CSV output immediately readable by incident responders. Fixed in v2 with password-protected data.zip.
• No PE metadata disguise (v1, v1.5): Binary easily identifiable as unknown with no legitimate cover story. Fixed in v2 with SentinelOne impersonation (then removed in v3).
• Console help screen revealing all modes (v1): Executing without correct arguments printed all supported modes and output file names. Obscured in v2.
• Browser history SMB paths triggering Snort rules (v1.5): Nine specific SMB access patterns to browser history databases were detectable at the network layer with published Snort rules.
• Hard-coded GUID enabling data.zip decryption (v2): The GUID E8B10161-0849-4984-A6BF-3D1B267615CC- in inf_g.dll allows defenders who recover the sample to decrypt the exfiltration archive. Not fixed in v3.
• 727 KB anomalous binary size (v2): Detectable by ML-based size/entropy heuristics. Fixed in v3.
• data.dat + inf_g.dll two-file deployment fingerprint (v2): A highly distinctive drop pattern. Fixed in v3 by externalizing the payload.

Weaknesses Persistent Across All Versions (Never Fixed)

• Drop path unchanged — C:\Users\Public\Music\ via RDP: Every single version of Grixba across 26 months has been dropped to this exact path via Remote Desktop Protocol. This is the most significant unforced operational security error in the tool's history. Any EDR or file-integrity monitoring alerting on executable writes to this directory from RDP sessions catches every version.
• WMI/WinRM enumeration generates high-volume telemetry: Grixba's primary function produces a distinctive pattern of rapid lateral WMI connections from one source host to multiple targets in a short time window — a well-known lateral movement indicator. This has never changed because it is the core capability.
• No anti-sandbox or anti-debug capability: None of the four versions check for VM artifacts, low uptime, unusual process lists, or virtual NIC vendors. Running any version in a sandbox produces a complete execution trace. This basic capability — common in commodity malware — has never been implemented.
• .NET managed IL is trivially decompilable: Building in .NET means every version decompiles to near-source code with freely available tools (dnSpy, ILSpy). No obfuscation layer has been applied to any version. v2's XOR encryption of inf_g.dll adds one step, but once decoded, it decompiles identically.

New Weaknesses Introduced in v3

• Staged delivery creates a single point of failure: If the second-stage payload is blocked or detected in transit, the dropper alone is useless. Unlike v2 which was fully self-contained, v3's operational success depends on a delivery dependency.
• GT_NET.exe filename without the SentinelOne cover story: In v2, the filename was paired with convincing PE metadata making it look legitimate. In v3, the metadata was removed but the recognizable filename remains — arguably making it more suspicious than before.

---

11. The DPRK Connection

In October 2024, security researchers confirmed that North Korean state actor Jumpy Pisces (Andariel) had been operating alongside Play Ransomware as an initial access broker. The November 2024 v3 compilation coincides directly with the period of active DPRK collaboration.

The v3 architectural choices — leaner, stageable, lower fingerprint — may reflect not just evasion of public detection but also the operational requirements of a new partner. A 727 KB monolithic EXE with database engine bundled is harder to adapt to varied intrusion contexts. A lean loader stub that stages its payload on demand is far more versatile across the diverse deployment environments that a state-actor initial access broker would encounter.

The expanded locale/language APIs newly introduced in v3 also support this hypothesis: greater locale awareness could serve geofencing requirements for DPRK operational security, avoiding execution in environments that would trigger unwanted attention.

---

12. Detection Strategy and Hunting Guidance

Based on the four-version analysis, here is a prioritized detection framework for defenders:

Tier 1: Highest Confidence, Version-Agnostic

• File writes to C:\Users\Public\Music\ from RDP sessions: The single most reliable indicator across all versions and 26 months. Monitor for any executable (.exe, .dll, .dat) written to this path during or immediately after an RDP session.
• 4-behavior execution chain: ntdll PAGE_READWRITE modification + VEH handler registration + RWX memory creation + HKLM\SYSTEM\ControlSet001\Control\Nls\CustomLocale\en-US registry check in sequence.
• Rapid lateral WMI connections: One source host initiating WMI queries against multiple targets within a short time window, especially combined with WinRM and Remote Registry access patterns.

Tier 2: High Confidence, Version-Specific

• Mutex creation events containing "CPFATE": Catches v1 and v2 regardless of other changes.
• GT_NET.exe process name: Used across multiple versions with only cosmetic PE metadata changes.
• EvtOpenLog / EvtClearLog API calls + WMI activity log wipe in sequence: The Clr (log clearing) mode present in every version.
• ntdll.dll memory protection modification to PAGE_READWRITE: EDR unhooking behavior present in all four versions.

Tier 3: Version-Specific (Still Valuable for Triage)

• ExportData.db presence on disk (v2 indicator)
• data.dat + GT_NET.exe co-presence in C:\Users\Public\Music\ (v2 indicator)
• Network connection to 84.239.41.12 (v2 C2 indicator)
• Browser history SMB access across Chrome/Edge/Firefox/IE paths in sequence (v1.5 indicator)

What to Avoid Over-Indexing On

• Binary size thresholds (changed dramatically across versions)
• SentinelOne PE metadata strings (removed in v3)
• Specific CSV file names like alive.csv, soft.csv (removed in v2)
• Hash-based detections as the primary signal (each version is a new hash)

---

13. IOC Reference Table

File Hashes (SHA-256)

Hash	Description
453257c3...65deb	Infostealer.Grixba baseline (v1)
c59f3c8d...904b7	Play network scanner / Gt_net.exe (v1.5, CISA AA23-352A)
f8810179...353a	Peak-capability build (v2)
36214681...6e94	Stripped/staged build (v3)
b4505ab4...b7	inf_g.dll — XOR-decoded CoreScanner module
5922b1a7...18	XOR-encrypted payload carrier (data.dat)
f71476f9...b6	Infostealer.Grixba cluster (Symantec)
f81bd2ac...f9	All VSS Copying Tool (AlphaVSS-based companion)

Network Indicators

• IP: 84.239.41(.)12 — PIA VPN exit node used as v2 C2

File System Indicators

• Drop path: C:\Users\Public\Music\ (all versions)
• Filenames: GT_NET.exe, GT_NET.exe (lean), data.dat, inf_g.dll, ExportData.db, export.zip, data.zip
• Embedded GUID: E8B10161-0849-4984-A6BF-3D1B267615CC-

Mutex

• CPFATE_2704_v4.0.30319 (observed in v1 and v2)

Tor Infrastructure (Play Ransomware)

• x6zdxw6vt3gtpv35yqloydttvfvwyrju3opkmp4xejmlfxto7ahgnpyd(.)onion
• b3pzp6qwelgeygmzn6awkduym6s4gxh6htwxuxeydrziwzlx63zergyd(.)onion
• p2qzf3rfvg4f74v2ambcnr6vniueucitbw6lyupkagsqejtuyak6qrid(.)onion
• whfsjr35whjtrmmqqeqfxscfq564htdm427mjekic63737xscuayvkad(.)onion
• mbrlkbtq5jonaqkurjwmxftytyn2ethqvbxfu4rgjbkkknndqwae6byd(.)onion
• k7kg3jqxang3wh7hnmaiokchk7qoebupfgoik6rha6mjpzwupwtj25yd(.)onion
• j75o7xvvsm4lpsjhkjvb4wl2q6ajegvabe6oswthuaubbykk4xkzgpid(.)onion

---

14. Conclusion

The four-version arc of Grixba is one of the clearest documented examples of a ransomware group's feedback loop with the detection ecosystem. Play built a tool, watched it get detected, expanded it dramatically in response to the first detections, and then — after that expansion became the new detection baseline — stripped it back below the original baseline to escape again.

The April 2023 Symantec disclosure was answered in three weeks with v2. The 18 months of progressive v2 analysis from Symantec, CISA, Trend Micro, and Field Effect MDR was answered by November 2024 with v3 — a build smaller than v1, carrying none of the artifacts that made v2 detectable, and architecturally suited for the new DPRK partnership context.

For defenders, the message is straightforward: do not anchor detection to any single version's artifacts. The only constants across all four versions are the C:\Users\Public\Music\ drop path from RDP sessions and the WMI/WinRM enumeration behavior. While size, filename, PE metadata, output format, and archive structure have all changed, this behavioral pair has held steady across 26 months and four architectural generations.

Hunt the behavior. Not the binary.

---

References and Further Reading

• Original Research: RakeshKrish, "Decoding Grixba — A Play Ransomware Scanner," The Raven File, June 8, 2026. https://theravenfile.com/2026/06/08/decoding-grixba-a-play-ransomware-scanner/
• CISA/FBI Advisory AA23-352A — Play Ransomware
• Symantec Threat Intelligence — Infostealer.Grixba (April 2023)
• Field Effect MDR — Grixba / Play Ransomware impersonates SentinelOne (January 2025)
• Trend Micro — Play Ransomware Analysis

---

Tags: Play Ransomware, Grixba, Malware Analysis, Infostealer, .NET Malware, MITRE ATT&CK, Ransomware, Threat Intelligence, EDR Evasion, DPRK Threat Actor, Jumpy Pisces, Andariel, Incident Response, IOC, Hunting

SEO Poisoning Leads to Fake Claude Code Infostealer Attacks

Attackers are exploiting the Claude Code adoption wave. A six-stage fileless infostealer is being delivered through a poisoned search result to first-time developers who think they are following an installation guide. Here is everything you need to know.

Credit and original research: Cyderes Howler Cell

Why this campaign matters before we get to the technical details

Most malware campaigns target careless users or misconfigured systems. This one targets something different: enthusiasm.

Claude Code has opened software development to people who never thought it was accessible to them. A small business owner automating their invoicing. A teacher building a grading tool. An entrepreneur with an app idea and, for the first time, a realistic path to shipping it. These are the people this campaign is hunting. Not IT administrators ignoring security policy. First-time builders sitting down to install a tool they are genuinely excited about, following instructions that look completely legitimate.

The attacker did not need to trick a security professional. They needed to be at the top of a search result when someone motivated, trusting, and technically inexperienced went looking for a getting-started guide. SEO poisoning put them there. And unlike a corporate user, this audience typically has no proxy filtering, no endpoint detection, and no security team to call. What they have is a browser, a search engine, and instructions that look exactly like every other installation guide they have ever followed.

Cyderes Howler Cell identified and documented this campaign in full. What follows is a technical breakdown of their findings, with analysis of what makes this chain particularly dangerous and what defenders need to do about it.

The attack chain at a glance

The full delivery chain is six stages deep, entirely fileless after Stage 1, and engineered to defeat file inspection, AMSI, EDR telemetry, sandbox analysis, and static IOC matching simultaneously. Here is the sequence:

Initial access begins with an SEO-poisoned search result for "claude code install" leading to a spoofed Anthropic install page. The page looks right. The branding is convincing. The instructions feel familiar.

Execution happens through a ClickFix lure. The victim is instructed to open the Windows Run dialog using Win+R and paste a pre-staged mshta.exe command, framed as a required step to complete the installation. This is hands-on keyboard execution rather than automated drive-by delivery, which bypasses many endpoint controls that key on automated or scripted execution patterns. The victim complies because they have no baseline for what legitimate installation should or should not ask them to do.

Stage 1 sees mshta.exe retrieve an MP3/HTA polyglot payload from download.version-516[.]com, a software-update-themed lure domain designed to look like a routine update server.

Stage 2 has the HTA spawn cmd.exe, which runs an encoded PowerShell script performing three operations: an AMSI bypass, RC4 string decryption, and victim fingerprinting via an MD5 hash of the machine name and username.

Stage 3 downloads a second PowerShell script from a per-victim subdomain on oakenfjrod[.]ru, executed entirely in memory. The script is 17 MB, a size engineered deliberately to break analysis tooling.

Stage 4 delivers a reflective .NET infostealer that beacons to Russian infrastructure at 185[.]177[.]239[.]255:443 for credential exfiltration. Nothing is written to disk. No new process is spawned.

Before going deeper, one clarification that matters: Anthropic is not compromised. The legitimate Claude Code installation path is unaffected. This campaign is brand impersonation, not a supply chain attack.

Stage 1: The MP3/HTA polyglot and why it defeats file inspection

The payload retrieved by mshta.exe in Stage 1 is one of the more technically elegant evasion constructions seen in commodity malware recently. It is a 6.7 MB file that simultaneously satisfies the parsing rules of two completely different file formats: MP3 and HTA.

The file carries a valid ID3v2.4 tag, embedded JPEG cover art, and playable MPEG audio frames occupying the first approximately 4.7 MB of the file. It is a real, playable MP3. Open it in VLC or Windows Media Player and it plays. A security tool that classifies files by header, magic bytes, or content inspection will see a legitimate MP3 and move on.

When mshta.exe processes the same file, it parses linearly. It moves past the audio content, reaches the embedded HTA script block at the end of the file, and executes it. The same bytes, two completely different runtime interpretations. Sandbox environments that open the file as media may deprioritise analysis entirely, which is precisely the intent.

This is the Living Off the Land principle applied at the file format level. The attacker is not hiding malicious code in an obviously suspicious container. They are hiding it inside something that looks like exactly what it claims to be.

Defender note: mshta.exe initiating outbound HTTPS connections to external infrastructure has no legitimate use in most enterprise environments. Blocking or alerting on mshta.exe network activity catches this stage regardless of payload obfuscation. MITRE technique: T1218.005.

Stage 2: AMSI bypass, RC4 decryption, and victim fingerprinting

The HTA registered a scheduled task through the Schedule.Service COM object to spawn cmd.exe with delayed-expansion enabled. The command line reconstructed the string "powershell" at runtime using split variables to break static signature detection, then explicitly invoked the 32-bit PowerShell binary at %windir%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe.

Targeting the 32-bit binary is deliberate. EDR telemetry coverage is frequently weighted toward 64-bit process activity. By invoking the 32-bit PowerShell host, the attacker reduces the likelihood of being captured in high-fidelity telemetry streams that a security operations team would be monitoring.

The PowerShell script executed a Base64-encoded payload that performed three sequential operations. First, an AMSI bypass: it patched System.Management.Automation.AmsiUtils.amsiInitFailed in memory via Marshal::WriteInt32, disabling in-process script scanning before any further stages are executed. This is a well-documented technique, but its effectiveness depends on the EDR not having already instrumented the AMSI interfaces at a lower level. Many commodity endpoints have not.

Second, RC4 string decryption: sensitive string constants were decrypted at runtime using the hardcoded key BWJFEesMEqRvjQbm, keeping indicators out of static analysis. Any analyst examining the script without executing it sees only ciphertext where the meaningful strings would be.

Third, victim fingerprinting: the script computed an MD5 hash of COMPUTERNAME concatenated with USERNAME to generate a unique subdomain label for the Stage 3 download URL. This fingerprinting step is the architectural foundation of the campaign's most effective IOC-defeating mechanism.

Defender note: 32-bit PowerShell spawned from a scheduled task registered via COM object is rare in enterprise environments and represents a high-confidence detection signal. MITRE techniques: T1059.001, T1562.001, T1027.

Stage 3: The 17 MB obfuscation fortress and per-victim infrastructure

Stage 2 used the MD5 victim fingerprint as a subdomain label to construct a unique retrieval URL in the format https://MD5_HASH.oakenfjrod[.]ru/cloude-uuid. The loader issued an HTTPS GET request to this URL and piped the response directly into IEX for in-memory execution, inheriting the AMSI-disabled state from Stage 2. Nothing was written to disk.

The retrieved Stage 3 script is approximately 17 MB. This is not accidental. Legitimate PowerShell loaders are typically under 100 KB. The size here is engineered as a weapon against the analysis pipeline itself.

Automated deobfuscators have memory and time limits. Sandbox environments have resource constraints. Human analysts have finite patience for unwinding nested obfuscation layers at 17 MB of scale. The size is a deliberate tax on the defender's analysis capability, designed to make full deobfuscation expensive enough that many analysts will give up or accept a partial result.

The obfuscation layers stacked inside this script are comprehensive. Massive integer-encoded byte arrays that must be reconstructed before any logic surfaces. Multi-layer string fragmentation using split-and-concatenate chains and character-code substitution. Runtime variable name mangling with identifiers reassigned dynamically to break cross-references between analysis passes. Stacked Base64 and RC4 decryption layers that must be unwound in the correct sequence. A third XOR layer using the key AMSI_RESULT_NOT_DETECTED, a detail worth pausing on: the attacker used Microsoft's own AMSI bypass indicator string as a decryption key, which is either a deliberate provocation or a functional choice that also serves as a signature-defeating red herring. And finally, the reflective .NET shellcode carried inline as a byte array, removing the need for any additional network fetch at this stage.

The per-victim subdomain structure deserves particular attention from a threat intelligence perspective. Every victim gets a unique URL derived from their machine name and username. Static IOC sharing at the URL level is therefore functionally useless. Sharing the URL a specific victim connected to does nothing for the next victim, because their URL will be completely different. The only meaningful IOC at this layer is the domain itself: oakenfjrod[.]ru. Wildcard blocking on that domain is the correct defensive response, not per-subdomain matching.

Defender note: DNS queries to *.oakenfjrod[.]ru are a strong indicator of compromise. Block and alert at the domain level. Per-subdomain IOC matching is ineffective by design. MITRE techniques: T1568, T1620.

Stage 4: The reflective .NET infostealer and what it takes

The terminal stage is a .NET-based infostealer delivered as raw bytes embedded inside the Stage 3 PowerShell script. It is never written to disk. It never loads as a module. It never spawns a child process. The entire stealer executes inside the existing powershell.exe address space.

The loading technique abuses the .NET Framework's built-in ability to execute managed code directly from a byte array in memory via Assembly.Load(byte[]). This is functionally equivalent to techniques used by Cobalt Strike's execute-assembly, Donut, and SharpSploit, but executed entirely from PowerShell without an unmanaged loader stub. The consequence for defenders is significant: there is no file artifact on disk, no new process entry in the process tree, and no image-load event tied to a suspicious file path. The traditional tripwires that defenders have built detection around simply do not fire.

The infostealer beacons over HTTPS to 185[.]177[.]239[.]255:443 for command and control and credential exfiltration. The IP resolves to Russian infrastructure. SensitiveFileRead telemetry from Cyderes Howler Cell's analysis confirms browser credential store access during execution, meaning the stealer is actively harvesting saved passwords, session tokens, and authentication cookies from the victim's browser profiles.

Defender note: .NET assembly loads from PowerShell without a corresponding file on disk are detectable via ETW (Event Tracing for Windows) and process memory inspection. EDR platforms with .NET assembly load visibility catch this where file-based controls cannot. MITRE techniques: T1620, T1555.003, T1041.

The full MITRE ATT&CK mapping

T1204.003 User Execution via ClickFix: Win+R paste of attacker-supplied MSHTA command triggering hands-on keyboard execution.

T1218.005 Signed Binary Proxy via mshta.exe: mshta.exe fetched and executed a remote HTA payload disguised as an MP3 file.

T1059.001 PowerShell: Base64 and RC4-obfuscated encoded commands across multiple stages.

T1027 Obfuscated Files or Information: RC4 encryption of sensitive string literals, integer-encoded byte arrays, and runtime variable mangling.

T1562.001 Impair Defenses via AMSI Bypass: Marshal::WriteInt32 used to set amsiInitFailed via reflection, disabling in-process script scanning.

T1620 Reflective Code Loading: Reflective .NET stealer loaded entirely in memory via Assembly.Load(byte[]), leaving no file artifact.

T1071.001 Application Layer Protocol via HTTPS: C2 communications on port 443 across all stages, blending with legitimate encrypted traffic.

T1568 Dynamic Resolution: Per-victim C2 subdomain derived from MD5(COMPUTERNAME+USERNAME), making static IOC sharing ineffective.

T1555.003 Credentials from Browser: SensitiveFileRead events confirm browser credential store access during final stage execution.

T1041 Exfiltration Over C2 Channel: Harvested credentials exfiltrated to 185[.]177[.]239[.]255.

Indicators of compromise

Domain: download.version-516[.]com - HTA payload delivery, fake Claude download site

Domain: oakenfjrod[.]ru - Stage 3 C2, block as wildcard *.oakenfjrod[.]ru

IP: 185[.]177[.]239[.]255 - Final stealer C2, Russian infrastructure

URL pattern: https://[md5_16char].oakenfjrod[.]ru/cloude-[uuid] - Per-victim beacon URL structure, unique per machine

What makes this campaign notable and what to do about it

The operators behind this campaign did not rely on a single trick. They stacked deliberate evasion choices end-to-end and produced a chain where each traditional detection surface has been accounted for at the design stage. The MP3/HTA polyglot defeats file-type filtering. The 32-bit PowerShell invocation reduces EDR telemetry coverage. The AMSI bypass clears the path for in-memory execution. The 17 MB Stage 3 script is sized to break analysis tooling and exhaust sandbox resources. The per-victim subdomain structure neutralises static IOC sharing. The reflective .NET final stage leaves no file, no new process, and no image-load artifact.

What is notable is not the novelty of any individual technique. Each component is documented and understood by the security community. What is notable is the targeting logic: a rapidly growing population of non-technical users with high motivation, low threat awareness, and a search engine that, for a moment, put the attacker exactly where a legitimate download page should have been.

For defenders, the actionable steps are clear. Block mshta.exe outbound network connections at the endpoint level. Alert on 32-bit PowerShell spawned from scheduled tasks registered via COM objects. Apply wildcard DNS blocking on oakenfjrod[.]ru immediately. Deploy EDR platforms with ETW-based .NET assembly load visibility. And brief non-technical users in your organisation who may be using AI development tools: if an installation guide asks you to paste a command into the Windows Run dialog, stop and verify before proceeding.

For the broader security community, this campaign is a preview of what commodity malware targeting AI-tool adopters will look like as the developer population expands. The attack surface is growing faster than the security awareness of the people being added to it. Campaigns like this one are a direct consequence of that gap.

Full technical research and IOC details by Cyderes Howler Cell. Subscribe to their research feed for ongoing infrastructure tracking and updates as this campaign evolves.

MITRE ATT&CK techniques referenced: T1204.003, T1218.005, T1059.001, T1027, T1562.001, T1620, T1071.001, T1568, T1555.003, T1041

The Last Line:

The Last Line of Defence: How Ransomware Erases Your Recovery Options Before Encryption

Modern ransomware attacks do not begin with encryption. They begin with preparation. Long before employees see ransom notes or encrypted files, attackers quietly disable recovery mechanisms, destroy backups, and erase Windows Volume Shadow Copies. By the time encryption starts, the organization has already lost its easiest recovery path.

This article explores how ransomware families abuse tools such as vssadmin, wmic, PowerShell, and direct COM API access to destroy recovery options. We will also explore how defenders can detect these attacks early using threat hunting, SIEM correlation, behavioral analysis, and security monitoring.

Table of Contents

• What Are Shadow Copies?
• Why Shadow Copies Matter During Ransomware Attacks
• The Modern Ransomware Kill Chain
• How Attackers Use vssadmin
• How Attackers Use WMIC
• PowerShell and Advanced Evasion
• Real Ransomware Families and Techniques
• Threat Hunting and Detection Strategies
• How Organizations Should Defend Themselves
• Future of Ransomware Defense

What Are Shadow Copies?

Volume Shadow Copy Service, commonly called VSS or Shadow Copies, is a Windows technology that creates point-in-time snapshots of files and storage volumes. Microsoft introduced this feature to help users recover previous versions of files, restore systems after failures, and support backup applications.

When a user right-clicks a file in Windows and selects “Previous Versions,” the operating system may retrieve the file using VSS snapshots. These snapshots silently exist in the background and are incredibly valuable during ransomware incidents.

For many organizations, shadow copies become the fastest recovery mechanism after accidental deletion or corruption. Security teams often discover during ransomware response that shadow copies represent the difference between quick recovery and catastrophic downtime.

“Ransomware operators understand one critical principle: destroying backups increases the probability of payment.”

Because of this, ransomware operators aggressively target:

• Volume Shadow Copies
• Backup servers
• Database snapshots
• Cloud backup agents
• Recovery catalogs
• Disaster recovery infrastructure

Why Shadow Copies Matter During Ransomware Attacks

Many organizations mistakenly assume ransomware attacks begin with encryption. In reality, modern ransomware campaigns are highly organized operations involving:

• Initial access
• Credential theft
• Lateral movement
• Privilege escalation
• Data exfiltration
• Recovery destruction
• Encryption deployment

Destroying shadow copies gives attackers enormous leverage. Without recovery options, organizations face:

• Longer downtime
• Business disruption
• Higher recovery costs
• Operational paralysis
• Increased pressure to pay ransom

Ransomware Statistics

• More than 90% of modern ransomware attacks attempt backup destruction.
• Average ransomware recovery costs continue rising yearly.
• Downtime often lasts weeks after enterprise ransomware incidents.
• Double extortion attacks now combine encryption and data theft.

Attackers no longer depend only on encryption. They depend on psychological pressure.

If victims can restore systems easily, ransom payments decrease significantly. Therefore, deleting shadow copies is often prioritized before encryption even begins.

The Modern Ransomware Kill Chain

Modern ransomware groups operate like professional businesses. Many ransomware gangs use a Ransomware-as-a-Service model where affiliates perform attacks using shared malware platforms.

Stage 1: Initial Access

Attackers enter organizations through:

• Phishing emails
• Compromised VPN accounts
• Exposed RDP servers
• Software vulnerabilities
• Third-party supply chain compromises

Stage 2: Privilege Escalation

Attackers attempt to obtain administrator or SYSTEM privileges. Without elevated permissions, many destructive operations cannot succeed.

Stage 3: Internal Reconnaissance

Threat actors map the environment carefully:

• Domain controllers
• File servers
• Database servers
• Backup systems
• Security software

Stage 4: Data Exfiltration

Modern ransomware operations frequently steal sensitive files before encryption. This allows attackers to threaten public leaks if victims refuse payment.

Stage 5: Shadow Copy Destruction

This stage is critically important.

Attackers disable:

• Windows recovery features
• Backup agents
• VSS snapshots
• System restore points

Stage 6: Encryption

Only after preparation is complete does encryption begin.

By then, attackers often already control the environment completely.

How Attackers Use vssadmin

One of the most abused Windows utilities in ransomware operations is:

vssadmin.exe

This built-in Windows tool manages Volume Shadow Copy Service snapshots.

Attackers commonly execute:

vssadmin delete shadows /all /quiet

This command silently deletes all shadow copies without requiring user confirmation.

The command is devastatingly effective because:

• It uses legitimate Microsoft software
• It exists on almost every Windows system
• Many security tools historically trusted it
• It requires minimal attacker effort

This technique belongs to a broader category known as:

Living Off The Land (LotL)

Living Off The Land techniques use legitimate operating system tools for malicious purposes. This helps attackers evade antivirus products and reduce suspicious malware artifacts.

Why vssadmin Detection Is Difficult

System administrators legitimately use vssadmin for:

• Storage management
• Backup maintenance
• Troubleshooting
• System recovery operations

Therefore, security teams cannot simply alert on every vssadmin execution. Effective detection requires context.

How Attackers Use WMIC

As defenders improved monitoring for vssadmin abuse, ransomware operators adapted quickly.

They increasingly shifted toward:

wmic shadowcopy delete

WMIC, or Windows Management Instrumentation Command-line utility, provides another method for manipulating system management functions.

Attackers realized many detection systems only monitored vssadmin command lines. Switching to WMIC helped bypass simplistic detection logic.

Why WMIC Is Dangerous

WMIC allows:

• Remote administration
• System inventory collection
• Shadow copy manipulation
• Process execution
• Persistence techniques

Attackers increasingly combine WMIC with:

• PowerShell
• Encoded commands
• Scheduled tasks
• Remote execution frameworks

This makes forensic analysis significantly more complicated.

PowerShell and Advanced Evasion

Modern ransomware groups rarely rely on a single technique.

As defenders improve visibility into command-line tools, attackers migrate toward:

• PowerShell automation
• Direct API calls
• COM interface abuse
• Custom binaries

Encoded PowerShell Commands

Attackers frequently Base64 encode PowerShell commands to hide suspicious strings from security tools.

Example techniques include:

• Encoded WMI commands
• Memory-only execution
• Fileless malware behavior
• Reflection-based execution

COM API Abuse

Some advanced ransomware families bypass vssadmin and WMIC entirely.

Instead, they directly call Windows COM interfaces associated with VSS management.

This significantly reduces forensic evidence because:

• No suspicious command lines appear
• No child processes spawn
• Traditional EDR signatures may fail
• Behavior resembles legitimate system activity

“The future of ransomware detection depends on behavioral analysis, not simple signature matching.”

Real Ransomware Families and Techniques

Different ransomware groups use different methods for destroying recovery infrastructure.

Ransomware Family	Technique
LockBit	WMIC and PowerShell-based deletion
Conti	vssadmin shadow deletion
BlackCat / ALPHV	Rust-based payloads and API abuse
Hive	Shadow storage resizing and deletion
REvil	Combined backup and VSS destruction
BlackMatter	Direct COM API invocation

LockBit

LockBit became one of the most widespread ransomware families globally. Its operators aggressively evolved techniques to evade detection.

Security researchers observed LockBit variants rotating between:

• vssadmin
• WMIC
• PowerShell
• Encoded commands

This flexibility made static detection rules unreliable.

BlackCat / ALPHV

BlackCat attracted attention because it used the Rust programming language.

Rust offers:

• Cross-platform capability
• Memory safety advantages
• Complex analysis challenges
• Efficient execution

BlackCat operators focused heavily on stealth and minimized suspicious process creation.

Threat Hunting and Detection Strategies

Effective ransomware defense requires layered visibility.

Organizations should monitor:

• Process creation events
• Command-line arguments
• PowerShell execution
• WMI activity
• Privilege escalation
• Mass file modification behavior

Behavior-Based Detection

Security teams should focus on intent rather than only syntax.

For example:

• Unknown process spawning vssadmin at 2 AM
• Backup deletion combined with credential dumping
• Bulk process termination before encryption
• Simultaneous security tool tampering

These patterns strongly indicate malicious activity.

SIEM Correlation

Modern SIEM platforms should correlate:

• Process telemetry
• Network connections
• User authentication
• Threat intelligence feeds
• Endpoint behavior

Single alerts are often noisy. Correlated behaviors create higher confidence detection.

Threat Hunting Queries

Threat hunters commonly search for:

vssadmin delete shadows wmic shadowcopy delete powershell Get-WmiObject Win32_ShadowCopy

However, mature hunting teams also investigate:

• Encoded PowerShell
• Suspicious parent-child process relationships
• Rare administrative tool execution
• Abnormal administrative activity

How Organizations Should Defend Themselves

1. Immutable Backups

Organizations must implement backup systems attackers cannot modify easily.

Immutable backups prevent:

• Deletion
• Encryption
• Tampering
• Unauthorized modification

2. Privileged Access Management

Restricting administrative privileges reduces attacker capability dramatically.

Many ransomware attacks succeed because:

• Users possess unnecessary privileges
• Shared admin accounts exist
• Password reuse occurs
• Domain-wide privileges remain excessive

3. EDR and Behavioral Monitoring

Endpoint Detection and Response platforms should monitor:

• Process execution chains
• Script behavior
• Memory anomalies
• Persistence techniques
• Recovery destruction attempts

4. Network Segmentation

Segmentation prevents attackers from moving freely across environments.

Critical infrastructure should remain isolated from:

• User workstations
• Development systems
• Internet-facing services

5. Incident Response Preparedness

Organizations should rehearse ransomware response scenarios regularly.

Prepared teams recover faster because:

• Roles are predefined
• Recovery procedures exist
• Communication plans are established
• Forensic workflows are tested

Future of Ransomware Defense

Ransomware continues evolving rapidly.

Future ransomware operations will likely incorporate:

• AI-assisted phishing
• Automated lateral movement
• Cloud infrastructure targeting
• EDR evasion frameworks
• Advanced anti-forensics

Defenders must evolve equally fast.

Future cybersecurity operations will increasingly depend on:

• Behavioral analytics
• Machine learning detection
• Threat intelligence sharing
• Automation
• Zero Trust architectures

“The organizations that survive ransomware attacks are not necessarily the ones with the most expensive tools. They are the ones with visibility, preparation, and disciplined operational security.”

Final Thoughts

Shadow copy deletion may appear technically simple, but its impact is enormous.

A few commands executed in seconds can transform a manageable security incident into a catastrophic business crisis.

Understanding how ransomware operators destroy recovery infrastructure is no longer optional for security professionals. SOC analysts, incident responders, threat hunters, and defenders must understand:

• How attackers abuse Windows utilities
• How modern ransomware kill chains operate
• How behavioral detection works
• How to protect recovery infrastructure

Modern ransomware defense depends not only on preventing malware execution, but also on protecting the organization's ability to recover.

Because once shadow copies disappear, the attack has already entered its most dangerous phase.