Topic: Cidox Trojan Spoofs HTTP Host Header to Avoid Detection

[Pez]

Cidox Trojan Spoofs HTTP Host Header to Avoid Detection

Lately, we have seen a good number of samples generating some interesting network traffic through our automated framework. The HTTP network pattern generated contains a few interesting parameters, names like “&av” (for antivirus?) and “&vm=”(VMware?), The response received looked to be encrypted, which drew my attention. Also, all the network traffic contained the same host header pointing to metrika.yandex.ru. These samples turned out to be related to the Cidox Trojan family. Here is the Wireshark packet capture of the Get request:



("click the images to make them larger")

One might immediately conclude that the host name in the Get request is the culprit and may be compromised, or it is an attacker’s domain that isn’t correct for this sample. The domain looked to be legitimate because yandex.ru is the largest search engine in Russia. To confirm, I quickly checked the packet capture for the DNS request and IP address (where the Get request was sent); it differs from the IP address of metrika.yandex.ru. This tells me that the host header in the Get request is spoofed and must be hard-coded in these samples.

We have seen this trick used recently by malware authors in which HTTP host headers are spoofed to point to legitimate domains to evade detection based on host headers or to evade researchers or automated tools. The response from remote server was encrypted, so I decided to look into it.

The malicious binary used a custom packer and wasn’t difficult to unpack.



Once unpacked, you can see several interesting strings in the binary, below:



This binary checks whether the sample is running under VMware and also looks for antimalware services. Remember, the network traffic shown earlier contains “&vm=” and “&av=” parameters. We can conclude this binary sets those parameters based on the preceding checks. I could go on and on in this blog, but for your sake I will focus only on a couple of important items. The binary starts its main operation by the process replacement method to overwrite the memory space of a running process with a malicious executable. The binary creates an “explorer.exe” process in suspended mode and maps the process memory with its own code, as shown next:



It then executes the mapped binary code with the “ResumeThread” procedure. The binary next drops a few files:



It sets a registry key with the value that is the path to a DLL, so that each process using user32.dll will load this DLL. Also it drops some configuration files under the Cookies directory:



The cf file is encrypted and we will look into the encrypted file shortly, but first we need to see the HTTP header generated by this binary. The binary collects information such as browser, operating system, antimalware and VMware checks, OS version (32 or 64 bit) etc. and prepares the HTTP Get request. Here is screenshot of the Get request header in process:



As we suspected, the binary has a hard-coded host header, which points to metrika.yandex.ru, but the actual domain is different. It may come from a dropped encrypted configuration file. The response from server is encrypted as follows:



The binary uses custom Tiny Encryption Algorithm (TEA) to encrypt and decrypt the data. Here the call has been made to decrypt the response from the server:



TEA uses a 128-bit key for its encryption and decryption routine. The binary uses two hard-coded keys: one for decrypting the data comes from the server and the second stores the data in encrypted format, as shown in the preceding image. It is easy to identify the encryption method used based on few constant values found in the algorithm. Here is snapshot of the TEA code:



Once decrypted, the response turns out to be a configuration file containing domain names, as seen below:



The binary stores this information in encrypted format in the file cf, as we saw earlier. The binary then downloads and installs another malicious program from a different server named in the configuration file. Here is the request:



The request to dldc.php sends an encrypted response that contains another executable file.



We won’t go into the details of the downloaded binary. The attacker behind this Trojan collects a lot of information through the Get request, including antimalware or VMware checks. The binary makes detection difficult for automated processes or intrusion detection or prevention systems by using spoofed host header names and custom TEAs for encrypting data. As we have learned, we can’t rely solely on the HTTP header host to judge whether the domain name used in an HTTP header is malicious.


Original article: Tuesday, September 3, 2013 at 4:06pm by Umesh Wanve