Are there any methods or standards to harden Javascript implementations to help reduce/remediate the the risks associated with Javascript malware like the Ransom32 or other types of Javascript attacks?


Alternative answers which may be helpful include any good guidelines on hardening all of the applications which implement javascript such as browsers or adobe reader that may be relevant to mitigating Javascript specific malware (Not looking for general browser hardening guidelines unless they have Javascript specific remediation steps).

Note: I'm asking this in the context of how to implement this for desktops across an organization.

  • @FiascoLabs I don't think Windows Script Host is involved in this particular malware. Any resources that says it is? Jun 20, 2016 at 17:58
  • @FiascoLabs Such malware definitely exists, but those links don't appear to describe Ransom32. Jun 20, 2016 at 18:05
  • Ok, sounds like there's no fix for it... you just gotta prevent it from installing in the first place. Jun 20, 2016 at 18:09
  • the "app" comes with its own Javascript implementation, so it doesn't matter what you harden on your box...
    – dandavis
    Jun 20, 2016 at 19:53

2 Answers 2


The most important thing to consider here is that this type of JavaScript malware does not run in a browser. It runs in a special runtime called NW.js which gives powerful NodeJS API's not found in a browser.

While NW.js shares many technologies with the Chromium browser, it is not a browser but a type of native wrapper for making desktop apps, and this type of malware would not run in a traditional browser which would never create the necessary API's for things like direct, un-prompted filesystem access. Therefore, browsers (and presumably Adobe Reader, even with a not-so-great track record) are already immune by design.

On the flip side, the main advantage to NW.js is that it makes these powerful API's available to JavaScript powered applications. This means that you can make desktop applications with traditional desktop application capabilities. The only way to limit this functionality would be to take away these advantages and cripple the wrapper completely.

In short, this isn't a new security risk. Running any desktop application carries the same risk, be it written in C++, JavaScript, etc. The only think new is that JavaScript has evolved to be the interpreted language of choice for many new things, and is now a common language outside a browser.

In fact, your link says it uses a self-extracting RAR file which means the user must run a .exe file. That .exe could be anything.

On a side note, we have actually already seen pure JavaScript malware for Windows targeting the Windows Script Host because .js files are executable on Windows by default (!). Normally these are just used to bypass malware filters and download more executable payloads when run.


This is not Javascript breaking out of a browser's vm/sandbox but rather an executable that runs with full local user privileges that happened to be written in Javascript...

There's nothing to harden as local Javascript app platforms like NW.js are designed to allow exactly that and like all other platform/frameworks they can be used for good as well as for evil.

Admittedly, malware like this are harder to detect as all the binary files are legit and probably signed by reputable sources. Fortunately, many anti-virus software are scanning all files instead of just excutable files, so they probably can still catch this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .