XMRig Covert Ops: The Cryptomining Campaign That Abuses Trusted Access and Deploys Forensic Smokescreens

Introduction

In May 2026, a highly covert Monero (XMR) cryptomining campaign was identified, leveraging advanced stealth techniques to infiltrate and persist within targeted Linux environments. The initial compromise occurred through a trusted third-party relationship, allowing threat actors to traverse from a trusted environment into the primary network undetected. This blog post details the campaign’s tactics, from weaponizing Linux Pluggable Authentication Modules (PAM) to create a forensic smokescreen, to the deployment of a highly customized, self-unlinking XMRig botnet implant and employment of MITRE technique T1564.013.

Key Discoveries

• Initial access was achieved by exploiting a trusted third-party relationship, highlighting critical supply chain risks.
• The threat actor escalated to root access, but weaponised the pam_rootok policy to seamlessly impersonate multiple low-privileged users to create a forensic smokescreen designed to confuse incident responders and establish a “hydra-like” redundant persistence across unmonitored accounts.
• The campaign operators actively suppressed system visibility by disabling logging services and removing authentication logs to blind standard file-based monitoring.
• Execution of a self-unlinking binary that deletes itself from the filesystem to run purely in memory, utilizing a /tmp/.lock mutex to ensure single execution.
• Campaign tracking parameters were uncovered within the binary’s obfuscated data (using XOR keys I3F0 and CLIENT), identifying the operation as part of the V25 (Generation 26) campaign family.
• Employment of MITRE technique T1564.013 (Hide Artifacts).

Who may find this blog interesting:

• Cybersecurity analysts
• Malware and Threat intelligence professionals
• Incident Responders
• Security Operation teams

Group-IB Threat Intelligence Portal:

Group-IB customers can access our Threat Intelligence portal for reference about XMRig as described in this blog.

Technical Walkthrough

Initial foothold & PAM weaponization

The campaign began when the threat actor leveraged a trusted network relationship to silently infiltrate the target system using a standard user account. Upon gaining initial access, the actor successfully escalated privileges to root. However, this is where the campaign’s true sophistication emerged.

Rather than operating openly as root – which typically triggers high-severity alerts in any organization’s Security Operations Center (SOC), the attacker weaponized the Linux Pluggable Authentication Modules (PAM) architecture. By abusing the pam_rootok policy, the attacker utilized the `su` command to seamlessly assume the identities of multiple low-privileged users across the system without requiring their passwords. This calculated lateral movement turned out to be extremely effective as it created a forensic smokescreen. By distributing their malicious activities and planting redundant cronjob persistence across various unmonitored standard accounts, the attackers ensured that if SOC analysts only remediated the root compromise, the botnet implant would simply regenerate from the shadowed accounts.

To further conceal their tracks and hide their interactive sessions, the operators behind this campaign actively suppressed system logging. By stopping core logging services and tampering with authentication logs, the threat actor ensured that their initial privilege escalation and PAM manipulation left a minimal forensic footprint on the disk, effectively blinding traditional file-based monitoring.

Execution guardrails, self-unlinking & hardware optimization

The core implant is a heavily modified version of the open-source XMRig 6.25.0 miner, cross-compiled with musl libc. It contains a hardcoded ASCII-art banner that explicitly states, “PRIVATE VERSION FOR BOTNET”.

Figure 1. One of the indicators of this customized XMRig malware.

To ensure operational stability and avoid alerting administrators through excessive resource contention, the malware employs an execution guardrail. Upon startup, it creates a file-based mutex located at /tmp/.lock. This synchronization mechanism guarantees that only a single instance of the botnet implant runs at any given time, preventing self-competition that could otherwise crash the host system.

Immediately after establishing this mutex, the malware performs a self-unlink operation. By deleting its own binary file from the disk while the process remains active, the malware transitions into a fileless state, running entirely from memory (RAM). This severely complicates post-incident forensics, as traditional antivirus scans looking for static files on the disk will return clean results.

Once securely residing in memory, the malware evaluates the host’s CPU topology. To ruthlessly optimize hardware resources and maximize cryptomining profitability, it dynamically spawns additional instances (worker threads) tailored to the compromised system. It actively interacts with kernel MSR (Model-Specific Registers) and allocates Huge Pages to squeeze every ounce of processing power from the victim’s hardware, while utilizing a companion bash script to kill off competing processes.

Custom command-line interface

Unlike legitimate XMRig deployments, this botnet variant replaces the standard argument parser with a highly simplified interface designed for rapid, scripted deployment across compromised hosts. Key custom flags include:

Supported mining algorithms

The threat actors ensured the botnet remains highly adaptable by embedding support for multiple hashing algorithms. This allows the botmaster to pivot the mining operations dynamically based on the target’s hardware architecture or the most profitable cryptocurrency of the day.

Obfuscated string fragments & campaign tracking

Deep binary analysis of the implant revealed how the campaign is structurally managed. The malware utilizes layered XOR encryption keys to hide its internal configurations and command-line arguments. Specifically, Group-IB researchers observed the XOR key chain “I3F0”-> “xmrig”, which subsequently decodes the command-line flag strings. A secondary XOR key, “CLIENT”, is utilized to decrypt pool identity and miner defaults.

Upon decrypting these string constants, Group-IB investigators extracted the default configuration parameters used to connect to the mining pool infrastructure. Crucially, the decrypted User flag was hardcoded as My-V25-GEN-26, and the Password flag was set to V25-GEN-26. This specific telemetry convention directly links the operation to the V25 (Generation 26) campaign family, allowing the threat actor to organize, track, and aggregate hash rates from thousands of compromised endpoints.

To maintain operational security, the threat actor utilized advanced defense evasion techniques, specifically leveraging MITRE technique T1564.013 for hidden artifacts. The malware natively supports process masquerading via the custom -h flag, allowing it to spoof legitimate process names such as “ssh” in ps, top, and /proc/<pid>/comm outputs. Furthermore, network traffic was heavily obfuscated. By conducting memory forensics on the JSON-RPC packets in RAM, analysts discovered that the malware disguised its User-Agent as “Java/Agent”, effectively blending its malicious Stratum traffic into typical web application traffic flows.

Conclusion

This newly observed XMRig campaign underscores the evolving sophistication of cryptomining botnets. By combining trusted third-party access, intricate lateral movement through PAM manipulation, active log suppression, and advanced evasion techniques like self-unlinking, T1564.013, and process masquerading, the threat actors demonstrated a high degree of operational security. Defenders must move beyond static file scanning and DNS blocking, adopting robust memory forensics, strict logging controls, and behavioural analysis to unmask and root out these deep-seated threats.

Recommendations

To defend against such covert miner campaigns, organizations should adopt the following measures:

• Deploy an advanced Endpoint Detection and Response solution like Group-IB MXDR to block malicious downloads and neutralize attacks before they escalate.
• Audit and Restrict Trusted Access: Implement Zero Trust architectures and strictly monitor cross-environment connections from vendors or clients to prevent supply chain exploitation.
• Protect Logging Infrastructure: Monitor for unauthorized stops or modifications to logging services (e.g., rsyslog, auditd) and ensure logs are forwarded in real-time to an external, tamper-proof SIEM.
• Monitor PAM and Audit Logs for Smokescreens: Scrutinize /var/log/secure and audit.log for unusual user-switching behavior. Alerts should be triggered immediately if root is observed rapidly transitioning into standard user accounts (USER_START events associated with pam_rootok).
• Enhance Memory Forensics & File Artifacts: Hunt for transient artifacts such as the /tmp/.lock mutex file. Because the malware unlinks itself and utilizes T1564.013 to hide processes, memory carving is essential to extract runtime configurations, JSON-RPC Stratum packets, and real process arguments.
• Deploy IOC Blocks: Immediately block the identified malicious domain (unable.download) and associated IP addresses at the perimeter firewall and DNS resolvers.

Indicators of Compromise (IOC)

Network IOCs

File Hashes

File Indicators

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as XMRig and others, solely to illustrate cases where threat actors have abused or misused these platforms.

This material is provided for informational purposes, prepared by Group-IB as part of its own analytical investigation, and reflects recently identified threat activity.

All trademarks referenced herein are the property of their respective owners and are used solely for informational purposes, without any implication of affiliation or sponsorship.