Hackers Use SANSAR Linux Malware to Hide Crypto Mining by Faking 0% GPU Usage

Hackers are hiding cryptocurrency mining on Linux GPU servers by changing the readings administrators use to spot heavy workloads.

The toolkit combines a Rust-based controller called SANSAR, a kernel rootkit, and a modified NVIDIA monitoring library that reports 0% GPU utilization while mining continues in the background.

The intrusion reached three Linux GPU hosts through an exposed Ray job agent. Ray supports distributed computing, including AI training and inference, making these systems valuable targets.

Unlike campaigns involving fake utility download traps, this attack entered through infrastructure that accepted remote computing jobs without authentication.

Researchers from Elastic Security Labs identified the activity as REF3364 in a November 12, 2026, technical analysis of SANSAR.

Their findings describe coordinated tools for mining, hiding processes, maintaining access, and opening remote shells—not simply a miner running unnoticed.

Hackers Use SANSAR Linux Malware

The deception targets NVIDIA Management Library, or NVML, the interface used by monitoring tools such as nvidia-smi. The attacker’s wrapper forwards requests to the genuine NVIDIA library, then changes selected results before returning them.

GPU utilization becomes zero, while temperature and power readings are replaced with random values between 36–46 degrees Celsius and 100–200 watts.

This makes apparently normal monitoring output unreliable. The GPU is not necessarily idle; the software reporting its activity has been altered.

SANSAR can also rebuild and reinstall the wrapper from recovered source files, giving the operator a way to maintain the modified monitoring layer.

A separate kernel rootkit hides selected processes, files, and socket entries. It intercepts directory listings and other system operations, removing matching records or returning errors when tools inspect hidden processes.

Similar Linux rootkit mining attacks have used kernel-level concealment, but this toolkit adds falsified GPU measurements to obscure resource use.

SANSAR itself supervises publicly available mining software rather than performing every mining task internally. Its CPU branch uses XMRig, while its GPU branch launches SRBMiner-MULTI.

The controller supplies pool addresses, wallet or login details, algorithms, and other settings. Elastic found no hardcoded fallback pool or wallet in those launch paths.

Exposed Ray Jobs Enable Persistent Remote Access

Recorded activity began with external probes on October 22, followed by a GPU inventory query on October 24. On October 25, the attacker submitted a Python reverse-shell job.

Although the Ray head-node dashboard listened only on localhost, the job agent remained internet-accessible and accepted unauthenticated submissions. The initial shell ran under the account owning the Ray session. The attacker then added an SSH key for continued access.

After obtaining root, the operator installed the toolkit, built its kernel module through Dynamic Kernel Module Support, and added an early-boot loader. Elastic’s account does not explain the precise method used to obtain root.

Control extends beyond mining. SANSAR communicates over Tor and supports interactive Bash shells, miner configuration changes, output forwarding, and TCP SYN traffic generation.

Its shell setup suppresses saved command history. These capabilities make the compromise broader than stolen computing capacity alone.

A separate backdoor retrieves its controller address from an Ethereum smart contract, then connects directly over TCP. This creates another route for shell access.

Earlier Discord controlled mining campaigns also combined mining with remote control, although their communication methods differed from this intrusion.

For defenders, Elastic highlights two priorities: check who can submit Ray jobs and verify whether GPU monitoring libraries have changed.

A zero reading from an altered library cannot establish that a server is clean. Investigations should also account for persistent access and kernel-level hiding rather than treating the visible miner as the entire infection.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally Qdefanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Give your SOC the alert context on the latest threats to stop incidents quickly -> Integrate Threat Intel from 16K SOCs