[SI-LAB] #OpJerusalem 2019 – JCry ransomware is now infecting Windows users

Pierluigi Paganini March 06, 2019

Over the last few days, a new ransomware campaign infected several users around the world as part of the #OpJerusalem campaign.

SI-LAB analyzed this malware and noticed that it does not use sophisticated techniques. Criminals used UPX packer to protect malware code written in Go and a RSA public certificate is hardcoded inside malware to encrypt all user’s target files. This finding results in a simple “key” to encrypt all the infected victims. This means that a unique RSA private key can be used to decrypt all the files as well.

Jcry is a recent ransomware written in Go which increases its analysis. Criminals have been concerned about protecting their code, however the UPX packer can be easily overcome by allowing a more efficient threat analysis.

It’s also important to note that every time malware runs, a new unique key is generated. However, the RSA public key used to encrypt the target files is static and hardcoded inside ransomware.

By getting this private key, files of each infected users can be recovered – since the key to decrypt the files is also unique.

The new ransomware dubbed JCry (extension used to rename encrypted files .jcry) is part of the OpIsrael 2019 — an annual coordinated cyber attack against the Israeli government and private websites created with the stated goal of “erasing Israel from the Internet” in protest against the Israeli government’s conduct in the Israel-Palestine conflict.

Criminals have used common attack vectors in the past, such as website defacements and denial-of-service distributed attacks (DDoS). On April 7th, 2013, for instance, the most successful attack executed by Anonymous group using data leakage and DoS conditions against a huge number of Israeli websites was noted.

According to media (see this link), since the attack in 2013, the number of participants and supporters is decreasing.


Figure 1: #OpIsrael Participants statistics.

This time, a new attack is ongoing and is targeting private websites. The attacks happen one month before the common data of the campaign.

Last weekend, hundreds of popular Israeli websites were targeted by a cyber attack called #OpJerusalem. This attack has the goal of infecting Windows users with the JCry ransomware. In this case, the attack vector used to distribute the ransomware are defaced websites.

To carried out this attack, crooks modified the DNS record of a popular web accessibility plugin from nagich[.]com. When users access a website using that plugin, a malicious script is loaded instead of the legitimate plugin.

Ido Naor, Principal Security Researcher at Kaspersky Lab, was who share this threat on Saturday, March 2nd, at VirusBay.


“After they replaced the IP of the domain, they simply redirected the traffic to a page called update.html where a script was looking for the victim’s USER-AGENT. Once found, it was comparing parts of it with the string “Windows”. If it wasn’t Windows, the script would only show a defacement page. Else, a fake Adobe update was suppose to be served to the victim. Due to a fail in the code (the comparison if condition), the code was never able to reach the download link, so actually the attack was shooting blank.” – researcher says.

How ransomware is distributed

After the website is compromised, a script was placed to perform the next task:

  • If a javascript variable was equal to a specific string “Windows”, a malicious Adobe update message is triggered delivering the JCry ransomware.
  • Otherwise, a defacement page is displayed.

The Israeli website nagish[.]co[.]il was compromised and used in these attacks. Criminals left the following message: #OpJerusalem, Jerusalem is the capital of Palestine.

The source code of the webpage was published on GitHub and we can easily see a funny bug: the malware will never download because the printed message condition is wrong and always true.

(See code here).


Figure 2: Malicious code used in this campaign.

To lure the victims, the following image is presented with the message: “Your version of Adobe Flash Player is outdated – Update“. When the user clicks on Update, the malicious file is download.


Figure 3: When the user clicks on Update, the malicious file is download.


Figure 4: Malicious file “flashplayer_install.exe” is downloaded from hxxp://


If the browser user-agent used to access the page does not contain “Windows”, then the defacement message is presented and nothing else happens.

Figure 5: Defacement message when browser user-agent is not a Windows device.

After the download – Technical Analysis

SI-LAB analyzed this new ransomware in order to understand its behavior and techniques used by criminals.

If users download the exe file called flashplayer_install.exe, the infection process starts. As shown, the malware icon is the same used by common Adobe Flash Player executables, a trick used by crooks to lure victims.


Figure 6: Ransomware icon.

This first .exe is a dropper Winrar SFX (self-extracting archives). There are three archives inside it, namely:


Figure 7: Archives inside flashplayer_install.exe — the dropper.

Enc.exe is the first stage this ransomware. It is responsible to encrypted all the target files from user’s devices.

Dec.exe is the executable responsible to decrypt all files after the ransom payment. The last one, msg.vbs, has a simple message coded. Both two files (*.exe) are copied to the user’s Startup folder.

Figure 8: Files dropped.

As presented below, the ransomware was protected/packed by crooks. To do that, they used the UPX packer, which is easily unpacked.

Figure 9: UPX packer detected.

At a first glance, after unpacking the two files, all is unpacked and we can continue with malware analysis.


Figure 10:  Enc.exe — Nothing is packed now.

Deep dive in IDA

As shown, we can see that this malware was coded in Goland.

Figure 11: Goland was used to build the ransomware.

It’s important to note that Golang (Go) is a relatively new programming language, and it is not common to find malware written in it.

However, new variants written in Go are emerging, presenting a new big challenge to malware analysts. Applications written in Go are bulky and look much different under a debugger from those that are compiled in other languages, such as C/C++.

After some tricks, rename some functions to understand the malware was possible.

We can see that some cryptographic functions are declared — this is an important indicator that allows categorizing this threat as ransomware.

Figure 12: Cryptographic functions observed.

The malware has a built-in RSA public key used to encrypt all the target files.  JCry is designed to encrypt data and append filenames with “.jcry” extension (e.g., “file.jpg” is renamed to “file.jpg.jcry” and so on). Once data is encrypted, JCry opens a pop-up window and generates an html file (“JCRY_Note.html“) and drops a copy in every existing folder. We will observe this later.

The RSA public key used by ransomware every time to encrypt files is the following:

Figure 13: RSA public key used by ransomware to encrypt target files.

Since the key is hardcoded, we suspect that the private key may also be unique – since the public key is not variable. In this way, by obtaining a private key all the different files from each infected user’s can also be recovered.

In detail, the malware uses the crypto_cipher_NewGCM function to encrypt the target files. Next, the os__ptr_File_Write function is used to write the changes on disk (the file encrypted).

Figure 14: Functions used to encrypt target files.

The same function is used in the Dec.exe file to decrypt the files.

Figure 15: Functions used to decrypt target files.

Interesting that when analyzing the files, we were able to identify some indicators about the potential author(s) this ransomware (sh4dow).

Figure 16: Info about the malware author(s).

Executing the ransomware

At runtime four new threads are created responsible for encrypting all files on the infected user’s devices.

Figure 17: Threads created by ransomware to encrypt all target files and CPU performance.

After that, the files are encrypted and a new file extension is appended (.jcry).

Figure 18: .jcry extension is appended to the encrypted files.

After the encryption process has finished, a PowerShell is executed, and the executable Dec.exe is opened.

Figure: 19 Encryption process is terminated and the decryption file (Dec.exe) is opened.

The ransomware will also create a ransom note named JCRY_Note.html, which contains a victim’s unique key, a bitcoin address to send the $500 ransom payment, and a TOR site with the address http://kpx5wgcda7ezqjty.onion, which used to tell the attackers a payment has been made.

Figure 20: Ransomware note, bitcoin address, and victim unique key.

As can be seen below, when Dec.exe is executed via a Powershell process, the Enc.exe file is deleted.  Also, the file “PersonalKey.txt” is added, with the key to make the ransom payment.

Figure 21: Unique Personal Key generated by ransomware.

This activity can be observed on IDA as well.

Figure 22: Enc.exe file is deleted when Dec.exe file is executed.

Second round: Re-run the malware and validate if a new unique key is really generated

Re-run the malware, we see that another unique key is, in fact, generated. YES, different uniques keys are generated at each run (they are, in fact, unique).

Figure 23: Unique key generated during the second round.

Interesting, this time the malware was not able to eliminate the first stage (Enc.exe). More, the ransomware doesn’t start if PersonalKey.txt file is in the same folder. We need to delete it to launch the second round.

Figure 24: Access denied when malware tries to remove Enc.exe file (look at the left corner).

By accessing the TOR website, we observe that it contains a field that receives the address of the wallet and the unique key generated.

Figure 25: TOR website used by crooks to receive ransom payment.

As the 1FKWhzAeNhsZ2JQuWjWsEeryR6TqLkKFUt bitcoin address used for payment is the same for every victim, it would have been hard for the attackers to know who actually made the payment. It is not known whether the attackers would have provided a key after paying the ransom.

In addition, it’s possible to note that no payments were received for that bitcoin account at this time (March 5th, 2019)

Figure 26: Bitcoin wallet used by crooks.

Final Thoughts

Jcry is a recent ransomware written in Go which increases its analysis. Criminals have been concerned about protecting their code, however the UPX packer can be easily overcome by allowing a more efficient threat analysis.

It’s also important to note that every time malware runs, a new unique key is generated. However, the RSA public key used to encrypt the target files is static and hardcoded inside ransomware.

By getting this private key, files of each infected users can be recovered – since the key to decrypt the files is also unique.

Further details, including Indicators of Compromise are reported in the analysis published by Pedro Tavares:


About the author Pedro Tavares

Pedro Tavares is a professional in the field of information security working as an Ethical Hacker, Malware Analyst and also a Security Evangelist. He is also a founding member and Pentester at CSIRT.UBI and founder of the security computer blog seguranca–informatica.pt.

[adrotate banner=”9″] [adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – OpJerusalem, hacking)

[adrotate banner=”5″]

[adrotate banner=”13″]

you might also like

leave a comment