Over the last few months there has been a massive outbreak of the Ransomware CryptoLocker.  CryptoLocker is malware that first silently encrypts a user’s files and then requires the user pay a ransom to obtain the encryption key needed for decrypting the files.  CryptoLocker “Racketeer” (details about the name “Racketeer” at the end of the post) has been distributed through fake Energy Australia electricity bills. The phishing emails look very authentic, making them a powerful tool for delivering the malicious software.  On May 30th 2014, Energy Australia published a warning “New email scam reported” with an example of the hoax email.

What does an infected machine look like?

After tricking a user into running the malicious executable, a scary message shows up on the desktop:

CryptoLocker Message

 

Introduction

A few days ago I managed to track down a sample of “Racketeer”, so I ran it through our Vinsula Execution Engine (VEE) to find out what it does and how it works. Credit for providing the link to the malicious website goes to Ryan Dowd.

After running the malicious executable through the Vinsula Execution Engine to analyze its behavior, I discovered that the “Racketeer” CryptoLocker malware is very different from the notorious CryptoLocker linked to Gameover Zeus malware. A week ago, our colleagues from Sophos published a great write-up on CryptoLocker/Gameover malware – “Has CryptoLocker been cracked? Is Gameover over?”

Similar to CryptoLocker/Gameover malware, CryptoLocker “Racketeer” also uses public-key cryptography. Once the malware is launched on user’s machine, the attacker uses a symmetric session key to encrypt the user’s files utilizing the AES algorithm. In this case, the same symmetric session key can be used to encrypt and decrypt the user’s files. Next, the attacker uses a public key to encrypt the session key and then removes the unencrypted symmetric session key. Decrypting the symmetric session key–which is required for decrypting user’s files–is only possible using the private key that corresponds to the public key used for encryption of the symmetric session key.  So the crooks encrypt the session key with the public key and require the user to buy the private key in order to decrypt the session key needed to decrypt the user’s files.

So, what makes CryptoLocker “Racketeer” so different from other CryptoLocker variants?  Unlike CryptoLocker/Gameover malware, which generates the RSA key pair on the CryptoLocker servers, CryptoLocker “Racketeer” generates the RSA key pair locally on the infected machine. This means that the user’s machine does not need to be connected to Internet for CryptoLocker “Racketeer” to encrypt user’s files.

Attack Overview

The diagram below highlights the key elements of the attack.  In essence, the targeted user receives a phishing email addressed to “Dear Valued Customer”. The recipient is tricked into clicking on the link, ostensibly to view the details of the Energy Australia bill. Next, the browser takes the user to a very realistic-looking website. The web page asks the user to enter a Captcha in order to download the “bill”.  Next, the user unzips the malicious file packed as a ZIP file and extracts the malware. Once the user clicks on the malware, it encrypts the user’s files.

 

2014-06-08-CryptoLocker Racketeer

Here are the hashes of the binary bill_903440.exe:

  • MD5: 1877882082af86f024994844d86e3522
  • SHA1: a1224ff6f081143c0bda16e343fd2d94ba75aa10

CryptoLocker “Racketeer” malware has been hosted and available for download from the phishing Website energyask[dot]com. As of today, June 9th, 2014, this site is not responding, so I assume that last night it was shut down. That said, I expect the crooks will simply move the hosting to a different domain name and continue the operation.

Once launched the malware sends two HTTP POST requests to hxxps://royalgourp[dot]org/gate[dot]php.

Security manager Aaron Bailey from the Australian firm The Missing Link, told Fairfax Media that maybe 30 or 40 single recipients and very senior contacts in each company were sent a fake Energy Australia bill.

Attack steps

After tricking the user to click on the phishing email, the browser opens up and navigates to a link on the phishing Website energyask[dot]com.

Phishing Website

The user is prompted to enter the characters from the fake Captcha. Having a Captcha human validation technique creates a very deceiving impression for the user that he/she is interacting with the actual Energy Australia’s Website. It also prevents any automated sandbox systems from examining the malicious link. As an additional–and particularly deceptive–step, the crooks have implemented logic on the malicious Web server that redirects users navigating to energyask[dot]com to the legitimate Energy Australia Website – http://www.energyaustralia.com.au/

After entering the characters in the Captcha box and submitting the form, the user is presented with the following web page where there is a button that allows downloading the fake bill.

Phishing site

Once the malware ZIP is downloaded, the user is first tricked into saving and unzipping the file and then into clicking on the executable, which appears to be a normal PDF file (if the user’s configuration is set up not to display file extensions).

Fake PDF

 

It takes a few seconds after clicking on the malicious fake PDF for the user to see the following message:

Your Computer is Hacked!

All files that have been encrypted appear under the same name with “.encrypted” suffix. A file with name “PLEASE_READ.txt” is copied to all folders where the malware has encrypted files. The file has the same content as the text on the screen above.

 

A few words about browser redirect (HTTP 302) and Referer header

As mentioned above, the attackers have implemented a browser redirect technique to ensure that curious users, perhaps suspecting fraud, who enter http://www.energyask[dot]com in their browser are automatically redirected to the legitimate Energy Australia website. That prompted me to find out if the Energy Australia website was failing to check the “Referer” (per RFC, we spell the Referer with one ‘r’) HTTP header, thus lacking a control for preventing malicious Websites redirecting to real Energy Australia Website. I was surprised to find out that the browser was actually not sending the “Referer” header as a result of HTTP 302 response sent by the malicious Web server.

We are aware of different mechanisms for stripping the “Referer” header while redirecting, and there are plenty of examples. However in our case where we have a simple redirect from one HTTP session to another HTTP session that didn’t make much sense. We are no longer able to investigate this as the malicious Web server which the domain name energyask[dot]com points to is now down.

The following screenshot provide details captured with Fiddler for the request to the malicious website and the HTTP 302 response that instructs the browser to send a request to Energy Australia Website – energyaustralia.com.au

HTTP Redirect

On the next screenshot the request doesn’t provide the expected Referer HTTP header showing that the redirect came from energyask[dot]com

Browser Redirect

Behavioral Analysis

Our first step was to run the fake CryptoLocker “Racketeer” through our Vinsula Execution Engine to find out just what it does.  The process tree below as reported by our engine allows us to visually present the parent/child relationship between all the processes and their command lines related to the execution for this specific malware.

This malware doesn’t seem to be very “chatty” as no files are downloaded/dropped from the attacker’s servers.

+ bill_903440.exe [Process Id: 2860]
  + bill_903440.exe [Process Id: 1644]
    + explorer.exe [Process Id: 3404] "C:\Windows\explorer.exe"
      + vssadmin.exe [Process Id: 3764] "vssadmin.exe Delete Shadows /All /Quiet"

As we can see in the cascade tree above, the main malware launches a copy of itself. The purpose of the second instance is to make debugging of the malware more difficult. The second instance is used as hollow process where the first instance injects code.

The second instance of bill_903440.exe launches Windows explorer, explorer.exe, after which it injects a unencrypted version of its code into Windows explorer. The goal of the authors is to hide their traces and carry out the attack from within a known Windows process – explorer.exe.

Depending on whether the executable bill_903440.exe is launched with admin elevated privileges, the newly launched copy of Windows Explorer (explorer.exe) copies the main malware binary to “C:\Windows” or to “C:\ProgramData” and stores the executable file using a random name. The infected Windows Explorer also registers the newly created random name binary as run at startup by modifying following registry setting – SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Here are the related events registered by the Vinsula Execution Engine:

+ explorer.exe [Process Id: 3404] 
    Action:NtSetValueKey Key:  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run 
                         Value:ohabuvuq New Value:C:\Windows\elavawox.exe
    Event:Create File[C:\Windows\elavawox.exe]
    Event:Write File[C:\Windows\elavawox.exe]

CryptoLocker “Racketeer” clearly implements an innovative approach to ensure that the user is left with no local backups on shadow volumes by launching the command “vssadmin.exe Delete Shadows /All /Quiet” from within the Explorer.exe instance that is in control of the attacker. See Microsoft TechNet article discussing “Vssadmin delete shadows”. On June 3rd, 2014, the Australian Government published a warning “Fake electricity bills target Australians, links to Cryptolocker ransomware: SSO Alert Priority High”. This page has a reference to a CERT Australia advisory document that recommends activating volume shadow copy service as a way to protect user’s data. With this version of CryptoLocker “Racketeer”, the malware would be able to destroy any backup stored using volume shadow copy service.

It is important to note that the image bill_903440.exe is packed and the code is encrypted in order to prevent static code analysis.

The attackers have gone to some lengths to hide their intentions and the libraries and APIs the malware uses. The following two screenshots show the unencrypted piece of the malware, where we can see very limited information about the imported libraries and APIs. BTW, PeStudio is a fantastic tool and helps a lot in static analysis!

Imported Libraries

Imported APIs

The Vinsula report also reveals that there is complex logic implemented in the main malware to isolate any attempts to reverse the binary. The following section covers process modification and remote code injection related events section from the report:

+ bill_903440.exe [Process Id: 2860] [Parent Id: 2036] 
    API:NtSetContextThread Target:bill_903440.exe Target Process Id:[1644] 
    API:NtWriteVirtualMemory Target:bill_903440.exe Target Process Id:[1644] 
  + bill_903440.exe [Process Id: 1644] [Parent Id: 2860] 
      API:NtSetContextThread Target:explorer.exe Target Process Id:[3404] 
      API:NtWriteVirtualMemory Target:explorer.exe Target Process Id:[3404]

Now it’s time to investigate further exactly what code is being injected into the second instance of  bill_903440.exe [Process Id: 1644] and the instance of Windows Explorer launched by the malware, explorer.exe Process Id:[3404].

There are different methods that facilitate execution of remote code–attaching a debugger, CreateRemoteThread() API, and SetWindowsHookEx() API, to name a few. One of the options for executing remote code is through hijacking an existing thread using SetThreadContext() API (or its corresponding native API – NtSetContextThread) and controlling the instruction pointer.

The reason the second instance of bill_903440.exe [Process Id: 1644] launches a new instance of Windows explorer Process Id:[3404] is that as a parent process of explorer.exe, it wouldn’t require holding of SE_DEBUG privilege to inject the code into the child process. Normally SE_DEBUG is only granted to members of the local admin group. The handle to the process where the code is being injected is returned by CreateProcessW() API, which the malware uses to launch its second instance and the new instance of Windows Explorer.

Another API that would need more attention is WriteProcessMemory() (or the corresponding native API – NtWriteVirtualMemory). CryptoLocker “Racketeer” executes NtWriteVirtualMemory to write the malicious payload to the memory of its child processes. An option for identifying and extracting the malicious code is to intercept WriteProcessMemory (or NtWriteVirtualMemory), dump the data buffer, and investigate it. Note that there are some legitimate calls to WriteProcessMemory() between processes in Windows, and data passed through WriteProcessMemory isn’t necessarily malicious. Our goal is to isolate the malicious pieces and reverse engineer them.

After dumping the binary content of the data that is injected into the second instance of bill_903440.exe [Process Id: 1644] and the instance of Windows Explorer, we find some data worthy of investigation. In particular, there is a buffer written to the Windows Explorer instance that is in fact an executable.

This executable reveals all APIs that it uses. Here is a short list of what I think are some of the important APIs for the malware to take control of a user’s machine:

kernel32.dll
	Wow64RevertWow64FsRedirection
	Wow64DisableWow64FsRedirection
	LoadLibraryA
	GetProcAddress
ntdll.dll
	NtWriteFile
	NtSetInformationFile
	NtQueryInformationFile
	NtCreateFile
	NtDeleteFile
	NtReadFile
	NtQuerySystemInformation
	RtlFreeHeap
	RtlAllocateHeap
	RtlDosPathNameToNtPathName_U
	NtClose
WININET.dll
	InternetOpenW
	InternetQueryOptionW
	InternetCrackUrlW
	InternetConnectW
	InternetSetOptionA
	HttpSendRequestW
	HttpQueryInfoW
	HttpOpenRequestW
	InternetCloseHandle
	InternetQueryOptionA

This binary gets implanted into Explorer and it implements most important functions of the malware – the RSA key pair generation, the file encryption process, storing the configuration into registry, and displaying the warning message “Your system is hacked!” to the user. All of these different aspects of the malware are intended to run from within the Explorer.exe context.

Based on the Vinsula reports, we can confirm that all the malicious functions described above–including the code that encrypts user’s files–run in the context of the newly launched Explorer.exe. Here is a short segment of the report that covers the file encryption and renaming process:

 + explorer.exe [Process Id: 3404] 
	 Event:Open File[C:\Python27\DLLs\_bsddb.pyd]
	 Event:Read File[C:\Python27\DLLs\_bsddb.pyd]
	 Event:Rename File[C:\Python27\DLLs\_bsddb.pyd] 
	       New File[C:\Python27\DLLs\_bsddb.pyd.encrypted]
	 Event:Write File[C:\Python27\DLLs\_bsddb.pyd]
	 Event:Open File[C:\Python27\DLLs\_ctypes.pyd]
	 Event:Read File[C:\Python27\DLLs\_ctypes.pyd]
	 Event:Rename File[C:\Python27\DLLs\_ctypes.pyd] 
	       New File[C:\Python27\DLLs\_ctypes.pyd.encrypted]
	 Event:Write File[C:\Python27\DLLs\_ctypes.pyd]
	 Event:Open File[C:\Python27\DLLs\_ctypes_test.pyd]
	 Event:Read File[C:\Python27\DLLs\_ctypes_test.pyd]
	 Event:Rename File[C:\Python27\DLLs\_ctypes_test.pyd] 
	       New File[C:\Python27\DLLs\_ctypes_test.pyd.encrypted]
	 Event:Write File[C:\Python27\DLLs\_ctypes_test.pyd]

To avoid anti-malware tools, the injected code into Explorer.exe code uses GetProcAddress() API to dynamically retrieve the address of the exported functions it uses.

Where is the RSA key-pair being created?

As mentioned previously, CryptoLocker “Racketeer” doesn’t require an Internet connection; if the user is tricked into launching it, the malware encrypts user files. It’s obvious that since CryptoLocker “Racketeer” doesn’t need to call home to get the public key, the RSA key-pair has to be generated locally. The code that creates the RSA key-pair runs in the context of that same newly created Explorer.exe. Explorer.exe is a shell that links with some of the critical security infrastructure libraries and also provides the user interface for the logged-on user.

After debugging the malicious code, we’ve narrowed this down to the Microsoft Windows Cryptographic Primitives Library (bcrypt.dll). Cryptography API: Next Generation (CNG)  exposes BCryptGenerateKeyPair function that creates an empty public/private key pair. After RSA key pair has been created by using this function, there are a few other functions that would need to be executed, but that would allow an attacker to execute code that creates the RSA key pair.

After encrypting the files, the attacker would need to preserve the private key in some obfuscated (or encrypted) form, so later that can be retrieved and send back to the C2 server. At this point of time, it is not quite clear how the process of uploading the private key is triggered. It is likely to have some hidden functionality that would be activated by the user once he/she contacts the attacker to get instructions about payment.

As the private key is stored locally on user’s machine, it is just matter of time for the remaining code to be reverse engineered to find the way of extracting the actual private key and decrypting the session key. We will continue working in this direction.

Configuration

CryptoLocker “Racketeer” stores its configuration into registry under the registry key “HKCU\Software\Bit Torrent Application\Configuration”. Vinsula Execution Engine captures all the data that gets stored in registry and allows us to inspect the values stored there. CryptoLocker “Racketeer”  stores six values, and most seem easy to deobfuscate. Following screenshot shows CryptoLocker’s configuration database.

Configuration Database

Without going into details, these are some of the interesting findings:

The value of the second setting “01000000” is actually the malicious executable delivered to the user.

Windows 7 32bit (Honeypot) - Folio-2014-06-09-19-05-35

 The values of the third “02000000” setting are the location for the copy of the malware that is registered to run at startup.

Run at startupThe fourth settings is the location of the Warning wallpaper, and the fifth one is the encrypted with the public key session key.

“!!!Your system is hacked!!!” window

This window is part of the code that is injected into Explorer.exe. The user cannot close it, but can minimize it. Here is the full text that appears there:

All your files was encrypted with CryptoLocker!

This means that without a decryption key the recovery of your files is not possible.
If your files have a value to you and you are willing to pay me for the decryption key please contact me: decrypt-request@mail.ua

You have 3 days to pay for my services. After this period, you will lose all your files.

Anti-virus software can remove Cryptolocker, but can not decrypt your files. The only way to recover your files - is to pay for the decryption key.

Information for IT-specialists:

Data was encrypted with AES (Rijndael) algorithm with the session key length of 256 bits. Session key is encrypted with RSA (2048 bits) algorithm. Public-key is enclosed into CryptoLocker. Private-key for decryption of the session key is stored only in my database.
To crack this key, you will need more than a million years time.
---- Encrypted Session Key Begin ----
---- Encrypted Session Key End ----

Network activity

CryptoLocker “Racketeer” injects code into the newly started Windows Explorer that is responsible for calling back home to hxxps://royalgourp.org/gate.php (IP 151.248.118.193). Notice the malware uses HTTPS to post information to the C2 server. All the interactions with the malicious server are utilizing the Windows Internet (WinInet) application programming interface.

+ explorer.exe [Process Id: 3404] [Parent Id: 1644]
  =>  TCP IPv4 UNKNOWN 100.200.100.200:1069 <==> 151.248.118.193:443
  =>  TCP IPv4 send 100.200.100.200:1069  ==> 151.248.118.193:443
  =>  TCP IPv4 recv 100.200.100.200:1069 <==  151.248.118.193:443
  =>  TCP IPv4 UNKNOWN 100.200.100.200:1070 <==> 82.209.177.136:80
  =>  TCP IPv4 send 100.200.100.200:1070  ==> 82.209.177.136:80
  =>  TCP IPv4 recv 100.200.100.200:1070 <==  82.209.177.136:80
  =>  TCP IPv4 UNKNOWN 100.200.100.200:1071 <==> 151.248.118.193:443
  =>  TCP IPv4 UNKNOWN 100.200.100.200:1072 <==> 82.209.177.136:80
  =>  TCP IPv4 send 100.200.100.200:1071  ==> 151.248.118.193:443
  =>  TCP IPv4 recv 100.200.100.200:1071 <==  151.248.118.193:443
  =>  TCP IPv4 send 100.200.100.200:1072  ==> 82.209.177.136:80
  =>  TCP IPv4 recv 100.200.100.200:1072 <==  82.209.177.136:80

The following screenshots show the two HTTPS POST request sent to the C2 server. First request posts 4 bytes 0x00 and the second (and what seems to be the last) request posts 4 bytes 0x01. It looks like the second request is sent after the files have been encrypted and very likely to inform the attacker about a successfully completed infection. This is what the first HTTPS POST request looks like in Fiddler:

HTTPS request

And here is the second HTTP POST request:

HTTPS Request

 Here is the geographical location report for royalgourp.org (151.248.118.193). The C2 server appears to be in the Russian Federation, City Petushkova.

IP GeoLocation

 

Why is the malware dubbed “Racketeer”?

Well, after debugging one of the buffers being injected into Explorer.exe, I found a string that reveals the program database location, which is linked to the source code of the malware:

X:\racketeer\solutions\new\output\Release\bin\rack-core.pdb

YARA detection rule

Based on the details that have been identified, we can create a simple YARA rule for detection of the CryptoLocker “Racketeer”. Hopefully that would help other malware researchers and security companies.

rule cryptolockerracketeer : cryptolocker
{
    strings: 
		$a = "Tools_Android_Pacage"
		$b = "Cyber_com_.mdb" fullword nocase
		$c = "X:\\racketeer\\solutions\\new\\output\\Release\\bin\\rack-core.pdb" fullword nocase

     condition:
        ($a and $b) or $c             
}

Yara-001

Summary

With this particular sample, the C2 server—at this writing—is down. We will continue investigating and reversing the samples to find out more details and extract the private key from the local machine.