In this edition of Malware Monthly, we take you on a journey through malware that rejects virtual machines, Linux crypto miners, evasive variants of RAT mutants, and a ubiquitous package that’s dependent on the entire publicly available npm ecosystem — all targeted at modern software supply chains. Follow us as we continue uncovering suspicious activities in open source registries.
In terms of the volume of malware caught by our AI-enabled system, 2023 did not start quietly.
In January, we caught 691 malicious packages in the npm registry. A noticeable amount of packages contained mentions of Yandex — the Russian search engine company. Packages including yandex-logger-sentry, yandex-logger-qloud, and yandex-sendsms attempt to exfiltrate information to a rogue server, possibly a bug bounty campaign against Yandex that employs dependency confusion attacks.
We also caught 49 malicious packages in the PyPI registry last month. Notably, the packages reqsystem and httpxfaster published by the same author (sexydev1337), contained heavily obfuscated code with hyperion — an obfuscator we see gaining popularity. Other examples here with heavily obfuscated code include aio6, gorilla2, httpsos, and pohttp packages. Additionally, the packages have and view execute a script that downloads and runs a malicious binary from an external server. In the case of have, some of the versions contain obfuscated code, and one replaces Discord’s executable.
npm packages won’t be left behind
If you’ve uploaded your contributions to the npm registry, you might’ve noticed a dependent package that was common to all the other packages: no-one-left-behind by author Zalastax.
The package was published in 2018 and depended on every other known publicly available npm package. Talk about a next-level dependency hell situation. Here’s how the dependency graph looks like:
Possibly inspired by hoarders, a self-described "utility grab-bag" package that was published in 2012 (at the time hoarders depended on 20,000 packages) and taken down for about 9 years before the author managed to find a workaround, no-one-left-behind was removed last week by the npm security team and is now a placeholder.
Nevertheless, on Jan 28th, our team found that more than 33k+ packages were published under the scope of “infinitebrahmanuniverse”, all with the “nolb-” prefix, and self-described as sub-packages of no-one-left-behind. The author “infinitebrahamanuniverse” has only published single versions, and it doesn’t have a GitHub account or any other personal information.
If you check any npm package right now you’ll probably find under the dependents tab one of the nolb packages uploaded by “infinitebrahamanuniverse.”
Now, a question of utmost relevance for this publication is whether these packages are considered malicious or not.
Technically, they consist of just a package.json file with a list of dependencies. Nothing malicious there. And the README advises against installing it. A nice gesture by the author. But that still doesn’t mean that the package is not malicious.
Not leaving any scenarios behind
Consider a developer that has published some trivial package on npm and now wants to unpublish. Thanks to “infinitebrahmanuniverse,” that developer wouldn’t be able to do so: per npm rules, you can only unpublish a package that “no other packages in the npm public registry depend on.” So now your trivial package, unfortunately, cannot be left behind. It is easy to imagine that the author is forcing his dislike for the unpublish feature by playing with the boundaries of the npm registry.
Now, consider a bad actor that’s leveraging this dependency for an attack. By adding it to a typosquatting package, that threat actor can launch a Denial of Service (DoS) attack against a company's download channel, which can sabotage developers' time by forcing them to wait for their npm environment to be ready. Installing a package with this dependency can also cause excessive resource consumption. If you follow this series you should know by now that such scenarios are not far-fetched.
On the brighter side, it might be that the author just wants to promote less-known packages and increase their download stats. Or give a boost to the morale of maintainers of unknown packages by showing them that someone from the community is using them, therefore, appreciating their work. An unlikely, yet admirable scenario that would make it unfair for us to call it truly malicious.
And there’s even a spiritual interpretation to all this. The author's name references the concept of Brahman: the ultimate reality, consciousness, and source of the universe. When a package tries to install every known publicly accessible package in the npm universe, you have to wonder if there’s some type of mystical concept behind it.
But maybe we’re getting too hung up on the author's intent. We'll monitor the package and let you know if there’s more to it. In the meantime, the best you can do is to keep it out of your build environment.
A stack of malicious cryptominers
Our security research team uncovered a noticeable volume of cryptocurrency miners within the npm registry this past month. If you’re not familiar with cryptocurrency mining, it is a way to generate digital money online by using computers to solve complex mathematical problems. The process is validated when a miner is successful in solving the problem and is then rewarded with cryptocurrency. Attackers can earn money by using a victim’s computer for this purpose.
In one of our finds, speedtestgod — a malicious package impersonating the legitimate library speedtest-cli — contained a package.go file detected as a Trojan that targets Linux systems and attempts to mine cryptocurrency using unsuspecting victims’ resources.
We found other packages that utilized the very same Trojan file and uncovered that 16 of these malicious cryptominers originated from a single account: trendava. The supposed threat actor was reported and removed from the npm registry.
Our security researchers found additional cryptocurrency miners, including: best-man-fine, lagra, trova, trovam, speedgun, speedgum, flip-flop-flap, flip-flop-flip, flip-flop-flop, speedtestclix, speedtestcliz, speedtestwow, speedtestfast, speedtestbom, speedtesta, speedtesto, speedtestis, speedtestgod, speedtestsolo, speedtestrun, speedtestgo, speedtestkas, speedtestspa, speedtestzo.
Previously, we covered how cryptotminers flooded npm in attempts to infect Linux hosts. Just like before, the npm security team received a notification from us about these crypto miners.
The machine stops
Threat actors know there’s a big probability that their malware ends up being analyzed in some virtual machine by a group of security researchers. Anticipating that scenario, some attackers are designing malware that validates the presence of a virtual machine before attempting to execute. Such is the case with minimums, a malicious package in Python that our AI system flagged and our security researchers confirmed as malicious.
The package contains a payload in the setup.py file that attempts to download a Trojan virus from a rogue server, install it, and log the installation result using a Discord webhook.
Let’s take a deeper look:
The malware is designed to check if the current operating system is Windows. It then checks if the environment is not running in a virtual machine or sandbox environment. It does this by validating the presence of specific files associated with VMware and VirtualBox, as well as checking for the presence of certain processes that are commonly used by security researchers.
If the environment is a virtual machine, the code immediately returns without executing any further.
Next, the code checks whether the USERNAME environment variable matches one of the specified usernames (beferg, kimberlyro, amamar, andcoleman, rachestew, ralphgra, raymonke, joehal, pink, victoho, sharonj, etc) and returns if it does.
Finally, the code attempts to make a request to hxxps[:]//wtfismyip[.]com/text, a site used to detect the victim’s public IP and verify if it should infect that machine or not. After all validations are passed (no VM, no known user, no debugging processes running, no known IP address), the malware downloads and executes a binary, and then uses a Discord webhook to warn the attacker that the module has been installed.
As mentioned before, the purpose of these validations is to avoid executing the payload in a research environment where it can be easily detected.
Chasing RATs in a maze
In last month’s edition of Malware Monthly, we broke the story of a software supply chain attack that employed a unique tactic. Hernán Ortiz from our DevRel team summarized the tactic as such: “by combining the capabilities of a remote access trojan (RAT) and information stealers, these packages are strange mutations we hadn’t seen before in the PyPI registry.”
Hernán teamed up with security researcher Carlos Fernandez as the Watson to his Holmes to solve this mystery. Carlos even shared his discovery of the RAT mutants in a recent video for Help Net Security.
Hernán dove a bit deeper into the origin story and evasive variants of RAT mutants including Python packages forenitq, forenith, forenity, and forenitz in his recent piece published on HackerNoon.
Hernán’s and Carlos’ investigation stitched a story of malware that mutates to evade detection, a clipboard hijacker code to swipe cryptocurrency, and bad actors stealing malicious code from other bad actors.
An open source intelligence (OSINT) story like this could not have been told without humans seeing the patterns in the data caught by automated systems.
Anatomy of a malware analysis environment
As AI-enabled tools provide automated defenses for modern software supply chains, the humans wielding those tools need to stay up to speed with the latest developments in malware analysis.
Juan Aguirre, security researcher at Sonatype, recently laid out foundational knowledge for analyzing Python malware. In his article, he takes the audience into the fast-paced workflow of a security researcher while carefully explaining the basics with examples augmented by screenshots from command line, directory, and online tooling.
While Juan himself stated his article did not go “fully into the deep end” of malware analysis, he covered many critical fundamentals such as:
- Static vs. dynamic analysis
- Online tools for analyzing binaries
- How to use a combination of manual inspection and automated tools
Although he supplied only a sneak peek into the life of a security researcher, Juan equipped any reader with working knowledge of tools and actions to stave off any analysis paralysis when dealing with malware.
Automate protection from supply chain attacks
The packages mentioned above just scratch the surface of the volume of malware caught by our tools. Since 2019, we’ve discovered a total of 106,872 packages flagged as malicious, suspicious, or proof-of-concept.
Sonatype’s system uses ML/AI techniques to recognize unusual attributes for newly published components in public repositories. Data delivered via our tooling’s near real-time detection capabilities helps prevent our customers from inadvertently consuming malicious components.
If you want to stay protected from software supply chain attacks, consider Sonatype Repository Firewall to automatically block malicious packages from reaching your development builds.
.png)
