Slashdot Mirror


First Node.js-Powered Ransomware Discovered (softpedia.com)

An anonymous reader writes: A security researcher from Emsisoft has discovered a new ransomware family coded via NW.js (formerly Node-WebKit). Why is it unique? Because it is the first of its kind to use JavaScript for the ransomware's source code, it provides cross-OS support (we may see the first universal Windows-Linux-Mac ransomware in the future), and because the security researcher describes it as "successor of CryptoLocker" when it comes to encryption quality. The ransomware, Ransom32, is offered as a RaaS service on the Dark Web, only targets Windows machines in its first version, and is currently undecryptable.

7 of 69 comments (clear)

  1. Attack vector? by mark-t · · Score: 3, Interesting

    Specifically, what is the actual attack vector for this? All it seems like to me is that they've made a cross-platform trojan.... one that still needs to be explicitly executed by the end user. since the only self-executing js that I know of is within a web browser, and the javascript running inside of that can't even see the local filesystem, can it?

    1. Re:Attack vector? by dos1 · · Score: 2

      Download and run it. Just like lots of other trojans/ransomwares. It could have been written in Python, Ruby, Perl, whatever, there would be no difference. Someone just thought that the fact that it uses the same language that browsers happen to use for their scripting is somehow remarkable and news-worthy. It really isn't.

  2. How is it platform independent? by goombah99 · · Score: 3, Informative

    So it's installing a server for node JS. but that does not make it platform independent. the script side of it may be but not the backend and it has to install that too.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  3. Re:Pure HTML by Anonymous Coward · · Score: 2, Informative

    Node-webkit stuff will definitely NOT run inside a browser. That was the entire point of node-webkit. It's a node environment fused with a webkit environment.

    Which, editors, is not "node.js"; it's a fork.

  4. Re:So glad we "got rid of Flash" by dos1 · · Score: 3, Informative

    Okay, but how is that related? Using JavaScript with Node.js is no different than using Python with CPython, or any other interpreted language using their interpreter. The fact that browsers happen to use the same syntax for their in-page scripting doesn't mean anything here.

  5. I've seen this by JThundley · · Score: 5, Insightful

    I think I've seen this one first hand. It was emailed to the victim posing as a Firstname Lastname resume.zip, inside was Firstname Lastname resume.js. Inside the .js was what looked like base64 being encoded to something, probably downloading and running the actual exe.

    The biggest shock in all this is that Windows will execute a .js file when you double-click it. How fucking retarded is that? I'm looking at changing the default program for .js files to be notepad instead of the Windows Scripting Host.

  6. Re:A First for Cross-OS Support? by Junta · · Score: 2

    Note that in the debian.org set, Java won on cpu speed in one benchmark, lost on all in terms of resource utilization compared to C. So compared to C, it seems to back the assertion that Java on a JVM is disadvantaged cpu/memory wise compared to a compiled C application. Of course this is a selection of benchmarks that has had the world to think about it and probably does not represent what the average developer will achieve with the respective languages.

    Of course, there are a lot of languages whose runtime are as slow if not slower than Java, yet Java does continue to be the whipping boy for people wanting to talk about bad performance.

    The short of it is that in the real world, the differences in the languages pale in comparison to what the developer can do. On a typical application I've encountered, generally optimizations within the way the code runs can yield given the same runtime can see an order of magnitude difference without even thinking about the relative contribution of the runtime differences from porting to another language. So it's a fascinating academic discussion, but comfort with the languages is far more important in reality. Java has suffered in practice because it's where all the developers went to churn out their dubious code...

    --
    XML is like violence. If it doesn't solve the problem, use more.