Upon closer inspection, we discovered evidence of a coordinated supply chain attack, with a large number of NPM packages containing jQuery scripts designed to steal form data from deployed applications that include them. While the full extent of this attack isn’t yet known, the malicious packages we discovered are likely used by hundreds, if not thousands of downstream mobile and desktop applications as well as websites. In one case, a malicious package had been downloaded more than 17,000 times.
As with the recent (benign) dependency confusion attacks targeting German organizations, these clearly malicious attacks relied on typo-squatting, a technique in which attackers offer up packages via public repositories with names that are similar to — or common misspellings of — legitimate packages. Attackers impersonated high-traffic NPM modules like umbrellajs and packages published by ionic.io. However, it is the end users of software (and their data) rather than development organizations that are the real targets. That makes this attack more comparable to the infamous SolarWinds compromise than to other, more recent supply chain compromises. Furthermore, similarities between the domains used to exfiltrate data suggest that the various modules in this campaign are in the control of a single actor.
Here’s detailed information on this widespread software supply chain attack, including known indicators of compromise (IOCs) associated with the attacks — and recommendations for remediating the threat posed by these malicious NPM modules.
The ReversingLabs research team is continuously monitoring open-source package repositories for instances of malicious code planting and software supply chain attacks. This work involves both automated and human-led scanning and analysis of packages published in the most popular public package repositories like NPM, PyPI, Ruby and NuGet. During these scans, we leverage our proprietary Titanium platform, and our deep file repository of goodware and badware to spot malicious and even suspicious elements hiding in plain view. Our newly released ReversingLabs secure.software solution builds upon that past work. The platform provides a way for dev and SOC teams to deeply examine their CI/CD workflows, containers and release packages to spot nascent or active software supply chain compromises.
Here’s how tracking the usage of this obfuscation technique resulted in discovering several NPM accounts, which were used to publish malicious code designed to steal form data entered by end users of infected web applications.
The core capability of ReversingLabs’ secure.software solution is analyzing code intent while highlighting malicious behaviors. These indicators cover all kinds of software behavior, from network and file system activities to use of packers associated with malicious campaigns, and the use of evasion techniques.
Can you spot the pattern? A deeper investigation into these NPM modules reveals even more connections. All were connected to one of a handful of NPM accounts with names like ionic-io; arpanrizki; kbrstore; and aselole.
Obfuscated code found stealing form data
Clearly, the typo-squatting technique used to fool developers into confusing the malicious packages with their legitimate counterparts was working. Packages created by the NPM ionic-io author, for example, show that the author published 18 versions of an NPM package named icon-package containing the malicious form stealing code. That was a glaring attempt to mislead developers into using this package instead of ionicons, a popular, open-source icon set with more than 1,000 icons for web, iOS, Android, and desktop apps.
Figure 2: Version data related to icon-package
NPM download stats show that the malicious icon-package has over 17,000 downloads. Data exfiltrated using this package passes through a domain hxxps://ionicio.com, a play on the legitimate ionicons framework domain ionic.io that would be easy for application developers to overlook. The ruse extends beyond the NPM ecosystem, though. Note the visual similarity between the fake ionic web page seen in Figure 3 and the legitimate ionic page in Figure 4.
Figure 3: Fake ionic webpage
Figure 4: Legitimate ionic webpage
Under the hood, the malicious packages use a modified script that extends the behavior of the jQuery ajax() function to exfiltrate serialized form data to domains controlled by the attacker. Prior to sending the data, the function validates the URL content to perform target filtering checks.
The trail begins in December 2021
In the process of tracing the origin of the campaign, even older packages containing this type of malicious functionality were discovered. They were published in December 2021 by the author fontsawesome, and also targeted the already mentioned ionicons icon set. The domain used for data exfiltration in these packages is the same as the one used in the first two versions of the icon-package package: hxxps://graph-googleapis.com.
While the exact start of this campaign is unknown, the malicious package published from December 2021 all the way to the middle of May 2022 focused on mimicking the ionicons framework. At that point, the attackers switched to developing new NPM packages that reused the same functionality and also started targeting other popular UI frameworks.
We also observed several packages published by the NPM account arpanrizki engaging in similar form data-grabbing. However, the exfiltration domain associated with these packages is different: hxxps://arpanrizki.my.id. The form identifier for exfiltrated data was quite specific: ValidateVerificationDataForm. So, as part of our investigation, we performed a GitHub search for this identifier, with some interesting results. (See Figure 5.)
Figure 5: GitHub search results
As the results show, one of the GitHub repositories containing the string in question were maintained by arpantek, a nickname very similar to the one of the NPM author. The other result was related to a HackingTool repository belonging to the NPM author Woxruz.
Figure 6: Woxruz’s HackingTool
The last commit’s description gives us a clue of the intended use for these software projects. These tools were designed for “Hacking PUBG i’d” [sic]. PUBG is a popular online-multiplayer video game with a large number of users. In other words, it seems the person behind the arpantek and arpanrizki accounts tried to port the login stealing script to the NPM ecosystem to expand the reach.
Figure 7: sidr package description and the content of the referenced website
Hungry for data
While the malicious packages we initially observed took a conservative approach to harvesting form data, the more recently published malicious packages are taking a more aggressive approach to acquiring data. Another malicious package we identified, footericon, gathers data from all form elements with a defined “login-form” class.
Figure 8: Form data exfiltration code from footericon package
Figure 9: Form data exfiltration code from swiper-bundIe package
Clues hidden in code
Figure 10: Comment header at the beginning of the payload from swiper-bundIe package
Finally, the malicious packages use exfiltration domains with a consistent naming pattern: <subdomain>.my.id. Together, these clues suggest a common actor behind the various malicious packages and a unified campaign.
List of malicious NPM modules
|Author / Package name||Download count|
Table 1: List of malicious packages with corresponding download count
ReversingLabs’ research uncovered an extensive software supply chain attack involving more than two dozen NPM modules used by thousands of downstream applications, as indicated by the package download counts.
Analysis of the modules reveals evidence of coordination, with malicious modules traceable to a small number of NPM publishers, and consistent patterns in supporting infrastructure such as exfiltration domains. ReversingLabs reached out to the NPM security team to report the findings on July 1st, 2022.
This attack marks a significant escalation in software supply chain attacks. Malicious code bundled within the NPM modules is running within an unknown number of mobile and desktop applications and web pages, harvesting untold amounts of user data. The NPM modules our team identified have been collectively downloaded more than 27,000 times. As very few development organizations have the ability to detect malicious code within open source libraries and modules, the attacks persisted for months before coming to our attention. While a few of the named packages have been removed from NPM, most are still available for download at the time of this report.
In publishing this report, we hope it serves as a resource for development organizations to assess their own exposure to these malicious NPM modules. We have prepared a list of affected modules and indicators of compromise that organizations can use to look for evidence of active attacks.
Looking beyond this specific incident, it is clear that software development organizations as well as their customers need new tools and processes for assessing supply chain risks like the ones posed by these malicious NPM packages. The decentralized and modular nature of application development means that applications and services are only as strong as their least secure component. The success of this attack — with more than two dozen malicious modules available for download on a popular package repository, and one of them with 17,000 downloads in a matter of weeks — underscores the freewheeling nature of application development, and the low barriers to malicious or even vulnerable code entering sensitive applications and IT environments.
Indicators of Compromise (IoC)
C2 domains extracted from the analyzed NPM packages:
|Package Name||Package Version||SHA1|