At a glance
| Field | Detail |
|---|---|
| Malware family | Modified XMRig 6.25.0 botnet implant (marked “PRIVATE VERSION FOR BOTNET”), cross-compiled with musl libc |
| Threat actor | Unidentified; campaign tracked internally as V25 (Generation 26) |
| Targets | Linux environments; initial victim reached through a trusted third-party network connection |
| Delivery vector | Trusted third-party relationship exploited to gain initial network access |
| Key capabilities | PAM weaponization, self-unlinking fileless execution, process masquerading, log suppression, Monero mining |
| Source | Group-IB (Nam Le Phuong and Yeo Zi Wei) |
TL;DR
A covert Monero mining campaign active in May 2026 combined trusted-network access, Linux PAM abuse, and fileless execution in one attack. The implant deletes itself from disk the moment it starts, leaving only a memory-resident process. Group-IB identified the operation as part of the V25 (Generation 26) botnet family, though the operator remains unattributed.
Delivery
In May 2026, the attackers entered a target network by abusing a trusted third-party relationship. They used a standard user account to move from a partner environment into the primary network without raising alarms. According to Group-IB, “initial access was achieved by exploiting a trusted third-party relationship, highlighting critical supply chain risks.”
Infection chain
PAM weaponization – the forensic smokescreen
After gaining root privileges, the operator chose not to act as root directly. That would have triggered high-severity SOC alerts. Instead, the attacker turned the Linux Pluggable Authentication Modules (PAM) framework into a cover mechanism. By abusing the pam_rootok policy with the su command, the actor switched into multiple standard user accounts without needing their passwords. This XMRig Linux PAM abuse scattered malicious cronjobs across unmonitored accounts, creating what Group-IB calls “a forensic smokescreen.” Cleaning up the root compromise alone would leave the botnet intact, regenerating from those shadowed accounts.
The operators also killed core logging services and deleted authentication logs. This blind standard file-based monitoring and removed traces of the privilege escalation and account-switching activity from disk.
Fileless execution and hardware optimization
The core implant starts by creating a mutex file at a predictable temp path. This ensures only one instance runs, preventing resource contention that would crash the host. Immediately after, it deletes its own binary while remaining active. The process transitions entirely into memory. Disk-based antivirus scans return clean results.
The in-memory process then reads the host’s CPU topology. It spawns worker threads tuned to the hardware, interacts with kernel model-specific registers, and allocates Huge Pages to push hash rates as high as possible. A companion script kills competing miners.
C2 traffic and campaign tracking
Group-IB analysts found layered XOR obfuscation protecting the binary’s internal configuration. Decrypting the key chain revealed hardcoded credentials that tied the sample to the V25 (Generation 26) campaign family. These credentials let the botmaster aggregate hash-rate telemetry from thousands of compromised endpoints under a single campaign tracker.
The malware disguised its mining pool traffic as Java agent traffic, blending Stratum protocol packets into typical web application flows. The process masquerading flag lets operators spoof legitimate process names such as ssh in standard monitoring tools.
Defense and detection
Standard disk scanning will not catch this threat. Instead, defenders need memory forensics to extract runtime configurations and Stratum packets from RAM. The full Group-IB technical report provides file hashes, the malicious pool domain, and the temp mutex path as indicators.
Key defensive steps include monitoring PAM and audit logs for unexpected root-to-user switching, watching for stops to logging services like rsyslog and auditd, blocking the identified malicious mining domain at the DNS layer, and auditing every trusted third-party connection with zero-trust controls. Restrict which vendor or partner accounts can traverse network boundaries and confirm each connection before granting access.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.