“I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which will probably install malware.”
When we analysed the malware – we found that clear links to earlier stages of the attack from an attacker named “wozheqirsplu”, described below.
The attacker compromised Faisal’s npm access and updated the npm package.json file to run a file called preinstall.js:
Preinstall.js then determines the operating system:
If it is running on Linux – it then runs preinstall.sh:
This determines the location of the system, and if it is not in one of the following countries continues to execute:
- Russia, Ukraine, Belarus or and Kazakhstan
It then downloads the file http://159.148.186[.]228/download/jsextension and executes it. The file jsextension the crypto-currency miner xmrig – set to use the minexmr mining pool with the monero wallet:
If it is running Windows – it then runs preinstall.bat:
Similarly to the Linux installation – this downloads a copy of xmrig (via curl or certutil) and runs it with the same parameters. The file sdd.dll is detected as a credential theft tool.
Setting up the Attack
The malicious file deployed on Windows machine is served from:
And has the SHA256 7f986cd3c946f274cdec73f80b84855a77bc2a3c765d68897fbc42835629a5d5.
This file has been seen before.
Back on Wednesday October 20th, Sonatype wrote a blog titled “Newly Found npm Malware Mines Cryptocurrency on Windows, Linux, macOS Devices”. They saw the same file – but back then it was being served from a different server:
Sonatype spotted a malicious user named wozheqirsplu had first created a npm package called okhsa that started calc.exe (Opening the Windows Calculator is a typical first step in testing malicious execution):
The malicious code in this package is an earlier version of the code actually deployed live – it has a couple of small changes such as a different Monero wallet ID:
(Earlier prototype of the code on the left. The right hand side shows the code deployed in the attack)
When Sonatype published their blog on October 20th (two days before the real attack) they noted that – at that point – it wasn’t clear how the attackers intended on deploying their malicious package:
In hindsight – it’s now clear that this was the user wozheqirsplu preparing for their attack.
Assume that any machine that has run compromised versions is compromised, and rotate and credentials or keys on the machine from a separate machine.
When deploying software, check for compromised dependencies as part of any build process.
Indicators of Compromise
citationsherbe[.]at – Note this is also referenced in https://unit42.paloaltonetworks.com/matanbuchus-malware-as-a-service/ – we haven’t confirmed the nature of the link yet.