<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1076912843267184&amp;ev=PageView&amp;noscript=1">
RL Blog

Operation Brainleeches: Malicious npm packages fuel supply chain and phishing attacks

“Write once, infect everywhere” might be the new cybercrime motto, with newly discovered campaigns showing malicious npm packages powering phishing kits and supply chain attacks.

Lucija Valentić
Blog Author

Lucija Valentić, Software Threat Researcher, ReversingLabs.

Operation Brainleeches: malicious npm packages fuel supply chain and phishing attacks

Executive Summary

ReversingLabs researchers recently discovered more than a dozen malicious packages published to the npm open source repository that appear to target application end users while also supporting email phishing campaigns targeting Microsoft 365 users. Some key takeaways from our report: 

  • The discovery may be the first "dual use" campaign in which malicious open source packages power both commodity phishing attacks and higher-end software supply chain compromises.
  • The malicious npm packages were discovered in two tranches: One supported phishing attacks that harvested user data with phony Microsoft.com login forms launched from malicious email attachments. The other was intended to implant credential harvesting scripts in applications that inadvertently incorporate the npm packages.
  • The malicious packages were posted to npm between May 11 and June 13. They mimic legitimate npm modules, notably jquery, which has about 7 million weekly downloads.
  • The malicious packages were downloaded around 1,000 times in total, but were removed from npm shortly after their discovery. ReversingLabs has dubbed the campaign “Operation Brainleeches,” based on malicious infrastructure used to facilitate the theft of victim data.
  • With npm used to support malicious campaigns, organizations should check their exposure to these malicious modules, which may indicate a broader, malicious campaign. 


At ReversingLabs, our researchers dedicate time to combing through public code repositories in search of malicious packages. These range from primitive infostealers that exfiltrate information from infected machines (some of which are probably benign and related to red team activities), to malicious modules that are designed to steal user credentials, access tokens and other sensitive information. When we find a malicious package, we report it to the affected repository’s administrators to remove the package —if they haven’t already done so.

Recently, our researchers came across a malicious campaign on the npm open source repository that encompassed more than a dozen files designed to steal sensitive user credentials. There were a number of “red flags'' that indicated these packages were malicious. They were analyzed in depth using ReversingLabs Software Supply Chain Security

Here is our threat research team's findings and an analysis of the malicious Operation Brainleeches campaign.

Red flags wave on npm

This most recent campaign caught our attention because of a number of features and characteristics in related npm packages that correlate with malicious intent. In many of the packages that make up the Operation Brainleeches campaign, our researchers noted the presence of new and relatively unsophisticated npm packages, maintained by relatively new and cursory maintainer accounts. Finally, many of these packages contained files that were obfuscated. 

New files and sketchy maintainer accounts don’t obviously signal “malicious intent.” But obfuscation of code in ostensibly open source packages — together with those other characteristics — is a tell-tale sign that something is amiss. There is the obvious question: "Why do you need to shield code in a software module that is public property?" There is also the high correlation between open source modules that use obfuscation and open source modules that are found to be malicious. We have noted this previously in our research on nodejs-encrypt-agent (see “RATs found hiding in the npm attic”). Also, hear ReversingLabs researcher Karlo Zanki talk about this correlation in an episode of the ConversingLabs podcast.

A double threat

Ultimately, our inquiry into the suspicious characteristics revealed 13 malicious packages that we’ve grouped into two tranches with similar contents, but different purposes. 

The first group includes six packages: different versions of npm packages named standforusz and react-vuejs (version 3.0.10). These were published in the middle of May and, based on our analysis, were used exclusively for hosting files used in widespread phishing campaigns, which were likely derived from turnkey phishing kits sold on the cyber underground. These packages contain the following files: 

Content of packages used in phishing campaignsFigure 1: Content of packages used in phishing campaigns

The second group of packages, seven in all, includes versions of npm packages named tetusdgsudgs, jqueryoffline, vueofflinez, jquerydownloadnew and react-vuejs (version 10.21.30). Published in early June, they can be used both for hosting files used in email phishing campaigns and performing supply chain attacks targeted at application end users, based on our analysis. 

Content of packages used in supply chain campaignsFigure 2: Content of packages used in supply chain campaigns

Here are the characteristics of these dual attacks, and what they say about the rapid evolution of supply chain threats. 

Phase 1: Phishing the supply chain

In our experience, malicious packages found on public repositories such as npm or PyPI target developers — the people who directly use them. As in campaigns like those targeting SolarWinds and 3CX, these supply chain attacks sit at the “sophisticated” end of the scale. They are long-term plays in which skilled cyber actors quietly infiltrate development pipelines and slip malicious code or dependencies into legitimate application updates. Patience pays off: they reap the bounty of hundreds or thousands of victims as unsuspecting users of those applications download and install the signed, but compromised update. 

However, after unpacking and deobfuscating files from this first tranche of malicious npm packages, it became very apparent (to us) that we were looking at a new manifestation of supply chain risk. Specifically: Our analysis revealed that these malicious packages were being used as supporting infrastructure for a phishing campaign targeting Microsoft 365 customers.

Standforusz: Microsoft 365 phishing made easy

A key to this realization was the npm package standforusz, which contained the files DEMO.txt, jquery.js, jquery.min.js and package.json. ReversingLabs researchers observed malicious email attachments containing the jquery.js paired with phishing emails. When the malicious attachments are opened by victims in a browser,  jquery.js was observed fetching jquery.min.js from the content delivery network (CDN) jsDelivr, and writing the content of that file to a dynamically created “document." The jquery.min.js's content fetches DEMO.txt also from CDN jsDelivr and writes its content to the same "document."

The DEMO.txt file contains HTML code that mimics the login for Microsoft.com. It also includes the URL of a remote server, hxxp://ourwhite.brainleeches.xyz, to which harvested credentials from the form are sent. The diagram below (Figure 3) shows the flow of the activity once the malicious attachment is opened in their web browser.

Flow of the activity when malicious attachment is opened in web browser

Figure 3: Flow of the activity when malicious attachment is opened in web browser

Evidence of turnkey attacks

Observing this campaign in action was challenging, as the malicious domain used in it was taken offline by the time our analysis was conducted. However, our researchers were able to identify examples of the malicious email attachments containing files from these modules in the wild. They contained vestiges of the original attack, including a page displaying a background image identical to the background image used with the Microsoft login. By and large, these appeared to be part of turnkey attacks spawned by phishing kits that are sold and licensed to unsophisticated malicious actors. 

Real Microsoft login form

Figure 4: Real Microsoft login form

To show what the victim would actually have seen when the domain was active, we made a few tweaks. Figures 4 and 5 serve as a comparison between the actual Microsoft login form (Figure 4) and the fake one presented to unsuspecting end users (Figure 5).

Fake Microsoft login form

Figure 5: Fake Microsoft login form

The fake Microsoft.com login wasn’t the only trick up the attackers' sleeves. Our analysis revealed another phishing page geared to gather Microsoft 365 credentials. Unlike the previous pages, this displayed a blurred document overlaid with what appears to be a Microsoft login screen. The implication is that the document can be viewed only if logged in to a Microsoft account. 

As it turns out, the ”blurred document” is actually just a picture formatted as a background that is intentionally blurred to entice the end user to enter their Microsoft account credentials (Figure 6). Passwords entered into this form were sent to a different location, a server located at the address

Malicious form presented to end users

Figure 6: Malicious form presented to end users

The malicious actors behind these phishing attacks took steps to make it more likely that the victim would enter their Microsoft credentials, also. Those included attempting to disable right mouse button functions on the web page and disabling the ability of users to open developer tools with a hot-key. Those steps made the malicious intent less likely to be discovered.

HTML attachment used in phishing campaign found in the wild

Figure 7: HTML attachment used in phishing campaign found in the wild

As we noted, npm in this phase of the campaign is used primarily as a host for a malicious component of the attack, rather than a platform to target developers (or end users as in the case of Phase 2 packages) with malicious, open source modules. Our open source research uncovered both remnants of Operation Brainleeches, as well as a very large number of similar email phishing attachments spawned by slightly different, but closely related phishing kits. That suggests that the modules identified in Phase 1 of the attack were likely not unique, but part of a broader wave of attacks orchestrated by low level actors outfitted with powerful and automated tooling. 

Phase 2: Developers in the crosshairs

As we noted, Operation Brainleeches comprised two phases and two, distinct tranches of malicious npm packages. While the first was clearly intended to support indiscriminate and automated phishing email attacks, the second group of npm packages had a different flavor, and appeared more in line with other software supply chain attacks we have analyzed. 

Specifically: The purpose of the second phase of the Brainleeches campaign appears to have been tricking developers into incorporating the malicious packages into legitimate applications.

As was the case in the first phase of the attack, the ultimate objective here, also, was phishing credentials. In other words, as in Phase 1, the target of the malicious code embedded in these npm packages was not developers or development organizations, but end users of the developed applications (and their data).  

Here are some of our team's findings from an analysis of the files contained in this group of malicious npm packages: tetusdgsdgs, jqueryoffline, vueofflinez, and jquerydownloadnew.

Jqueryoffline: Designed to confuse

To help understand this phase of the attack, we’re going to unpack jqueryoffline, one of the first malicious packages that caught the attention of our researchers. As we noted above, the npm packages that make up this campaign were singled out because they contained obfuscated code, which the actors responsible for the campaign accomplished using a JavaScript obfuscator alongside encrypting variables with hex encoding. Once the jqueryoffline files were de-obfuscated, we weren’t surprised to find that they were hiding malicious functionality. The question for us was ‘what is the purpose of these malicious files?’ 

Unlike the packages standforusz and react-vuejs, it appeared to us that jqueryoffline was intended, at least in part, to achieve a supply chain compromise of an established application. Partially, that conclusion is derived from the choice of package name, which invokes jquery, a  play on the name of a popular npm package, jquery, which is downloaded about 7 million times weekly. 

Upon viewing the package contents, we also noted the presence of two files that were not present in packages used in the first phase of the attack: index.js and index.html. The file index.js is specified as the main inside the package.json file found within the jqueryoffline package. 

So how might this supply chain attack play out? Consider the example of a modern javascript application developed using a tool like the Webpack. A popular, open source module bundler for Javascript, Webpack bundles JavaScript files for use in a browser. For an application developer who is tricked into adding the jqueryoffline npm package as a dependency in lieu of the legitimate jquery package, Webpack will compile the necessary code and ensure that the content of the jqueryoffline index.js file, which is specified as the main inside jqueryoffline package.json file, ends up in the main.js file which is the entry point of the Webpack bundled application (Figure 8). 

Content of the main.js file containing malicious code bundled with webpack

Figure 8: Content of the main.js file containing malicious code bundled with webpack 

The Webpack bundled application, including the malicious jqueryoffline code, would then be shipped to end users, who would be presented with the fake Microsoft login form observed in Figure 5 upon executing the Javascript application. 

A broad campaign

This same pattern was observed in the other npm packages identified in Phase 2 of this campaign: tetusdgsudgs, vueofflinez, and jquerydownloadnew.

Packages containing DEMO.txt found using ReversingLabs A1000

Figure 9: Packages containing DEMO.txt found using ReversingLabs A1000

Given the similarities of each of these packages, it’s likely they were created by the same actor. Each of the above packages had a file — or multiple files — that somehow incorporated jquery.min.js or DEMO.txt from standforusz, version 1.0.3. Additionally, we observed that passwords collected by the forms spawned from those packages were sent to the same domain, which was included in the DEMO.txt file. Finally, in each case, the name of the maintainer account in each case was identical to the name of the package.

Is this IconBurst re-loaded?

As we noted above: the target of the Operation Brainleeches supply chain attack wasn’t developers or development organizations so much as end users. In that sense, this new campaign recalls another malicious campaign that ReversingLabs discovered nearly a year ago, which the team dubbed “IconBurst.” 

In that incident, ReversingLabs’ researcher Karlo Zanki identified around two dozen packages on npm that were “designed to steal form data entered by end users of infected web applications or websites where the malicious packages had been deployed.” In that attack, the malicious packages we discovered were likely used by hundreds, if not thousands of downstream mobile and desktop applications as well as websites. The attack relied on typo-squatting, with attackers impersonating high-traffic npm modules like umbrellajs and packages published by ionic.io.

As with the current campaign, IconBurst was also leveraged to further phishing attacks. Specifically, the threat actor behind IconBurst promoted it as a phishing script for PUBG users. (PUBG is a massively multiplayer online game.) 

So was the campaign we uncovered a reboot of IconBurst? There are similarities between the campaigns, including the deployment of information-stealing forms, the use of the .xyz top level domain with command and control infrastructure and similarly structured npm packages. However, there are differences as well. An analysis of IconBurst revealed evidence of a significant effort by threat actors to make the malicious npm packages resemble popular, legitimate packages. That included copying the look and feel of the targeted npm packages on typosquatted fake domains created to fool developers. Similarly, considerable effort was made by attackers in the IconBurst campaign to make the finished packages both functional and trustworthy to avoid attracting the attention of developers. 

That was not the case with the latest campaign. Instead, many key elements of the new campaign suggest that the malicious modules identified in this campaign were either the byproducts of a large-scale email phishing campaign conducted by low-skill (or at least low effort) actors, or a hastily conducted supply chain attack that leveraged many elements of the phishing campaign. For example, consistent use of default file names like index.html and DEMO.txt suggest that the attack may have originated in a standard phishing kit and was minimally altered before being launched, even when targeting end users. 


As the ReversingLabs team has shown in prior research, malicious actors are turning to attacks on software supply chains to facilitate compromises of software makers and, by extension, their customers and end users. Historically, the vast majority of supply chain attacks have developers and development infrastructure in their cross hairs. 

Campaigns like IconBurst show that open source modules and infrastructure can be leveraged for a variety of malicious ends. In that incident, malicious npm modules facilitated attacks on end users by inserting info-stealing forms into legitimate applications. That obviated the more common route of launching attacks directly on deployed applications or web sites and risking detection.  

This latest Operation Brainleeches campaign highlights a wrinkle in the already complex picture around software supply chains: The role open source platforms and modules play in supporting both targeted hacks, and low-skill, broad-brush attacks like email-based phishing campaigns. 

Details of the attack suggest that the malicious packages and libraries that make up this campaign served multiple purposes: supporting automated email phishing attacks likely derived from a phishing kit, and facilitating more subtle attacks designed to fool developers into incorporating malicious npm modules into their applications.  

How did this play out in real life? ReversingLabs researchers obtained malicious email attachments identical to the byproducts of this campaign in the wild, which gives credence to the idea that the malicious npm modules played a role in active phishing attacks, likely carried out by a low skill actor or actors. 

The picture regarding supply chain attacks is less clear. As we noted: The malicious actors invoked the name of popular packages like jquery, and relied on obfuscation to hide the contents of files within the malicious packages. However, much of the supporting infrastructure for the campaign, including command and control servers, were taken down soon after this campaign was revealed, and before any application compromises were registered. 

Regardless, this campaign further underscores the need for organizations to be on the lookout for signs that open source packages could be malicious or compromised. Often, these attacks hinge on developer inattention to small details in naming, but that’s not all. The use of obfuscated code is a major warning sign. Other indicators include suspicious naming and package versioning, new packages with sketchy histories, smaller than expected downloads and dependencies, and more. 

When using packages from public repositories in their projects, developers should keep an eye peeled for these small, but telling details to avoid a malicious package being introduced as a dependency in some larger project. Development organizations also need to scrutinize the features and behaviors of the open source, third-party and commercial code they are relying on in order to track dependencies and detect potential malicious payloads in them. ReversingLabs technology, including our A1000 and Software Supply Chain Security platforms, deliver the visibility teams need to discover malware.

Indicators of Compromise (IOCs)

Type Description
Command & Control ourwhite.brainleeches.xyz
Command & Control


package_name/file version SHA1
standforusz 1.0.2 93027a2aa009502ce1992c851d4551573cb90b94
standforusz 1.0.3 121b10560f54d7767d250e15deb4aff89b577d03
standforusz 1.0.4 6c315b0907ce516d8b9c12d9609c752ff2107d88
standforusz 3.0.10 0b4247bf806e33d8d02b8051224d2d110a2b4f19
standforusz 3.0.7 3eb67cdd1d992db9fa11c924273eef31c315fe8c
react-vuejs 10.21.30 5448aa6902a98308836cca6a3ac6e30ede074e8b
react-vuejs 3.0.10 b29ae6894064b761522e0fffae3c6ae31c6b6604
tetusdgsudgs 1.0.3 33d1401651e16db2031b597a2a7ac36dfd2a7a27
tetusdgsudgs 1.0.4 47c8cd0a9203cb388e7cf865d3493da91f408ae0
tetusdgsudgs 1.0.5 4fd665a5c610a30528417ea0e201e0c4f946f5fc
jqueryoffline 1.0.2 10b0c28cac9375cae74464343309a85d74687d9e
vueofflinez 1.0.1 d186505f2fecf7c959f7f0441cf4a221bbbbe41c
jquerydownloadnew 1.0.1 4b938ea813c9be1feb95fcec52991b5ba8ee88fb
attachment.html   6c2d2d3c2e68bf3df88a41033a536d16c59c2f9d


Keep learning

Explore RL's Spectra suite: Spectra Assure for software supply chain security, Spectra Detect for scalable file analysis, Spectra Analyze for malware analysis and threat hunting, and Spectra Intelligence for reputation data and intelligence.

More Blog Posts