The trail in this campaign began with a file named modeling_evil.py. A Pluto Security investigation traced it from a random-string test account to a campaign spanning 28 repositories, six Hugging Face accounts and a ModelScope mirror, with more than 21,000 downloads across the campaign and its linked models.
How it was found
Pluto Security built a scanner for the files that trust_remote_code actually downloads and runs: every .py file referenced by auto_map in a config.json, plus any Python file sitting beside model weights. A model definition should describe layers and a forward pass. If it imports subprocess, opens a socket or calls memfd_create, someone put that there on purpose. The scanner looks for patterns including subprocess, os.system, socket, ctypes, memfd_create, base64.b64decode, exec, eval and urllib.
Run across recently uploaded public repositories, one hit stood out: dsxk4mr8tq/qwen2-tiny-gpt2. It had a random-string account name and a 305-line file called modeling_evil.py that matched subprocess, socket, ctypes and memfd_create. The account had six repositories, all created within 2.5 hours on October 12, with the same code under six model names.
The slip that linked the accounts
The real break came from the qwen2-tiny-lite repository, which held two backup files the operator had left behind: modeling_evil.py.bak-src and modeling_evil.py.bak-sync. They were older versions of the same malware with different download URLs. Those URLs did not point at dsxk4mr8tq. They pointed at hhzz667 on Hugging Face and wssb123e on ModelScope. The operator had copied production code into a new test account, updated the URLs in the main file and forgot the backups, so its own version history connected the accounts. From there Pluto Security exposed the first wave: 12 repositories, three accounts, two platforms, more than 700 recorded downloads and zero security flags.
The binary, taken apart
The 40.6 MB second-wave binary, syscore.bin, is packed with UPX, but two UPX! markers in the packing metadata were changed to PEK!. A routine upx -d rejects the file as not packed by UPX, while the embedded loader still unpacks and runs the miner, because the changed markers do not break its execution path. Pluto Security reverse-engineered the payload, restored both markers and unpacked it to reveal peakminer, the same mining client reported by the live workers on the first-wave wallet. The modification blocks routine unpacking without changing or encrypting the mining code.
What the “evil” name does and does not tell you
In wave one, the evil naming turned up on the development account. The production build, qwen2-final, used clean names, Qwen2Config and modeling_qwen2.py, and the EvilConfig naming only existed in the dev account. The wave-two flagship drops that disguise: MENXIANGYU/qwen2-tiny points auto_map at modeling_evil2.EvilModel and carries its payload in modeling_evil2.py. It had been downloaded 18,012 times by October 25, and the file returned safe from every scanner that ran. Among the tradecraft Pluto Security lists are development files named evil, alongside throwaway accounts, commodity tooling and a leaked token.
The money behind the file
The campaign is paying. The first-wave wallet has received about 2,276 PRL, roughly $5,000, across 716 transactions and sent about 2,241 PRL onward, and it was still earning after the repositories behind it were removed. Pluto Security’s assessment is that the goal is profit, from a financially motivated, Chinese-speaking operator or small group. The first wave progressed from a 37-line SSH backdoor to a 305-line fileless miner in three weeks, and the second wave replaced the hardcoded SSH key with reverse shells.
Why the finding matters
Pluto Security’s point is that a familiar model name does not mean safe code, and a clean scan alone is not a reason to trust a repository. Reviewing the .py files an auto_map points to, before the flag is set, would have caught every payload in this campaign, and a static check at upload time for subprocess, socket, ctypes or raw-IP network calls in those files would have caught them earlier still.
John Kevin Hao is a news and feature writer covering cybersecurity, technology, and business targeted for professional audiences.