{"id":74683,"date":"2022-03-28T09:06:38","date_gmt":"2022-03-28T13:06:38","guid":{"rendered":"https:\/\/staging.checkmarx.com\/?p=74683"},"modified":"2026-04-10T18:50:59","modified_gmt":"2026-04-10T16:50:59","slug":"a-beautiful-factory-for-malicious-packages","status":"publish","type":"zero-post","link":"https:\/\/checkmarx.com\/blog\/a-beautiful-factory-for-malicious-packages\/","title":{"rendered":"A Beautiful Factory for Malicious Packages"},"content":{"rendered":"

Checkmarx Supply Chain Security (SCS)<\/a> team has uncovered hundreds of malicious packages<\/a> attempting to use a dependency confusion attack. Customarily, attackers use an anonymous disposable NPM account from which they launch their attacks. As it seems this time, the attacker has fully-automated the process of NPM account creation and has open dedicated accounts, one per package, making his new malicious packages batch harder to spot.<\/p>\n\n\n\n

At the time of writing, the threat actors RED-LILI<\/strong> is still active at the time of writing and continues to publish malicious packages. So far, the packages listed in this report were detected by Checkmarx\u2019s internal systems and disclosed to NPM.<\/p>\n\n\n\n

Intro<\/h2>\n\n\n\n

About 3 weeks ago we reported<\/a> in Checkmarx blogpost of an attacker experimenting in several techniques while attempting dependency confusion attacks. In the past week, research teams from JFrog<\/a> and Sonatype<\/a> have also published blog posts informing the community about hundreds of malicious packages. The 3 reports are all related to the same threat actor.<\/p>\n\n\n\n

The same attack actor appears in all reports, tracked as RED-LILI<\/strong> by Checkmarx SCS research team, has recently automated the process of creating NPM users along with package publication.<\/p>\n\n\n\n

Checkmarx SCS research team was tracking RED-LILI<\/strong>\u2019s activity since it was first discovered internally on 2022-02-23 by its automated software supply chain attack<\/a> detection systems. During this time, and until today, the team studied this attack actor\u2019s capabilities and techniques, while continuously disclosing the findings to NPM security team.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Multiple disclosure emails sent to NPM security team, informing them about RED-LILI\u2019s activity<\/em><\/strong><\/p>\n\n\n\n

Throughout the attacker\u2019s experiments iterations, the packages\u2019 functionality itself remained mostly unchanged. Specifics about the code, its likely origin, and other interesting details can be found in our previous blog<\/a>.<\/p>\n\n\n\n

Today, we want to shed some additional light on this new and intriguing technique. We looked at the attacks, put the pieces and clues together, and tried to assemble a likely outline of the attacker\u2019s automation. In addition, we can report that this threat actor has published ~800 packages via a fully automated system, responsible for creating NPM user accounts, and publishing packages while passing OTP (One Time Passwords) verification requests.<\/p>\n\n\n\n

Motivation<\/h2>\n\n\n\n

As mentioned above, threat actor RED-LILI is experimenting and testing new techniques that might help them to avoid detection and reach bigger distribution.<\/p>\n\n\n\n

We cannot, of course, be sure of this attacker’s intentions, but a possible motivation for this new experiment is to prolong the time the published packages are \u201calive\u201d on the NPM registry before they are detected and taken down.<\/p>\n\n\n\n

Customarily, an attacker would open an anonymous NPM account and publish all or most of their packages under this user account. One of the downsides of this is the fact that once one of the malicious packages is detected it is likely that all of the other packages under this user account will be detected as part of an investigation and will be taken down as well. This new technique (user account per package) goes into some effort to avoid a situation where the package is taken down for as long as possible.<\/p>\n\n\n\n

Picking The Attacker\u2019s Breadcrumbs<\/h2>\n\n\n\n

The initial curiosity toward this cluster of malicious packages was in light of the scale and frequency of the attacks. The attacker published ~800 packages, most of them having a unique user account per package, in bursts over the span of roughly a week. While the packages names were methodically picked, the names of the users publishing them were randomly generated strings such as \u201c5t7crz72\u201d and \u201cd4ugwerp\u201d. This is uncommon for the automated attacks we see. Usually, attackers create a single user and burst their attacks over it. From this behavior, we can conclude that the attacker built an automation process from end to end, including registering users and passing the OTP challenges.<\/p>\n\n\n\n

The Server Behind the Scenes<\/h3>\n\n\n\n

The first breadcrumb in the first wave of the attack is the domain \u201crt11[.]ml\u201d. It is pointing to the primary server of the attacker and this domain appears in the email address of the dummy users created in order to publish the packages. In addition, this domain is used as the target server address to which the data is being sent to.<\/p>\n\n\n\n

Later down the road, a new domain was registered \u201c33mail[.]ga\u201d and took the place of the former domain \u201crt11[.]ml\u201d. It is likely that both domains were acquired free of charge by Freenom<\/a> service.<\/p>\n\n\n\n

Looking closer at this server reveals that it appears to be hosted in a U.S. hosting company Multacom<\/a> which is based in California. We disclosed these findings to their NOC team as we believe this is one of their clients\u2019 activities and that Multacom has no relationship to this other than leasing the server to the attacker.<\/p>\n\n\n\n

Looking more deeply, this server has interesting ports open:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

An nmap scan result of the attacker\u2019s server<\/em><\/strong><\/p>\n\n\n\n

Since the server is listening to http\/https, we checked what is being returned when browsing into this webserver. The result you are seeing is the root page of the server version of Interactsh tool, hinting to us this is a self-hosted version of the popular open-source tool:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Interactsh<\/h3>\n\n\n\n

Interactsh is an open-source tool for out-of-band \u201cData Extraction\u201d, and is a tool originally designed to detect bugs that cause external interactions. The usage is quite simple, running Interactsh gives the operator a unique URL, which whenever interacted with it, audits the full details to the operator for later inspection. Interactsh supports multiple network protocols, including HTTP, SMTP, DNS, and more.<\/p>\n\n\n\n

Interactsh can be used as-is. Zero configuration is needed for inexperienced users via the web application app.interactsh.com. And for the more advanced users, Interactsh is built to run self-hosted on a dedicated server which its operator has the option to customize advanced settings including supporting a custom domain<\/p>\n\n\n\n

Package Name Picking<\/h3>\n\n\n\n

At first, the attacker\u2019s name picking puzzled our research team. But after giving it another look, they were able to identify a pattern. The attack actor specifically targeted the @azure NPM scope<\/a> under and as it appears, the attacker extracted the package names and altered their names, erasing the scope part (\u2018@azure\/\u2019 in this instance) or replacing it with a similar string (such as \u201cazure-\u201c) and doing their best effort in publishing non-taken packages under scopeless, similar package names.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

The Complete Picture<\/h2>\n\n\n\n

Now that we have a deeper understanding of the technology stack and tools used in this attack, we rolled up our sleeves and start reproducing it by ourselves. This exercise was done solely for the purpose of learning the attacker\u2019s challenges in implementing their system.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Server<\/h3>\n\n\n\n

The initial building block is setting up a Virtual Private Server (VPS). This server will run on an AWS EC2 machine. So, we launched one and wrote down its assigned IP and domain address to use in the next DNS configuration.<\/p>\n\n\n\n

Custom Domain<\/h3>\n\n\n\n

The next ingredient is our own domain. We purchased the \u201cmalpkg.site<\/strong>\u201d domain which we used as the primary domain pointed at our dedicated server.<\/p>\n\n\n\n

Setting up the domain\u2019s DNS records was quite straight forward as documents in Interactsh official documentation<\/a>. In addition to the regular A record,<\/strong> we also configured the NS record<\/strong> to support the DNS tunneling functionality for data exfiltration.<\/p>\n\n\n\n

Interactsh Server<\/h3>\n\n\n\n

As mentioned above, Interactsh<\/a> is an open-source project written in Go. It has a client application and a server application. The former can be installed from its source code using \u201cgo install\u201d command or by downloading a matching precompiled version from the project\u2019s releases page.<\/a><\/p>\n\n\n\n

The configuration of Interactsh server is straight forward. Since our server is hosted on AWS, and is assigned with a private IP address, we had to configure it with the public IP \u201c-ip\u201d. The domain flag \u201c-domain\u201d was also needed to instruct the server what name needed to issue an SSL certificate for. In addition, we wanted to add a token-based authentication between the client and the server, so we defined a token string as we ran the server. While experimenting the connectivity with the client, we saw the default client id was quite long, so changing the \u201c-cidl\u201d and \u201c-cidn\u201d flags made it possible to shorten the client id. Note that this needs to match in both server and client, otherwise the data will not be synchronized properly.<\/p>\n\n\n\n

sudo .\/interactsh-server -domain <domain> -ip <ip address> -e 1 -t <authentication token> -debug -cidl 9 -cidn 4<\/code><\/pre>\n\n\n\n
Once we got all the configurations in order, we had our own interactsh server linked to our new domain.<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
Interactsh Client<\/h3>\n\n\n\n
The next building block was to configure the Interactsh client with proper communication to the server to conclude the infrastructure phase. But before we go on to that, there is one more interesting detail that lies in this server-client connection.<\/p>\n\n\n\n
If not specified when running Interactsh server, it will allow connections from clients with no validation. This means that if our attacker ran their server in that manner, we would be able to connect to it and possibly gain access to interesting information. This hope had quickly faded since the attacker seems to use the \u201c-a\u201d or \u201c-t\u201d flags in the server run command, which means that access to it will be granted only to the client providing the correct authentication token.<\/p>\n\n\n\n
Setting up the client and its connection to the server is fairly simple.<\/a> The following command is what we\u2019ve used to connect to our server:<\/p>\n\n\n\n
interactsh-client -s <domain> -v -t <authentication token> -cidl 9 -cidn 4<\/code><\/pre>\n\n\n\n
And that is it! Our infrastructure is up and running. Next building block: Automation script.<\/p>\n\n\n\n
The Main Tool<\/h3>\n\n\n\n
The real magic is harnessing Interactsh as a building block with automation. I have written an internal tool in Python for research purposes, simulating the steps done the attack group. Partial code snippets from this tool are referenced below.<\/p>\n\n\n\n
Getting started with the development, the following major building blocks came to mind:<\/p>\n\n\n\n