Tracking GLOBAL GROUP Ransomware from Mamona to Market Scale
In June 2025, a ransomware actor known by the alias $$$ publicly introduced a new brand, GLOBAL GROUP, on the Ramp4u cybercrime forum. Pitched as a fresh Ransomware-as-a-Service (RaaS) venture, the group claimed to offer a scalable platform with automated negotiations, cross-platform payloads, and generous affiliate profit-sharing.
However, forensic evidence across malware samples, infrastructure configuration, and control logic reveals that GLOBAL is not new, it is a rebranded continuation of the Mamona RIP and Black Lock ransomware families.
This blog dissects GLOBAL GROUP’s ransomware payloads and infrastructure by analyzing leaked API metadata, reverse-engineered binary code, and threat actor behavior. At every layer, payload, delivery, control, and operation, GLOBAL reveals continuity and maturity more than innovation.
Payload Architecture: Golang Execution, Mutex Reuse, and Cross-Platform Delivery
GLOBAL GROUP’s ransomware is built in Golang, compiled into monolithic binaries that support execution across Windows, Linux, and macOS environments. This choice aligns with current trends in ransomware development, where Go’s concurrency model and static linking are leveraged to accelerate encryption at scale.
In one of the first discovered samples, the binary includes the following mutex string:
Global\Fxo16jmdgujs437 |
This mutex is not random, it is identical to the one found in Mamona RIP ransomware, a now-defunct RaaS also operated by $$$. The reuse of this mutex indicates codebase inheritance rather than modular repackaging. This string is used to prevent multiple simultaneous executions of the ransomware process, enforcing single-instance behavior system-wide.
The ransomware uses the ChaCha20-Poly1305 encryption algorithm for its payload, a modern choice that provides both confidentiality and message integrity.
Encryption is handled concurrently across all available drives, exploiting Go's goroutines to maximize performance and limit execution time. Each encrypted file receives a custom extension defined by the affiliate (e.g., .lockbitloch), and in most samples, filenames are also encrypted to hinder restoration efforts.
Ransom Note Assembly: Embedded Strings and Write Logic
The ransom note is hardcoded directly into the binary and written using an I/O function that interacts with the victim's file system. Decompilation reveals the following logic used to construct the message:
v16 = ((__int64 (__fastcall *)(_160_uint8 *, const char *))loc_471AB4)( |
This buffer is then passed to the following function:
os_WriteFile(v25, 2, v16, 160, 160, 420, v17, v18, v19, v21, v22, v23, v24); |
The string hardcodes the Tor leak site where victims can verify compromise and begin ransom negotiations. The use of embedded constants and C-style function dispatch reflects either a Go-to-C interop layer or custom packing logic, indicating moderate sophistication in binary design.
Full Ransom Note Text
Beyond the embedded string used for ransom note construction, analysis of deployed payloads reveals the complete ransom message written to disk as README.txt. This message contains branding, extortion instructions, and proof-of-decryption guidance, consistent with modern double-extortion tactics.
GLOBAL
|
The tone of the note is direct and coercive, combining traditional scare tactics with a verification mechanism that instills trust in the decryption service.
Notably, it introduces a dual-portal model:
- one for leak site viewing, and
- another for real-time chatbot negotiations.
This structure reflects a mature, compartmentalized backend designed for affiliate operations at scale.
Frontend API Exposure: Backend SSH Credentials and Real IP Leakage
While the ransomware encrypts locally, the operator’s infrastructure mistakes provide valuable attribution opportunities. The Tor-based Dedicated Leak Site (DLS) hosts a JavaScript frontend that fetches victim data from an unprotected REST API at the endpoint /posts. This endpoint returns structured JSON describing each entry in the victim list.
Among the returned fields is:
"sshConnectionName": "dataleak@193.19.119.4:22" |
This single field, intended only for internal use, exposes the real-world IP of the backend infrastructure - 193.19.119[.]4, a server hosted by Russian VPS provider IpServer. The username dataleak confirms its function as the central node for storing and managing leaked files. This is the same provider previously associated with Mamona, and the server is reachable over port 22 for SSH access.
This exposure is an unforced operational security (OPSEC) error. The use of frontend JavaScript to fetch victim data, rather than rendering it server-side, resulted in the leakage of sensitive internal details that tie GLOBAL back to known infrastructure and hosting patterns.
The Builder: A RaaS Platform for Custom Payload Generation
GLOBAL GROUP supports a full-featured affiliate portal, with a ransomware builder interface accessible via both desktop and mobile devices. Screenshots from the portal reveal a dark-themed UI with toggles, sliders, and dropdowns for configuring payload parameters.
Configuration options include:
- Encryption percentage (e.g., 20%)
- Custom file extension (e.g., .lockbitloch)
- Optional flags:
- Self-delete after execution
- Kill security processes
- Delete Windows Event Logs
- Encrypt file names
- Mount and enumerate drives
- Change file icons
Each of these flags maps to internal logic within the payload.
Internally, these flags correspond to modular execution blocks, suggesting that the builder dynamically includes or excludes specific functions at compile-time rather than embedding all logic statically. This approach reduces binary size and may help evade signature-based detection.
For instance, the KillProcesses option enables a subroutine that enumerates running services, matches them against known AV/EDR process names, and terminates them via Windows APIs such as OpenProcess and TerminateProcess.
Similarly, DeleteLogs likely invokes wevtutil commands or directly modifies system files in C:\Windows\System32\winevt\Logs.
The builder supports payload compilation for multiple operating systems, including Windows, Linux, ESXi, BSD, and NAS appliances, giving affiliates flexibility in targeting hybrid and virtualized infrastructures. The output is typically a single binary packed into a ZIP archive for distribution.
Negotiation Panel: AI Chatbot Interface and Psychological Manipulation
The ransom note instructs victims to access a separate Tor-based negotiation portal:
gdbkvfe6g3whrzkdlbytksygk45zwgmnzh5i2xmqyo3mrpipysjagqyd.onion |
Once accessed, the victim is greeted by an AI-powered chatbot designed to automate communication and apply psychological pressure. The panel is built for non-technical users, with prompts to upload a sample encrypted file for free decryption verification. All correspondence occurs over a secure channel with a timer displayed to reinforce urgency.
Chat transcripts reviewed by analysts show demands reaching seven-figure sums, such as 9.5 BTC ($1 million at the time), with escalating threats of data publication. Affiliates are able to monitor negotiations, set ransom windows, and interact with victims directly via a mobile-friendly UI.
The integration of AI chat automation reduces the affiliate workload and ensures negotiations proceed even in the absence of human operators, enabling GLOBAL to scale victim engagement across time zones, languages, and organizational profiles.
Initial Access, Brokers, and Credential Harvesting
GLOBAL relies heavily on Initial Access Brokers (IABs) for rapid network infiltration. In one case, an IAB named HuanEbashes advertised Remote Desktop Protocol (RDP) access to a U.S. law firm, with confirmation of domain membership and access to financial data. The operator $$$ engaged directly on the thread, offering to purchase access or initiate a profit-sharing agreement based on successful encryption and extortion.
This collaboration model reflects a service-oriented ecosystem in which ransomware deployment is outsourced, commodified, and scaled. The same broker also promoted a custom-built brute-force tool designed to target Fortinet, Palo Alto GlobalProtect, Cisco VPN, and Microsoft services like Outlook Web Access (OWA) and RDWeb. GLOBAL’s operator publicly “liked” the post, suggesting direct interest or downstream usage of these tools to expand their attack surface.
Summary of Technical Attribution
Collectively, these indicators demonstrate that GLOBAL is not a standalone threat group but a continuation of existing tradecraft under a refreshed brand.
Evidence |
Reuse Indicator |
Mutex Global\Fxo16jmdgujs437 |
Reused from Mamona RIP |
VPS IP 193.19.119.4 |
Same provider as Mamona (IpServer) |
Builder logic and UI design |
Identical panel behaviors |
Hardcoded DLS Tor address |
Same in payload and ransom note |
qTOX display name “Global Black Lock” |
Rebranded from Black Lock |
The reuse of hosting providers, malware artifacts, mutex values, and even actor communication channels points to a well-established actor repackaging proven infrastructure for renewed affiliate appeal.
Defensive Considerations
Security teams should validate their ability to detect and respond to the specific techniques employed by GLOBAL GROUP. Key focus areas include:
- Detection of multithreaded ChaCha20-Poly1305 encryption routines commonly used in Golang-based ransomware.
- Identification of custom file extension patterns and filename encryption during post-compromise file access.
- Monitoring abuse of native utilities such as wevtutil, vssadmin, and net use for log clearing and system manipulation.
- Detection of unauthorized SSH access targeting public cloud infrastructure.
- Anomaly detection around session hijacking and credential replay via OWA and RDWeb.
Beyond static signatures and heuristics, detection engineering should incorporate:
- Behavioral analysis of rare mutex instantiation (e.g., Global\Fxo16jmdgujs437).
- Correlation of lateral movement paths initiated from non-domain-joined endpoints.
- Service-level telemetry for spotting atypical process chains or credential reuse across protocols.
Where possible, organizations should simulate these techniques using Adversarial Exposure Validation approaches such as Breach and Attack Simulation (BAS) to continuously assess the real-world effectiveness of their security controls. This allows teams to:
- Validate whether prevention and detection tools block actual attack behavior, not just theoretical signatures.
- Uncover blind spots due to misconfigured rule sets or telemetry gaps.
- Apply actionable, vendor-specific mitigation guidance to close validated gaps.
By focusing on validated control performance, not assumed coverage, security teams can shift from passive detection to operational assurance.