First Node.js-Based Ransomware: Nodera | Hacker News Reader

First Node.js-Based Ransomware: Nodera

blogs.quickheal.com

62 pointsel_duderino24 comments

Open articleView on HN

Site is currently down; https://web.archive.org/web/20200122181519/https://blogs.qui...

The article mentions the ransom message with the date March 1 2018. This probably means this malware is two years old?

> This ransomware seems to be in development phase and has some flaws as mentioned below:

> ...

> Hard code destruction time of Private Key “March 1 2018”.

Quite possibly. I'm not sure what that language means and they don't provide more analysis of the HTML page that comes from. If it's in development maybe some dude has been sitting on this idea for a few years and their virus scanner just picked it up recently.

Ironically, the archive link you provided also doesn't load for me.

If it's just a blank screen, it's a longstanding issue nobody seems to acknowledge:

https://news.ycombinator.com/item?id=21765389

> There's a problem with the Wayback Machine in specific which can kill your ability to access it quite silently, unless you know how to use the browser's development tools and interpret headers.

> It has to do with cookies: Somehow, the Wayback Machine sets cookies... and sets cookies... and keeps setting cookies, until it overflows its own ability to accept cookies. At that point, your browser tries to access a Wayback Machine page, handing the server all of the cookies it currently has, and the server refuses to deal. It absolutely denies everything, sending an error header and a blank page. You have to clear all web.archive.org cookies to get anything at all, at which point it works perfectly.

> I've completely solved this problem by blacklisting web.archive.org in browser cookie blacklists. I haven't had it happen since then. As far as I'm concerned, the problem is diagnosed and just needs to be solved. At their end.

One of these modules' owners should update their modules to check if they are running as part of the ransomware, and kill the program if so. That would certainly be an interesting turn of events.

So as I read it this is ransomware that was built using nodejs... not a compromised npm package or anything like that. Is that right?

That's what I took away from the article as well. It's installed via a VBScript file.

Edit: I'm also not able to find any other record of it (yet). Everything links to the OP link or analysis on the OP link.

I wonder how long until instead of installing itself it finds and infects an existing Electron app?

Most languages, distros, large applications, etc have their own packaging system. Some are more laissez-faire than others.

Does someone know a good article from the POV of the maintainer of a packaging system ecosystem that describes the tradeoffs made by different approaches over the past ~30 years?

To be clear, as far as I can tell, the ransomware is built using nodejs. It is not a ransomware that's installed via a compromised package. Although if you happen to be a bad guy, it seems like building a quality bitcoin-related package, waiting until you have a big installed base, and then owning all your users, might be an effective way to set yourself up for life.

>as far as I can tell,the ransomware is built using nodejs

Oddly enough, that's what it is. It even drops a full 17MB copy of nodejs to run it and just renames the executable.

Node processes can also be renamed on the fly, process.name

I thought Bitcoin can't effectively be mined on CPUs anymore, only some AltCoins that are too difficult to compute with ASICs

I'm not talking about a miner. I'm talking about a wallet or some utility module. You'd wait until you have a big installed base then change your module to silently steal coinbase credentials. Wait a few weeks until you have enough of them and then own all the accounts at once. Something like that. The Bitcoin aspect of the module is just to target effectively.

Well, yes, but "effective" is context-dependent.

If you have a million computers mining for you, and you're not paying their electricity, it doesn't really matter how individually efficient they are.

There was a few articles about go's search for a new package system from 2018.

Edit: See https://blog.golang.org/versioning-proposal and related articles at the bottom.

Interestingly enough the JS source is not obfuscated, merely minified with no name mangling.

Count me in as being one who is disappointed that the code is not being made available. I know releasing it to the public is inherently dangerous, but, I can't help but to be curious as to how these programs work top to bottom.

https://send.firefox.com/download/29f34c9a6a4a30b6/#RBSP9jz2...

password hackernews. I've set it to the maximum option of 100 downloads so it won't last forerver but should last long enough.

"The sample received in our lab was vbs script which has multiple embedded js scripts. On execution, it creates a directory “GFp0JAk” at location “%userprofile%\AppData\Local\”."

Why is this even possible?

If applications can't write to the Application Data folder then what's the point of an application data folder?

> Why is this even possible?

Well they said "on execution" so that's what made it possible. Now if it could install to that location without being explicitly executed (say on download or via a browser bug) then THAT would be a much bigger deal.

It's not so much the "applications can write data to application data" as it is "application data is executable by default". It's simply a design choice from before security was important. Nobody would defend that design today and Microsoft recognized this when they created appx which separates installers, executable programs, and data into separate content types treated with separate security policy.

Can't everybody write to their own user's AppData folder?

Yes, but it's not granular per-application [i believe]. On an install script you can create folders in %localappdata% without needing elevated permissions meaning that %localappdata% and any files/folders you create are owned by the current user; unless a script does something with the file permissions, any other application can scan, access, and modify other applications (same goes for all of your user files but that's just par for the course for win32).

Reply on news.ycombinator.com