NOTE: This is the in-depth analysis of Grixba Tool specifically used by Play Ransomware Group during their Campaigns. This does NOT contain any analysis of Play Ransomware Sample.
CONTENTS
INTRODUCTIONGRIXBA TOOL: IN-HOUSE FROM PLAY RANSOMWARESIDE BY SIDE ANALYSISSIZE ANALYSISREGRESSION ANALYSISFEATURE DIFFERENCE v1 → v1.5FEATURE DIFFERENCE v1.5 → v2FEATURE DIFFERENCE v2 → v3SCANNER TARGETS26 MONTHS OF GRIXBA EVOLUTIONMITRE ATT&CK ANALYSISMUTEX: CPFATE_2704_v4.0.30319CAPABILITY VERDICTWEAKNESS ANALYSISWEAKNESS SCORECARDDPRK CONNECTION 🇰🇵TAKEAWAYSIOC TABLE
INTRODUCTION
Play Ransomware is one of the most consistent group since 2022, infecting 1200+ victims across the globe.
This group is laser focused to create havoc to US, Canada, UK primarily. This is evident from their victim list as major compromises are mapped to US, clocking at 900+.
Manufacturing, Business and Technology are the major sectors disrupted by Play Ransomware Group.
GRIXBA: IN-HOUSE TOOL FROM PLAY RANSOMWARE
Grixba is a custom Infostealer developed by Play Ransomware Group using Costura (.NET tool for embedding dependencies into single executable), which is publicly disclosed in 2023 (but originally dates back to 2022). It harvests information such as: Installed Software, User Credentials, Cryptocurrency Wallets, Messaging App Data.
In short:- It maps everything on a compromised network before the Encryption phase — security tools, backup systems, remote management software, users, machines.
We now have four samples spanning 26 months. Here are the SHA-256 hashes of the same:-
➤453257c3494addafb39cb6815862403e827947a1e7737eb8168cd10522465deb ➤c59f3c8d61d940b56436c14bc148c1fe98862921b8f7bad97fbc96b31d71193c
➤f8810179ab033a9b79cd7006c1a74fbcde6ed0451c92fbb8c7ce15b52499353a
➤3621468d188d4c3e2c6dfe3e9ddcfe3894701666bad918bc195aba0c44e46e94
Together they tell a story of rapid capability expansion, followed by a deliberate architectural regression. The binary ballooned from 164 KB to 727 KB, then was deliberately cut back to 118 KB. Each phase has a distinct purpose.
SIDE BY SIDE ANALYSIS
From the following Analyze Snapshot, we can clearly see the Transformation from Monolithic to Modular Architecture.
NOTE: On the v1.5 label – November 2022 sample (c59f3c8d61d940b56436c14bc148c1fe98862921b8f7bad97fbc96b31d71193c) is listed by CISA/FBI advisory AA23–352A as “Play network scanner / Gt_net.exe” and by Symantec as Infostealer.Grixba. It sits 7 weeks after v1 and predates the v2 architectural overhaul by 6 months — consistent with an iterative build that added network scanning breadth before the full modular redesign. We label it v1.5 to distinguish it from both the lean baseline and the feature-complete v2.
SIZE ANALYSIS
Why did it grow? v1 → v1.5 → v2
The journey from 164 KB to 727 KB across three versions took eight months. Each increment corresponds to deliberate new capability, not incidental code growth.
v1 → v1.5 (+11 KB, +6.7%)
A minor but meaningful bump. The v1.5 build — compiled just 7 weeks after the baseline — 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. The added code covers additional host enumeration paths and a slightly wider software detection list. The monolithic architecture is largely preserved; Costura bundling remains the delivery mechanism.
v1.5 → v2 (+552 KB, +315%)
The jump to 727 KB is the most dramatic in the series, driven by four concurrent changes:
➤XOR-encrypted inf_g.dll : All scan logic extracted into a bundled DLL (inf_g.dll), XOR-encrypted inside data.dat. Decoding at runtime requires an embedded base64 XOR key. The DLL itself is tens of KB.
➤SQLite Engine : Output migrated from flat CSV files to ExportData.db; bundling a database engine adds substantial size.
➤PE version-info resources : Forged SentinelOne metadata strings, company/product name blocks, and digital artifact strings embedded in the PE header.
➤Expanded Scan Radar : 14+ new AV/EDR products, 15+ new RMM tools, 5+ new backup vendors all translated to additional string tables and enumeration logic.
NOTE: The v2 binary compiled approximately 3 weeks after Symantec’s public Grixba disclosure (April 19, 2023). The operators were clearly watching detection research and responded with a substantially more evasive build.
REGRESSION ANALYSIS
Why did it shrink? v2 → v3 (−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.
The strategic logic of going smaller
After v2 was publicly documented by Symantec (April 2023), Field Effect MDR (January 2025), and eventually CISA (June 2025), the v2 IoC set was 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 one move: by stripping the bundled database engine and moving the heavy scanning logic into a separately-delivered module (no longer embedded in the EXE itself), the dropper binary is dramatically smaller, carries fewer static indicators, and evades size-based and hash-based signatures built for v2. The scanning payload can now be delivered on demand, staged only when needed.
NOTE: Detection implication in YARA rules, size thresholds, and file-name detections tuned 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.
FEATURE DIFFERENCE v1 → v1.5
In this, we are going to see the minor changes in the sample that happened between September to November 2022.
ADDED: Network Scanner Mode(Explicit Host Scanning)
The v1.5 sample expands Grixba’s enumeration to include active host discovery across IP ranges, beyond just WMI enumeration. CISA labels it a “network scanner” alongside infostealer, indicating 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 (GRXBA_webhist Snort Rules)
CISA’s published Snort detection rules for this hash trigger on a chain of 9 SMB-accessed web browser history paths (GRXBA_webhist_path_1 through _9). This means v1.5 added browser history collection — scanning for Chrome, Firefox, Edge, and Internet Explorer history databases accessible over SMB. This capability is a new data-collection dimension for credential and intelligence purposes.
ADDED: Wider Software Enumeration List
The 11 KB size increase from v1 (164 KB) to v1.5 (175 KB) is consistent with additional string tables and enumeration entries. The software detection list expanded moderately — not the large jump seen in v2, but enough to cover additional security products that may have been absent from the v1 Scan mode while not yet reaching the full Scanall breadth of v2.
RETAINED: Monolithic Architecture, CSV O/P, WinRAR Export.zip
v1.5 retains the v1 monolithic build: all logic in a single Costura-packed EXE, output in CSV flat files (alive.csv, soft.csv, wm.csv, etc.), compressed via WinRAR to export.zip without password protection. The modular XOR-encrypted DLL architecture and SQLite database output are not present yet — those arrive in v2.
FEATURE DIFFERENCE v1.5 → v2
In this, we are going to see the changes in the sample that happened between November 2022 to May 2023.
ADDED: XOR-Encrypted Modular Architecture (inf_g.dll via data.dat)
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. This separation means static analysis of the EXE alone reveals no scanning logic. It also enables the operators to update the payload (inf_g.dll) independently of the dropper (GT_NET.exe).
ADDED: PE Masquarading as SentinelOne (GT_NET.exe)
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 mimics a known EDR vendor, making the process look legitimate in Task Manager and basic triage. The irony of impersonating one of the very products the tool is designed to detect is operationally significant — it exploits defender trust in recognizable security tool names.
ADDED: SQLite DB Output — ExportData.db
All reconnaissance output is consolidated into a single structured database file (ExportData.db). This enables operators to query large-scale results efficiently, eliminates the 8 separate named CSV files that were prominent hunting artifacts in v1/v1.5, and requires bundling a SQLite engine — one of the main contributors to the 727 KB binary size.
ADDED: Obfuscated-Password Archive(data.zip)
v2 produces a password-protected data.zip rather than the plaintext export.zip of v1/v1.5. Crucially, the password printed at runtime is not the actual decryption password — it is combined with the hard-coded GUID ‘E8B10161–0849–4984-A6BF-3D1B267615CC-’ found in inf_g.dll to derive the real password. Even if an incident responder captures the tool’s console output, they cannot directly open the archive.
ADDED: C2 via PIA VPN (84.239.41.12)
v2 was observed communicating with 84.239.41.12, a Private Internet Access (PIA) VPN exit node. This provides an anonymized exfiltration channel and makes C2 attribution significantly harder. v1 and v1.5 relied on manual, offline compression with no dedicated C2 infrastructure.
ADDED: Expanded Scan List
CrowdStrike, SentinelOne, Carbon Black, Morphisec, MVISION, WithSecure, WatchGuard, FireEye, F-Secure, Heimdal, HitmanPro, VIPRE, DeepArmor, and Dr.Web added to the AV/EDR list. NinjaOne, Kaseya VSA, ConnectWise, BeyondTrust, GoTo Resolve, Splashtop, Atera, Zoho Assist, Action1, Pulseway, DameWare, Radmin, and others added to RMM. IDrive, Synology C2, and Dropbox added to backup coverage.
REMOVED: Flat CSV O/P Files (all 8 named files)
All 8 discrete CSV files are gone, replaced by ExportData.db. Detection rules hunting for these specific file names on disk will miss v2 entirely. The browser history collection introduced in v1.5 is now also consolidated into the database rather than separate files.
REMOVED: Unprotected WinRAR Export.zip
The plaintext-accessible export.zip from v1/v1.5 is gone. An incident responder finding data.zip from v2+ cannot open it without deriving the actual password from the hard-coded GUID in inf_g.dll.
FEATURE DIFFERENCE v2 → v3
In this, we are going to see the minor changes in the sample that happened between May 2023 to November 2024 (1.5 Year Span).
REGRESSED: Bundled SQLite Engine Removed — Output returns to lean ZIP
The SQLite engine embedded in v2 to write ExportData.db was the largest single contributor to the 727 KB size. v3 drops it entirely. Reconnaissance output returns to a compressed archive (data.zip), stripping the queryable database in favour of a much smaller operational footprint. The password protection mechanism introduced in v2 is retained.
REGRESSED: inf_g.dll/data.dat Payload Delivery Externerlized
In v2, the XOR-encrypted inf_g.dll was carried inside data.dat alongside the EXE — a 2-file deployment. v3 externalises the heavy scanning logic further: the dropper is a lean loader/stub that pulls or receives the scanning payload as a separate stage, rather than decoding it from a bundled file. This makes the dropped EXE itself far smaller and removes the data.dat artifact that became a widely-distributed detection indicator.
REGRESSED: SentinelOne PE Metadata Spoofing Dropped/Simplified
The elaborate SentinelOne PE version-info block (“SentinelOne Compatibility Wizard” v1.1.6.0) from v2 is removed or significantly simplified in v3. The Gt_net.exe filename convention is retained as a lighter-weight naming disguise. Removing the version-info resources saves KBs and eliminates the most-published static signature from v2 public reporting.
REGRESSED: Costura Dependancy Bundling Reduced/Removed
v1 through v2 all use Costura to embed .NET assembly dependencies into a single EXE, adding tens of KB of bundled DLLs. v3 drops below the v1 baseline (118 KB vs 164 KB), which is only possible if Costura bundling is removed or drastically reduced. Dependencies are likely resolved at runtime via the target environment’s .NET Framework installation rather than being embedded.
REGRESSED: Expanded Scan List trimmed to Core Targets
The aggressive expansion to 30+ AV/EDR and RMM products in v2 is dialed back in v3. Products added in v2 that proved to be rarely encountered in target environments (or that added disproportionate string-table size) are removed. Core targets — CrowdStrike, SentinelOne, Microsoft Defender, Veeam, TeamViewer, AnyDesk — are retained as the highest-ROI detections for the operators.
RETAINED: Core WMI/WinRM/Remote Registry/Remote Services Enumeration
The foundational 4-API enumeration engine survives all versions intact. This is the core capability that makes Grixba operationally useful and cannot be removed without degrading the tool’s primary function. It is also the most reliable behavioral detection signal across the entire version history.
RETAINED: Clr Mode — EvtOpenLog/EvtClearLog log wiping
The Log-Clearing mode using the Windows Event Log APIs and WMI activity log wipe has been present in every version. It is also the most-detected post-execution behavior and remains in v3 — suggesting Play Ransomware has not found a compelling alternative and still relies on it for anti-forensics.
RETAINED: C:\Users\Public\Music\ drop path via RDP
Every version of Grixba is dropped via Remote Desktop Protocol to C:\Users\Public\Music\ on the target Windows server. This is the single most consistent hunting indicator across the entire 2-year history of the tool. Monitoring writes to this directory from RDP sessions is the highest-confidence Grixba detection signal that remains valid regardless of which version is deployed.
RETAINED: Password-Protected data.zip Exfiltration
The password-protected ZIP archive output introduced in v2 is retained in v3. The obfuscation scheme (displayed password ≠ actual password) persists. However, without ExportData.db, the archive now contains traditional file-based output rather than database records — a functional regression in output structure but no regression in obfuscation.
NOTE: The v3 analysis is based on the size delta and known architectural patterns. No public technical report has analyzed this specific hash in full detail ATTOW.
- Removed = A feature that existed was completely deleted
- Regressed = A feature still exists but was deliberately made simpler or weaker compared to the previous version
SCANNER TARGETS
Let us see, what Grixba hunts for?
Color indicates when each product was added: Grey = v1 baseline, Purple = added in v1.5, Green = added in v2, Red = Removed in v3.
26 MONTHS OF GRIXBA EVOLUTION
MITRE ATT&CK ANALYSIS
The following analysis is derived directly from sandbox execution of all four binaries. This is not inferred from public reports — it is what each sample actually does at runtime. Several findings here are not documented anywhere in existing public threat intelligence.
NOTE: Technique count trend: v1 = 12 techniques, v1.5 = 12, v2 = 10, v3 = 8. The binary gets progressively quieter — each version generates fewer detectable behaviors, which directly maps to the size regression and the move toward minimal footprint staging.
KEY FINDINGS
- Architecture flip: x86 → x64 → x86
v1 and v1.5 are 32-bit (x86) binaries — confirmed by the NativeImages_v4.0.30319_32 path in their DLL loads. v2 upgraded to 64-bit (x64), confirmed by NativeImages_v4.0.30319_64 and 64-bit memory addresses (0x7ffb…). v3 reverted back to 32-bit — only kernel32.dll is loaded, with 32-bit address space (0x03ce…). 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. The re-version to 32-bit in v3 may be deliberate evasion, not just a build oversight.
2. EDR unhooking is present in ALL four versions — but the method changed
Every version modifies ntdll.dll memory protection to PAGE_READWRITE to unhook EDR instrumentation. This is confirmed from MITRE Profiling. However in v1 and v1.5, this is paired with direct syscalls from unbacked memory — a more aggressive technique where the binary calls kernel functions directly, bypassing ntdll entirely. In v2 and v3, the direct unbacked syscall technique is absent. The developer traded raw aggression for cleaner execution in later versions.
3. AMSI and WLDP loaded in v1, v1.5, v2 — completely absent in v3
v1, v1.5 and v2 all load amsi.dll (Antimalware Scan Interface) and wldp.dll (Windows Lockdown Policy) from unbacked callers. Loading AMSI and WLDP is standard .NET CLR behaviour when executing managed code — but loading them from unbacked memory is anomalous and strongly indicates the binary is attempting to patch or bypass these interfaces before executing its payload. v3 loads neither. This is the single most significant behavioural change between v2 and v3 — the technique that generated medium-to-high severity alerts in the first 3 versions is simply gone, either because the bypass was internalised differently, or because v3’s stripped architecture no longer triggers the CLR-based AMSI integration path.
4. Identical self-read offset in v1 and v1.5 — codebase fingerprint
Versions 1 and 1.5 read from their binary images at the same offset: 0x3030785c3030785c. This consistent offset indicates they share the same Costura bootstrapper code, confirming identical packing. The offset disappears in v2 and v3, reflecting architectural changes in the packing/loading process.
5. v3 added new locale/language APIs — not present in any prior version
v3 resolves several APIs that do not appear in v1, v1.5 or v2: 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 logic — possibly to avoid executing in non-English-language environments, or to support new targeting criteria introduced alongside the DPRK partnership context.
6. v2 added timezone and shell APIs — unique intelligence collection
v2 uniquely resolves RtlGetSystemTimeAndBias, GetDynamicTimeZoneInformation, GetTimeZoneInformation, and loads tzres.dll — the Windows timezone resource library. It also loads shell32.dll, ole32.dll, SHGetFolderPath, and SHGetFolderPathW. None of these appear in v1, v1.5 or v3. This confirms v2 performs timezone-aware operations and shell folder enumeration — consistent with its expanded reconnaissance scope and the ExportData.db 18-table output structure.
MITRE ATT&CK @ A GLANCE
Universal detection rule grounded in all four samples: Any process that uses following steps is sequence:-
- modifies ntdll.dll to PAGE_READWRITE
- registers a VEH handler
- creates RWX memory
- checks HKLM\SYSTEM\ControlSet001\Control\Nls\CustomLocale\en-US
This exhibits Play’s Grixba Execution Pattern. This 4-behavior chain is confirmed present across every version from September 2022 to November 2024, making it the most durable detection rule in the entire Grixba analysis corpus.
MUTEX: CPFATE_2704_v4.0.30319
During the sample analysis, it is found that a mutex is being repeated in 2 samples (not yet analyzed in other 2). It was found in V1 and V2.
- 453257c3494addafb39cb6815862403e827947a1e7737eb8168cd10522465deb
- f8810179ab033a9b79cd7006c1a74fbcde6ed0451c92fbb8c7ce15b52499353a
Upon analyzing the Mutex name:
➤CPFATE : Likely a custom prefix chosen by the developer. Not a Windows system mutex, not a known legitimate application mutex. This is operator-defined.
➤2704 : Almost certainly the process ID (PID) component baked into the mutex name at runtime, or alternatively a hardcoded build/version identifier.
➤v4.0.30319 : This is the exact .NET Framework 4.0 runtime version string. This is Microsoft .NET Framework 4.0.30319 — the CLR (Common Language Runtime) version number that .NET applications running on .NET 4.x report
The mutex name encodes the .NET runtime version the binary was compiled against/running on. This is a developer fingerprint — likely constructed programmatically at runtime as:
"CPFATE_" + [hardcoded_id] + "_" + Environment.Version.ToString()
Which would produce CPFATE_2704_v4.0.30319 on any machine running .NET 4.x.
WHAT IT REVEALS?
➤Same Author: A custom mutex prefix like CPFATE is a developer choice. Finding it identical across a Sep 2022 and May 2023 build means the same person or team wrote both — not two separate tools that were relabeled.
➤Shared Code Lineage: v2 was not a rewrite. It is a direct evolution of the v1 codebase — the mutex creation code carried forward verbatim
➤OpSec Failure: The mutex name is a persistent cross-version signature. Any EDR or hunting query looking for mutex creation events containing CPFATE will catch both v1 and v2 regardless of filename, size, or PE metadata changes
➤.NET 4.x confirmed: v4.0.30319 locks the runtime dependency. Both samples require .NET Framework 4.x on the victim machine — confirms the decompilation approach (dnSpy/ILSpy targeting .NET 4.x IL)
CAPABILITY VERDICT
While analyzing all 4 samples, it is important to figure out which one is the best sample from an Attacker’s Point of View.
The strongest sample overall is v2 (727 KB, May 2023). The four versions make different trade-offs between raw capability, evasion, and operational agility. Here’s the full breakdown.
WEAKNESS ANALYSIS
Every version of Grixba has structural weaknesses that defenders can exploit. Some were fixed in subsequent builds. The v3 weaknesses that remain unfixed tell us what to watch for in a future v4.
V1: 5 Critical Weaknesses
FATAL: Plaintext, unprotected export.zip
The WinRAR-compressed export.zip requires no password. All 8 CSV files inside — alive.csv, soft.csv, users.csv, wm.csv, remote_svc.csv, cached_RDP.csv, mount.csv, all_soft.csv — are immediately readable by any incident responder who recovers the file from the host. This gives defenders the full picture of what the attacker was collecting, including what security gaps were mapped. Fixed in v2.
FATAL: No Disguise — Binary Easily Identifiable
v1 carries no vendor impersonation in its PE version-info block. Any basic triage of the binary (file properties, PE analysis) reveals it as a generic unknown executable with no plausible legitimate cover story. Static analysis shows all scan mode strings (Scan, Scanall, Clr) in plaintext. Fixed in v2 with the SentinelOne impersonation; partially retained in v3.
SIGNIFICANT: Costura Embedding exposes all strings & ASM Structure
Costura makes deployment easy but it makes reverse engineering equally easy. The embedded costura.commandline.dll and all other bundled assemblies are extractable with standard .NET decompilers, exposing scan lists, help text, file names, and all operational logic in readable IL (Intermediate Language). There is no obfuscation layer on the .NET code itself — it reads like commented source code once decompiled. Partially addressed in v2 with XOR encryption of inf_g.dll; not fully fixed in any version.
SIGNIFICANT: Help Screen Printed to Console on Execution
v1 prints a detailed help screen when executed without correct arguments, revealing all supported modes (Scan, Scanall, Clr), what each does, and what output files are produced. Partially obscured in v2 by the base64-encoded argument requirement.
SIGNIFICANT: No Anti-Sandbox or No-Debug Capability
v1 has no checks for debugger presence, sandbox artifacts (low uptime, few processes, virtual NIC vendors), or analyst environments. It executes identically whether it is run on a victim server or in a Cuckoo sandbox. This means sandbox submission immediately produces a full execution trace revealing all network behavior, file writes, and registry accesses. Not meaningfully addressed in any version to date — a persistent weakness across the entire Grixba lineage.
V1.5 : Inherits V1 Weaknesses, Adds 1 more
NEW: Browser History SMB Paths are Detectable Snort Signs
The browser history enumeration introduced in v1.5 accesses nine specific file paths over SMB, covering Chrome, Edge, Firefox, and IE history databases. CISA issued Snort rules that detect these exact SMB access patterns. This means any network with Snort or Suricata running those rules will flag v1.5 activity at the network level — before endpoint detection is even required. The file paths remained unchanged in v1.5 before the build was retired. Browser history collection seems to have been removed in v2 or integrated into the ExportData.db structure without the same detectable SMB access pattern.
INHERITED: V1 Weakness carry forwarded
V1.5 did not address any of the 5 weaknesses in v1. The unprotected export.zip, lack of PE metadata disguise, fully decompilable Costura structure, revealing help screen, and absence of anti-sandbox/anti-debug measures all remain in v1.5. The only significant update was adding new capabilities like browser history and host scanning, but the existing vulnerabilities were not fixed.
V2 : Most Capable, but new Forensic Liabilities
CRITICAL: Hard Coded GUID in inf_g.dll enables Defenders to decrypt data.zip
The obfuscated password scheme in v2 is defeated the moment inf_g.dll is analyzed. The hard-coded GUID (‘E8B10161–0849–4984-A6BF-3D1B267615CC-’) and a Python script showing exactly how to combine it with the console-printed password to derive the actual archive password. This means any defender who recovers a data.zip from a v2 incident— the same situation as v1’s unprotected export.zip, just one step later. A unique per-target key would have been far stronger. Not fixed in v3.
CRITICAL: data.dat+inf_g.dll 2-File Deployment is distinctive fingerprint
Requiring two files to be present simultaneously (GT_NET.exe + data.dat) in the same directory creates a highly distinctive pattern. Any file integrity monitoring or EDR that watches C:\Users\Public\Music\ for new file writes will see both files appear together, making the drop event trivially attributable even without process analysis. Fixed in v3 by externalizing the payload delivery.
SIGNIFICANT: ExportData.db is a Goldmine if recovered
ExportData.db has 18 tables with details like active hosts, browser history, installed software, processes, session info, network routes, and cached credentials. If defenders recover this file — even partially — they gain a full view of the attacker’s intelligence: live systems, security tools, cached RDP sessions. Ironically, this gives defenders an advantage: they now know what the attacker knows. This was removed in v3.
SIGNIFICANT: SentinelOne Impersonation fails SentinelOne itself
Impersonating SentinelOne — a product Grixba targets — has pros and cons. If SentinelOne is on the target, Grixba’s scan would detect it, and the real SentinelOne agent would recognize its binaries. However, GT_NET.exe with fake SentinelOne version info but no valid signature would fail verification and trigger tamper protection. So, this impersonation mainly tricks manual triage, not the actual SentinelOne product.
SIGNIFICANT: Single Static PIA VPN IP
Using a single static VPN exit node as the C2 endpoint means that once the IP is published (which it was in January 2025), every subsequent deployment that uses the same IP is instantly attributed. Network security teams can block this IP at the perimeter and will see any connection attempt as an immediate high-confidence Grixba indicator. Not addressed in v3 (or if a new IP is used, it hasn’t been publicly disclosed yet).
MODERATE: 727KB Size is anomolous for .NET Recon Tool
While most .NET applications are legitimately large, a 727 KB binary dropped to C:\Users\Public\Music\ with no installation context is anomalous. EDR products with ML-based size/entropy heuristics would score this binary high risk simply because of its size relative to the drop location. The 727 KB also means slower transfer over RDP, slightly increasing the detection window during the staging phase. Fixed in v3 by returning to sub-200 KB size.
V3 : Best Evasion, but Persistent Weakness Remain
UNFIXED: Drop Path Unchanged
Every version of Grixba — v1, v1.5, v2, v3 — has been dropped to C:\Users\Public\Music\ via RDP. This path has never changed despite being publicly documented. Any EDR or file-integrity monitor alerting on executable writes to this directory from an RDP session catches every version. The failure to change this is the most significant unforced operational security error in the tool’s entire history.
UNFIXED: WMI/WinRM Enumeration Generates High-Volume Telemetry Detection
Grixba’s primary function — scanning all reachable hosts for installed software using WMI and WinRM — produces a distinctive pattern of rapid lateral WMI connections. This involves one source host connecting to multiple targets via WMI within a short period, a pattern well-known as a lateral movement and reconnaissance indicator. Grixba has never altered its use of native WMI, as it provides its core capability, but this behavior is also the most challenging to conceal without adopting an entirely different enumeration approach.
UNFIXED: No Anti-Sandbox/Anti-Debug
None of the four Grixba versions include sandbox detection features such as checking for VM artifacts, low uptime, unusual process lists, or virtual NIC vendors, nor do they perform anti-debug checks. Running any version in a manual sandbox reveals a complete execution trace, including all network activity, file writes, and registry changes. This basic capability, common in even commodity malware, has never been implemented in Grixba.
UNFIXED: .NET Framework Lazy Decompilation
Building Grixba in .NET (managed IL) means every version decompiles to near-source code with freely available tools. v2’s XOR encryption of inf_g.dll added one layer — but once inf_g.dll is decoded, it too is managed IL and decompiles identically. No obfuscation layer (e.g. ConfuserEx, Obfuscar, Dotfuscator) has been applied to any version, meaning analysts can read the full scan logic, string constants, and operational flow as clearly as if they had the original C# source.
NEW IN V3: Reduced Capability
V3 removes the SQLite database engine and reduces the scan data, providing less detailed intelligence than v2. While v2’s ExportData.db covered active hosts, browser history, credentials, and more, v3’s leaner output may leave operators with an incomplete view of the target. This could result in gaps in recovery options during encryption in complex networks.
NEW IN V3: Staged Delivery depends on 2nd Payload reaching Host
In v3, the scanning logic (formerly inf_g.dll) is moved to a separate payload, creating a dependency: the scan only runs if the second stage succeeds. If network access is blocked or the payload is detected, the dropper is useless. Unlike v2, which was fully functional on its own, v3’s staged approach improves evasion but introduces a new failure point.
NEW IN V3: Gt_net.exe File Name
In v2, Gt_net.exe was paired with convincing SentinelOne PE metadata, making it appear legitimate. In v3, the metadata was removed but the filename remains, now lacking any legitimate identity. This makes the executable more suspicious, as the familiar name is used without the convincing cover story, arguably making it worse than v2.
WEAKNESS SCORECARD
Overall, let’s check a Weakness at a single glance:-
DPRK CONNECTION 🇰🇵
The October 2024 confirmation of North Korean state actor Jumpy Pisces (Andariel) operating alongside Play as an initial access broker adds a new dimension. The November 2024 v3 compilation — coinciding with the period of active DPRK collaboration — may reflect not just evasion of public detection but also the operational requirements of a new partner with different deployment constraints and target profiles. Leaner, stageable tooling is better suited to varied intrusion contexts than a 727 KB monolith.
TAKEAWAYS
The arc across these 4 builds is not random. Play Ransomware built a tool, watched it get detected, expanded it dramatically in response, then — after those expansions became the new detection baseline — stripped it back below the original baseline to escape again.
This is a feedback loop. The April 2023 Symantec disclosure was answered in three weeks with v2. The 18 months of progressive v2 analysis (Symantec, CISA, Trend Micro, Field Effect) was answered by November 2024 with v3 — a build that is smaller than v1 and carries none of the artifacts that made v2 detectable.
Defender Priority Matrix: Avoid anchoring detection to any single version’s artifacts. The only constant across all four versions is the C:\Users\Public\Music\ drop path from RDP combined with WMI/WinRM enumeration behavior. While size, filename, PE metadata, output format, and archive structure have changed, this behavioral pair has remained the same.
IOC TABLE
SHA-256=======453257c3494addafb39cb6815862403e827947a1e7737eb8168cd10522465deb: Infostealer.Grixba baselinec59f3c8d61d940b56436c14bc148c1fe98862921b8f7bad97fbc96b31d71193c: Play network scanner (CISA AA23-352A)f8810179ab033a9b79cd7006c1a74fbcde6ed0451c92fbb8c7ce15b52499353a: Peak-capability build3621468d188d4c3e2c6dfe3e9ddcfe3894701666bad918bc195aba0c44e46e94: Stripped/staged buildb4505ab44108e27d8a5311fe5ba32e2db88e70f0084b5c0b0b903e5b98f904b7: inf_g.dll — XOR-decoded CoreScanner module5922b1a7172bd60b1353f2a3c4de2a03efba8d57d0f696d00868d4ef6fcbc218: XOR-encrypted payload carrierf71476f9adec70acc47a911a0cd1d6fea1f85469aa16f5873dd3ffd5146ccd6b: Infostealer.Grixba cluster (Symantec)f81bd2ac937ed9e254e8b3b003cc35e010800cbbce4d760f5013ff911f01d4f9: All VSS Copying Tool (AlphaVSS-based companion)IP==84.239.41.12FILENAME========GT_NET.exeGT_NET.exe (lean)PATH====C:\Users\Public\Music\ARTEFACT========ExportData.dbdata.datexport.zipdata.zipSTRING======E8B10161-0849-4984-A6BF-3D1B267615CC-TOR===x6zdxw6vt3gtpv35yqloydttvfvwyrju3opkmp4xejmlfxto7ahgnpyd.onionb3pzp6qwelgeygmzn6awkduym6s4gxh6htwxuxeydrziwzlx63zergyd.onionp2qzf3rfvg4f74v2ambcnr6vniueucitbw6lyupkagsqejtuyak6qrid.onionwhfsjr35whjtrmmqqeqfxscfq564htdm427mjekic63737xscuayvkad.onionmbrlkbtq5jonaqkurjwmxftytyn2ethqvbxfu4rgjbkkknndqwae6byd.onionk7kg3jqxang3wh7hnmaiokchk7qoebupfgoik6rha6mjpzwupwtj25yd.onionj75o7xvvsm4lpsjhkjvb4wl2q6ajegvabe6oswthuaubbykk4xkzgpid.onion
Follow me on Twitter for interesting DarkWeb/InfoSec Short findings and Stay Tuned with THE RAVEN FILE!
Leave a Reply