Meet Ransom32: The First JavaScript ransomware

s.exe is a legit application. So I doubt anyone will detect it. But just out of curiosity, here are the results for all components contained inside the dropper:

https://www.virustotal.com/en/file/...ce5a842a5f7b2b8fa2e842a5/analysis/1451824329/
https://www.virustotal.com/en/file/...7f5aa0fefef0a095708c02dd/analysis/1451824340/
https://www.virustotal.com/en/file/...458cc39c56e74b9bed4efaee/analysis/1451824338/
https://www.virustotal.com/en/file/...05b5bf2f5575b0c0813c15e3/analysis/1451824350/
https://www.virustotal.com/en/file/...38cc850b0d9633767524fb7d/analysis/1451824358/
https://www.virustotal.com/en/file/...08eb894295812d778bc6349e/analysis/1451824372/
https://www.virustotal.com/en/file/...0f65889939323b223ee2944a/analysis/1451824388/

Also a complete dropper:

https://www.virustotal.com/en/file/...06ebc38c5f7de231c2c4b010/analysis/1451824450/

We have archive and PUP scanning disabled on VT. That's why it doesn't show up when scanning the complete dropper.

 

AVs have to switch gears to detect such malware faster we will see more like this in the future i guess.

Businesses will be targeted by this since all Business AVs except Emsisoft fail on this........

 

Thank you Fabian for those links.

 

True. What I was referring to was the use of NW.js in this WinRAR download.

One question I have is in your analysis of this malware, I assume the WinRAR download still had to be manually executed by the user; opening of an e-mail attachment, etc.?

 

That is the way a malware campaign affiliate gets the malware. How he distributes it is up to him. Exploit kits don't have file size limits. The imagination of the affiliate is the limit really.

 

Ahh ........, gotcha. Thanks. Also, appears the only way to detect "chrome.exe" or whatever name used is by signature?

 

The file itless can only be detected by Signature or Cloud.

BUT Emsisoft also blocks the behavior of it resulting in a behavior alert

Nice work Fabian

 

No. We detect it by behavior as well for example and I am sure others will as well.

 

Does this mean that the new "Document Protection" added to the behavior blocker actually detects the attempted encryption activity?

 

Yes. A couple of other rules match as well. It's a neat pretty firework of alerts actually. The document one is just the first.

 

Fantastic! Great to see a security vendor finally detecting this malaise at the appropriate target.

 

Good morning (or evening where you are), Fabian,

My comment wasn't meant to be a criticism, just an observation. I realize it is your company blog.

I didn't dismiss your analysis, just that it was not clear to me in your analysis what the attack method (delivery mechanism) is, which is my primary interest.

Subsequent posts here have cleared this up.

Thanks,

----
rich

 

After reading Fabian's comments and the blog post again, as bad as this is, the malware still uses the standard procedure of dropping an executable file in the Windows Temp folder. If execution in the Temp folder is blocked by ACLs and SRP or Applocker for non administrators, Ransom32 is stopped and is just an SFX file in the Temp folder. This assumes that you are using a LUA, of course.

 

This wouldn't help against TorrentLocker; no temp dirs. used with this one:

Files used by this infection are:

C:\ProgramData\<random>.exe
C:\ProgramData\<random>.html
C:\Users\All Users\<random>.exe
C:\Users\All Users\<random>.html

Registry keys used by this infection are:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\<random> C:\ProgramData\<random>.exe
HKCU\Software\<Random>

Ref.: http://www.bleepingcomputer.com/for...t-and-discussion-thread-cryptolocker-copycat/
​

Also have my eye on a new ransomware variant posted on bleepingcomputer.com that is attacking corp. servers and doesn't leave a trace of its activities.

 

Any and all user-writable directories should be protected by an anti-executable. The only concern I'd have from my limited pov are the fileless exploits, at least any that infect at that stage during the infection process.

 

More info on Ransom32; a bit more detail than the Emsisoft blog article: http://www.bleepingcomputer.com/new...s-the-first-ransomware-written-in-javascript/

 

Yes, indeed. Scroll down to the Whitelisting Bypasses section of this article: https://www.countercept.com/the-knowledge/whitelisting/

 

Yep, lots of different methods to get around it, although I'd be willing to bet properly configured and managed browser scripting control will go a long ways to defeating (not 100%) the exploits. Even just blocking ads and iframes is apparently decent defense against them.

 

Looks like new variant of Ransom32 was just submitted here:https://www.hybrid-analysis.com/sam...3ede50f65889939323b223ee2944a?environmentId=1

Looks like this might be a rootkit version; note the Z: drive reference. Warning: Don't click on the sample download unless you want to infect yourself .......................

 

Scratch this comment. Just realized Z: is the virtual drive they ran the malware from.

 

These are locked in my systems as well. The file system ACLs are set so read/write and execute are mutually exclusive regardless of where they are in the volume. SRP or Applocker, depending on the Windows version, is set to deny execution in those locations as well so there are two mechanisms in place to deny execution all of these folders. Write permission in the ProgramData folder is denied to non administrators as well so the only place the executable could be copied is in one of the subfolders of the Users directory. From there, it couldn't execute.

 

@Fabian Wosar

Got it, I just found the NW.js website. Kind of like py2exe for Javascript, I guess.

(Mind, I read "Javascript ransomware" and immediately thought "malicious web script with a sandbox escape.")

 

Interesting, thanks for the link.

 

Easy-to-use ransomware code discovered