A new malware toolkit named SANSAR is being used to conceal illicit cryptocurrency mining on Linux GPU servers by manipulating GPU usage metrics. The adversary combines several clandestine components—a modified NVIDIA monitoring library, a kernel rootkit, and a Rust-based controller—to evade detection. Administrators who rely on standard tools to spot heavy GPU utilization could be misled into thinking systems are idle when in fact mining is underway.
How SANSAR Deceives Monitoring Tools
SANSAR works by hijacking NVIDIA Management Library (NVML), the API monitored by utilities like nvidia-smi. The malware wraps the legitimate NVML library, intercepts requests from monitoring tools, forwards those to the real library, then tampers with select outputs. GPU usage is masked as 0%, while temperature and power values are replaced with random numbers within a plausible but misleading range—36–46 °C for temperature and 100–200 watts for power draw—that support the illusion of inactivity. The wrapper can also be rebuilt and reinstalled from its source code to persistently reinstate the falsified monitoring layer.
On top of that, a kernel rootkit component suppresses visibility of certain processes, socket entries, files, and directory listings. It intercepts system calls that inspection tools use to enumerate active processes or access sensitive data, returning empty or error responses to hide mining activity. Thus, even digging into system internals without relying on GPU usage may miss the intrusion.
Compromise, Capabilities, & Communication
The incident was traced back to Linux GPU servers running Ray, the distributed computing framework often used for AI training or inference. Attackers exploited an exposed Ray job agent that didn’t require authentication. Initial probing began around October 22, followed by inventory queries on GPU hardware a few days later. On October 25, a reverse-shell job was submitted, enabling remote access under the account running the Ray job. From there, an SSH key was added, root access was obtained, and the full SANSAR toolkit was deployed—including components built with Dynamic Kernel Module Support and an early-boot loader to survive reboots.
SANSAR supports GPU mining via SRBMiner-MULTI and CPU mining via XMRig, but importantly it doesn’t implement all mining tasks itself—it orchestrates existing miners. The controller adjusts algorithms, config settings, pool addresses, and wallet information. Control communications happen through Tor, and the malware supports interactive remote shells, traffic generation like TCP SYN floods, and even hides its command history. A distinct backdoor retrieves controller metadata from an Ethereum smart contract, then connects directly over TCP—creating an alternate access vector.
Indicators & Defense Recommendations
Security researchers identified several indicators of compromise (IoCs): SHA-256 hashes for components such as the SANSAR orchestrator, modified NVML wrapper, kernel rootkit module (acpi_thermal_mgr.ko), XMRig and SRBMiner-MULTI miners (tagged as “kurt” and “tilki”), a Lyrebird transport helper, and a backdoor module. Also notable are an Onion (Tor) endpoint for controller operations and an Ethereum smart contract address used as a controller lookup. TCP port 8080 is involved as well.
Defenders are urged to audit which systems accept Ray job submissions and verify the integrity of GPU monitoring libraries rather than trusting zero utilization readings alone. Investigations should include kernel-level rootkits, unauthorized persistent access, and non-standard program modifications—not just active mining processes.
Importance for cloud providers, AI infrastructure maintainers, and GPU server operators is clear: malicious actors using tools like SANSAR can remain hidden in plain sight for extended periods. Expect growing threats of similar techniques. Vigilance with monitoring tools, stricter exposure controls for job agents (like Ray), and integrity checks of system-level components will be essential moving forward.
