Guest blog: Nemucod ransomware analysis

Posted by    on   Sep 2, 2016

In the run up to VB2016, we invited the sponsors of the conference to write guest posts for our blog. In the third of this series, Webroot's Jesse Lopez writes about the Nemucod ransomware.

Note: some security vendors refer to the downloader component alone (which has been seen to download other kinds of malware as well) as 'Nemucod'. This analysis focuses on both the downloader and the ransomware.


Nemucod is a piece of ransomware that changes file names to *.crypted. While it's not a brand new variant, a lot has changed in the last few months, and different methods have been used, but one thing has remained constant: it is deployed via bogus shipping invoice spam messages.

The JavaScript initially received in a spam email downloads malware and encryption components stored on compromised websites. Because this ransomware is written in a scripting language, it's easy to modify and re-deploy, and in most cases, it has bypassed anti-virus and spam protection. However, a flaw has been found in the encryption routine, which allows victims to recover their files.

  • January 2016: Nemucod changes file names to '.crypted', but does not actually encrypt them.
  • March 2016: Adds XOR encryption using a 255-byte key contained in a downloaded executable. This downloaded executable encrypts the first 2048 bytes of a file.
  • April 2016: 7-Zip is used instead, which creates an archive to password-protect files.
  • April 2016: Instead of a hard-coded key, the JavaScript generates a key and passes it as an argument to the downloaded executable and performs the encryption of the first 1024 bytes of each targeted file.
  • May 2016: A small change is added to the previous build, which encrypts 2048 bytes instead of 1024 bytes.
  • June – August 2016: A PHP script is used along with a PHP interpreter to encrypt the first 1024 bytes of a file.

The following is an example of an email used to distribute Nemucod:


After opening the email attachment, you can see that the file located inside is a JavaScript file cleverly disguised as a .doc. The file appears to be a .doc for users with the folder option setting 'hide extensions for known file types' enabled:


JavaScript analysis

When the sample is first opened, it is heavily obfuscated; this is done by design as a means to thwart AV analysis and static detection:


After de-obfuscating the script, I found that several compromised domains are used to store multiple files for use later on in the execution routine. Of the downloaded files, we can see that the first two (a1.exe and a2.exe) are designed as backdoors to the system. a1.exe is usually W32.Kovter and a2.exe is usually W32.Boaxxe. Since PHP is not installed natively on the Windows OS, the third and fourth files to be downloaded (a.exe and php4ts.dll) are part of a portable PHP interpreter, which allows the ransomware (a.php – the fifth file to be downloaded) to run.



Analysis of a.php

At first, we saw several samples of a.php written in plain text without obfuscation, but the developers soon changed this to thwart static detection techniques. The obfuscation techniques below use chr() to encode each as a number specified in ASCII, while also using array() to store the php script in a list of array values.

Examples of obfuscated ransomware variants



To de-obfuscate this, I converted all of the chr values to ASCII characters and finally decoded base64 stored to get the original script.



To de-obfuscate this, I echoed the output of implode for all of the arrays (and removed eval), using the following at the end of the script:

;echo implode($f,"); ?>




The PHP script first uses 'set_time_limit(0);' to keep the interpreter running.

A recursive TREE function is then used with preg_match to match folders:


If a match is found, the script opens the directory and checks for more directories using is_dir; if a directory is found, it runs TREE again, which continues the loop to check whether the object is a folder or a file.

Once a file is found, it uses preg_match again to match its file extension:


Once a file matching the file extensions above is found, it stores that file name and path as the variable '$fp' and a new variable, '$x', is made, which uses the function fread.

fread() reads up to length bytes from the file pointer referenced by handle.

After reading the first 1024 bytes of a file, a for loop is used with strlen and the variable $k (a base64 string) to encrypt the files.



Latest posts:

The road to IPv6 is generally smooth but contains a few potholes

Most of the switch from IPv4 to IPv6 will happen seamlessly. But we cannot assume it won't introduce new security issues.

New paper: Powering the distribution of Tesla stealer with PowerShell and VBA macros

Since their return four years ago, Office macros have been one of the most common ways to spread malware. Today, we publish a research paper which looks in detail at a campaign in which VBA macros are used to execute PowerShell code, which in turn…

VB2017 paper: Android reverse engineering tools: not the usual suspects

Within a few years, Android malware has grown from a relatively small threat to a huge problem involving more than three million new malware samples a year. Axelle Apvrille, one of the world's leading Android malware researchers, will deliver a…

Patch early, patch often, but don't blindly trust every 'patch'

Compromised websites are being used to serve fake Flash Player uploads that come with a malicious payload.

Virus Bulletin at RSA

Next week, VB Editor Martijn Grooten will be at the RSA Conference in San Francisco.