As part of the ReversingLabs research team's ongoing surveillance of open source repositories, we have identified aabquerys, a malicious npm package that downloads second and third stage malware payloads to systems that have downloaded and run the npm package.
Since discovering the aabquerys package, npm has removed it from their repository along with other, malicious packages. We do not believe it poses any risk to development organizations at this point. However, the discovery of aabquerys and evidence of other malicious projects by the maintainer responsible for the package underscore the growing risk of malicious packages lurking in open source repositories like npm, PyPi and GitHub. This risk demands greater attention by development organizations to the telltale signs of malicious or suspicious behavior within their open source supply chain.
Here is the ReversingLabs threat research team's findings — as well as guidance on how organizations can respond to the risk posed by malicious open source packages.
How our team identified the package
As with other examples of malicious open source packages, aabquerys first attracted the attention of ReversingLabs because of both package version numbers and content that appears suspicious. The package name, aabquerys, is also similar to the name of another, legitimate npm module: abquery, evidence of “typosquatting,” or attempting to sow confusion and fool developers into downloading a malicious package in place of a legitimate one.
Red flag: obfuscated code
The reasoning behind this is obvious: by their nature, open source code is intended to be viewable by everyone, so an effort to disguise or hide functionality within an open source module should be investigated. In the case of aabquerys, the obfuscated code in question was easily de-obfuscated. That revealed a jquery.js file with clearly malicious behavior.
Figure 1: Deobfuscated content of jquery.js file
Analysis: malicious downloader targeting PCs
According to our analysis, the jquery.js file first checks if the environment in which it is being run is a PC. If it is not, a message alerts the user (victim) that this "plug-in only supports installation on the computer side". Users who open the file on a PC are greeted with what appears to be a web browser crash message (it is not real) and a link that leads to hxxps://github.elemecdn.com from which a second stage malware is installed: install_flash_player_ppapi.exe, a Windows PE (portable executable).
Sideloading attack delivers the goods
This Windows PE (portable executable) file is an InnoSetup installer package that contains a legitimate PE executable: wsc_proxy.exe that is signed with a valid certificate issued to AVAST Software s.r.o. The wsc_proxy.exe executable is known to be vulnerable to the sideloading attacks. This component has been used in several malware campaigns.
With aabquerys, the sideloading is performed by putting a DLL file named wsc.dll with an exported function named run in the same folder where wsc_proxy.exe is located. That legitimate executable is then started and the run method from the malicious wsc.dll gets invoked.
Figure 2: Malware infection stages
Havoc summons the Demon.bin
Once the malicious wsc.dll is run, it downloads the third stage malicious component, Demon.bin, from an external command and control site: hxxp://22.214.171.124/vendor/htmlawed/htmlawed/demon.bin
Demon.bin is a malicious agent with typical RAT (remote access trojan) functionalities that was generated using an open source, post-exploitation, command and control framework named Havoc. The Havoc framework was created by the malware author known as C5pider. It supports building malicious agents in several formats including Windows PE executable, PE DLL and shellcode.
The downloaded malware we analyzed was built in the Windows shellcode format and contained loading code and an obfuscated DLL with the malicious functionality. We successfully extracted the malicious functionality from the sample using ReversingLabs’ TitaniumPlatform. When executed, the agent connects to the C2 server using the zh[.]googlecdnb.tk domain.
Not the end of the story
We first encountered a abquerys at the beginning of February, but we soon realized that it wasn’t the only package of this kind. First: the maintainer account linked to aabquerys, “obm2y67w,” had published multiple versions of packages nvm_jquery and aabquery. Upon further inspection, their functionality was identical to aabquerys,’ though they appear to be an early iteration of the aabquerys malware. For example: it appears to us that the first version of nvm_jquery was only used for testing functionality locally. Specifically: the download link in the file was pointing to an internal IP address, hxxp://126.96.36.199/install.zip. We also discovered some of the early versions of the downloader that already contained the second stage malware alongside the downloader. That is almost certainly a publishing mistake made by the malicious author.
Further research turned up a second account linked to the original malware maintainer, “cq0km9hu.” It was that account that was used to publish the aabquerys package we analyzed in this blog. As we have noted in other write ups: malicious authors often use multiple accounts - even scores or hundreds of them - to seed open source repositories like npm and PyPi with malicious modules.
Indicators of Compromise (IOC)
Found malicious packages
Second stage malware
Third stage malware
|core Havoc dll||4b0c13a054cadbfddf82686f4b4ff082e9cae428|
Command and Control (C2) Infrastructure
The following Internet addresses were observed hosting malicious infrastructure used to support the aabquerys malware:
The npm repository acted quickly to remove the aabquerys package and other, related modules — even before ReversingLabs notified them of our findings. At this point, there is no evidence of a wider campaign associated with the aabquerys authors or malware and ReversingLabs does not believe this poses a threat to development organizations.
Analysis: many C2 frameworks out there
Havoc is not the only open source Command and Control (C2) framework used by malicious actors. In fact, there are a number of similar, C2 frameworks that are obtainable on GitHub. These are intended for use by red teams though, of course, their features are easily adaptable for use by malicious actors, also.
The following list includes a few of the C2 frameworks ReversingLabs A1000 platform has identified being used alongside active malware campaigns:
As described in a recent ReversingLabs' blog post, Manjusaka is a free C2 offensive framework with the ability to “generate new implants with custom configurations with ease.” It is very similar to the Cobalt Strike and Silver C2 frameworks, which are often abused by malicious actors. Source code for Manjusaka with a detailed explanation (in Chinese) of how to use it can be found on its GitHub page.
Figure 3: Samples classified with A1000 as Manjusaka
Covenant is a C2 framework that targets the attack surface of Microsoft’s .NET framework. It is aimed at red teams and offers extensive documentation. It should be noted that the last update on GitHub page was in April of 2021, however there is no indication that Covenant is no longer an active project.
Merlin is a C2 framework with a server and client built in the Go language. The Merlin agent has its own repository, and the server requires no installation, but can be run immediately upon download. Unlike Covenant, Merlin is still being regularly maintained, with the last update in July of 2022.
Empire is a legacy C2 framework that is the merger of the previous PowerShell Empire and Python EmPyre projects. The framework includes a pure-PowerShell2.0 Windows agent, and a pure Python 2.6/2.7 Linux/OS X agent. It offers cryptographically secure communications and a flexible architecture. Empire gives red teams the ability to run PowerShell agents without needing powershell.exe and rapidly deploy post-exploitation modules ranging (keyloggers, Mimikatz, etc.) As of January, 2020, the original project is archived and no longer updated. A new forked project BC-Security is being actively managed and used. It also supports server/client structure, and it can be used through GUI as well as through CLI.
Compared to other, recent examples of malicious software campaigns conducted on public, open source repositories, the aabquerys campaign is not a cause for major concern. This incident involved a small number of packages overall (3) connected to two maintainer accounts. Furthermore, despite the use of typosquatting, the modules in question were bare bones, with little effort to construct convincing package profiles that would confuse developers. Finally, the modules in question have since been removed from npm and no longer pose a threat.
However, the incident is a reminder to development organizations of the growing risk posed by malicious code lurking on open source repositories. While the chances that any developer would have downloaded aabquerys is low, the techniques employed to disguise malicious functionality in the aabquerys module could just as easily be used in conjunction with more sophisticated staging and social engineering strategies to place malicious code on a developer’s system.
As with any open source software, development organizations need to monitor for red flags in the code they are downloading and incorporating into internal development projects. That includes (but isn’t limited to) the presence of obfuscated code as well as the use of known vulnerable components (in this case: wsc_proxy.exe). Attention also needs to be paid to links out to external sites and assets or infrastructure that could indicate communications with malicious command and control systems.
The aabquerys module is a reminder of the havoc (pun intended) lurking in open source and proprietary software supply chains and the need for greater vigilance by development groups to keep from being victimized by supply chain attacks.