Cisco Blogs
Share
tweet

Ransomware on Steroids: Cryptowall 2.0

- January 6, 2015 - 28 Comments

This post was authored by Andrea Allievi and Earl Carter.

Ransomware holds a user’s data hostage. The latest ransomware variants encrypt the user’s data, thus making it unusable until a ransom is paid to retrieve the decryption key. The latest Cryptowall 2.0, utilizes TOR to obfuscate the command and control channel. The dropper utilizes multiple exploits to gain initial access and incorporates anti-vm and anti-emulation checks to hamper identification via sandboxes. The dropper and downloaded Cryptowall binary actually incorporate multiple levels of encryption. One of the most interesting aspects of this malware sample, however, is its capability to run 64 bit code directly from its 32 bit dropper. Under the Windows 32-bit on Windows 64-bit (WOW64) environment, it is indeed able to switch the processor execution context from 32 bit to 64 bit.

Initial Compromise

Cryptowall 2.0 can be delivered through multiple attack vectors, including email attachments, malicious pdf files and even various exploit kits. In the sample that we analyzed, the dropper utilized CVE-2013-3660, “Win32k.sys Elevation of Privilege Vulnerability” to achieve the initial privilege escalation on X86 based machines. This exploit works on 32 bit OSs starting beginning with Vista. The dropper even includes a 64-bit DLL that is able to trigger the exploit in all the vulnerable AMD64 Windows Systems.

Provided the anti-VM and anti-emulation checks pass, the Cryptowall malware is decrypted and installed on the system. Once the system is infected, the user is presented a message similar to Figure 1.

Figure 1

Figure 1. (Click to Enlarge)

Constructing the Unencrypted Cryptowall Binary

To construct the unencrypted Cryptowall 2.0 code, the dropper (with an md5 hash of F31B1C58E0110B407EF1F99F2C8A5A63 and a sha256 hash of 0483900fea2f27028ca0971729422b903c5e75542b93c9fa3377c5a201f7c31c) goes through multiple  stages of decryption. The main dropper is a C++ MFC application. The first-stage decryption code is located at “CMainFrame::OnCreate” in the MFC event handler. The handler builds the first-stage decryption code (at RVA +0xF3F0) and simple calls it.

The first-stage decryption code opens the original dropper PE, reads from it, and decrypts a big chunk of code (second-stage). Finally it transfer the execution to the second-stage located in the external buffer.

The Second stage is the last encryption layer code. It builds a simple Import Address Table (IAT), and implements multiple features. The most important one is the Anti-VM Check. The Anti-VM code is quite simple:

Figure 2: The CryptoWall simple Anti-VM check code

Figure 2: The CryptoWall simple Anti-VM check code. (Click to Enlarge.)

If no VM is detected, another “dropper“ process is spawned in a suspended state. The “ZwUnmapViewOfSection” API is used to unmap the original PE buffer. A new memory chunk is allocated and a new PE (extracted and decrypted from the “.data” section) is copied into its preferred base address. Then a new thread process is resumed with the following new context and the original process terminates:

  • EAX register is set to the new PE entry point address;
  • EBX register is set to a still unknown value: 7ffd8008

Installing Cryptowall on System

The “VirusExplorerMain” routine in the faked “explorer” process constructs the IAT and installs CryptoWall on the victim system. The first step is to create an executable with the name based on the computer’s MD5 hash. This executable is copied to the location specified by the “%APPDATA%” environment variable (“C:\Users\<Username>\AppData\Roaming”).

To maintain persistence, an auto-start registry value is added in:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Note: The RunOnce value is preceded by a (*) so that the process starts even in Safe Mode.

The same random executable is copied to the “Startup” folder of the Start Menu. The last duty of the faked “explorer” process is to disable all system protections. The following shell commands are executed:

  • vssadmin.exe Delete Shadows /All /Quiet
  • bcdedit.exe /set {default} recoveryenabled No
  • bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures

The following services are also disabled: Security Center, Windows Defender, Windows Update, Background Intelligent Transfer Service, ERSvc, Windows Error Reporting Service.

Finally, the original dropper file is terminated and the file is deleted. The Cryptowall PE is now injected into a faked “Svchost” process in the same way as the fake “explorer” process was created initially. The infection now continues in the faked “svchost” process.

The “VirusSvchostMain” function (RVA 0x418C70) is the main infection routine. It constructs the virus IAT (importing functions from the following modules: ntdll, kernel32, advapi32, user32, wininet, ole32, gdi32), checks whether the installation is done, and creates the main Cryptowall event. It then creates the main Cryptowall Thread and tries to download the TOR client used for communication from one of the following URLs:

cryptowall-urls

If it succeeds in downloading the update file, it executes directly. The downloaded binary is an executable that is encrypted 3 times with a simple algorithm. After decryption, a clean PE file is extracted and launched. This PE file is peculiar because it has all its normal headers (DOS header, NT header, IAT, EAT, …) stripped. Its IAT and “.data” section reside in another big memory buffer. The decryption code deals with the correct linking and relocation.

This clean PE is actually the Cryptowall TOR communication module. It implements a complete TOR Client that it utilizes for Command & Control communication. The TOR URLs used by the sample we analyzed were:

  • crptarv4hcu24ijv.onion
  • crptbfoi5i54ubez.onion
  • crptcj7wd4oaafdl.onion

Using hardcoded IP address in the PE, the malware connects to the TOR Server with an encrypted SSL connection on port 443 or 9090. After successfully connecting, it starts to generate the Cryptowall domain names using a customized Domain Generation Algorithm (DGA). The algorithm is located at offset + 0x2E9FC.

Figure 3: The code of the DGA algorithm in the TOR client

Figure 3: The code of the DGA algorithm in the TOR client

If the encrypted connection goes well, the communication with the Cryptowall Command & Control server will take places; otherwise the main thread sleeps for a random number of seconds and then retries with a new generated server name.

Each of the many SSL connections Cryptowall 2.0 establishes uses random server names in the certificates. However, the client certificates share commonalities that are unique enough to make it possible to detect these client connections outbound. Cryptowall 2.0 makes many, many requests once installed.

Initially Cryptowall 2.0 attempts to idenitfy the outside address for the network the system is operating on using the “GetExternalIpAddr” function. It accomplishes this by communicating with one of the following addresses:

  • http://wtfismyip.com/text
  • http://ip-addr.es
  • http://myexternalip.com/raw
  • http://curlmyip.com

It starts with wtfismyip.com and stops after the first successful reply is received. In most situations, this means that it will end up only going to wtfismyip.com (since it is the first entry in the list). Although this is a fairly generic request, this shouldn’t be a very common occurrence in an enterprise network and can serve as a potential network indicator of this malware.

Another interesting aspect of the sample that we analyzed is that includes some 64 bit code (and an exploit DLL) directly in its main 32-bit executable. Although the main module is running in 32-bit mode, it is capable of executing  all the 64-bit functions it needs. It accomplishes this by performing a direct Processor execution context switch. The code pushes two 32-bit values on the stack: the target offset (only the low part) of the 64-bit function offset and a 64-bit selector.

push <32Bit Selector>
push <32Bit Low DWORD address>
retf

It finally performs a FAR RET (opcode 0xCB). As the Intel manuals say, this kind of opcode executes a “Far return”: a return to a calling procedure located in a different segment than the current code segment. The target code segment is a 64-bit one, and as result the processor switches the execution context. To return to 32-bit mode the code reverses this process:

call $+5                ; This will push the 64-bit return address on the stack
mov dword ptr [esp+4], <32Bit Selector>     ; The same as PUSH <32bit value>, keep in mind
mov dword ptr [esp], <32Bit Address>     ; that all values are 8 byte wide in AMD64 mode
retf

This mixing between 64-bit code and the 32-bit main executable is even difficult for IDA to disassemble. FIgure 2 shows a dump of a Windows 7/8 64 bit Global Descriptor Table (GDT):

Figure 4: A dump of the Global Descriptor Table of a 64-bit System

Figure 4: A dump of the Global Descriptor Table of a 64-bit System

As the reader can see, the descriptor 0x20 and the descriptor 0x30 are the Ring 3 code segments that describe the entire user-mode address space, one for 32 bit and one for 64 bit. Cryptowall utilizes the proper selectors for these two segment descriptors and switches between these the two execution modes during its operation.

We were able to reverse this process and reconstruct the assembly language code (shown in Figure 3) that performs this switching between 32 & 64 bit by pushing the correct value before executing the far return instruction.

Figure 5: Switching Between 32 &amp; 64 bit Modes. (Click to Enlarge)

Figure 5: Switching Between 32 & 64 bit Modes. (Click to Enlarge)

Summary

Ransomware is a growing threat to computer users. Variants continue to evolve in functionality and evasive capability. Just getting these complex samples to run in a sandbox can be challenging, making analysis more complicated and involved. Constant research is necessary to develop updated signatures and rules to combat these constant attacks.

Identifying and stopping these new complex variants requires a layered security approach. Breaking any step in the attack chain will successfully prevent this attack. Therefore, blocking the initial phishing emails, blocking network connections to known malicious content, as well as stopping malicious process activity are critical to combating ransomware and preventing it from holding your data hostage.

Protecting Users Against These Threats

coveragetableAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites, including the downloading of the malware downloaded during these attacks.

The Network Security protection of IPS and NGFW have up-to-date signatures to detect malicious network activity by threat actors. ESA can block phishing emails sent by threat actors as part of this attack.

 

 

 

Tags:
Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

28 Comments

  1. A good article on a growing threat. Very detailed about the vulnerabilities it uses to gain access but it left out the solution or what should be done if your information is held ransom. Otherwise an enjoyable reading on how ransomware is implemented, specifically cryptowall 2.0

    • The solution is reimage/wipe and reinstall. What to do if it's held ransom is hope you have external backups for important documents/files. What NOT to do under any circumstance is pay the ransom. That only enables and encourages this sort of activity.

  2. Great analisys, im smashing how malware is growing, this battle never stop..

  3. If I understand the anti-VM correctly, if it detects that it is run in a VM it will not continue to decrypt the next stages which in essence means that it will not start encrypting files. If the above is correct you could then mitigate the risk a little bit by having a dummy-executable which is named VBoxService.exe or vmtoolsd.exe ?

    • Yes Rocky, in theory line you can do that... It should let the dropper not executing... Thanks to all for the compliments! Very appreciated...

      • Excellent article, your reply explains a lot of the english! lol

    • "could then mitigate the risk a little bit by having a dummy-executable which is named VBoxService.exe or vmtoolsd.exe". No as it's checking the process name of the file running it, not just any random process.

      • It can't check a process running outside the VM on the host unless they break out of the VM (which isn't a simple task). In other words, what the code doesn't do is checking the filename of the process running it, what it does do is to iterate through all current running processes on the OS to see if there are any integration services for a guest OS running.

  4. Great analysis of Cryptowall 2.0. Thanks!

  5. I wonder if blocking the URL's of the Tor client download sites will block completion of the code execution. A simple addition of the list to your router block list and to your PC;s hosts file may be enough to stop an infection from dropping it's encryption payload. Prevention is worth a pound of cure. Still SOL if you already have it.

    • But if it doesn't stop it, and it can't communicate with the server, you just lost all hope of getting back any files that weren't backed up.

      • With this type of malware or wiper malware we recently blogged about backups in accordance to industry best practices really are your best bet. The good thing is the same best practices can help protect against both types of threats and more.

  6. Excellent analysis

  7. If i want to bypass the anti-vm check, can i run a virtualbox machine without the guest addition, will it work ?

  8. Has it occurred to anyone to "tak" on feedback software, hidden tapeworm, to a randsom payment, feedback location and account info, these thieves must have their pc's notify them of received payment, and wipe the source drive clean-or seriously mess with their data base. It may sound like "Star Wars ", but it can be done: probably even by the Genius that authored the above synopsis.

  9. So if I understand correctly another preventative measure is simply always get online in a VM, since it won't install beiieving that we are an anslysis effort? Great analysis on a sophisticated product of an evil genius - The war is on!

  10. How bout providing the md5 of the sample or something, huh?

    • We have updated the post to include the md5 and sha256 hash of the sample.

      • Thank you

  11. Entry of the tor download sites in the lmhosts file is a simple and great way to break process... Thank you so much for this perfect analysis and making it available on this blog

  12. Good analysis. But I have a few comments: Running 64 Bit Code in 32 Bit is nothing new, haven't you heard of the heaven's gate technique (link: http://spth.virii.lu/v1/articles/HEAVEN.TXT)? And the process injection technique is also old, its also known as RunPE. It will simple unmap the memory of the other process and inject a new process there and patch the context of the thread. The unknown value of EBX (which is in our case 0x7ffd8008) is just a pointer to the PEB structure (process environment block). That's because when you create a new suspended process, EBX contains the pointer to the PEB.

    • Yes, we haven't said that it is a brand-new technology. We have highlighted how this technology is used by a malware for the first time (or at least based on what I have analysed in my like). The process injection technique is absolutely not new. I agree, nobody has said the opposite. The important feature of this dropper is that it is able to use the TOR network to communicate with the C&C and its ability to switch the processor execution modes. Personally, I didn't know the existence of that document (heaven’s gate technique). Thanks for the signal. Andrea

  13. Can we get snort rule SID's?

    • The Snort SID's are 32521 & 31223. For the most up-to-date information, you can search using Defense Center or searching for "Cryptowall 2.0" on snort.org.

  14. Nice descriptive article great information thank you.

  15. Wonderful analysis and nicely written.Thank You.

  16. Awesome Post.

  17. Nice descriptive post.Thank You.

Share
tweet