Recently, I discovered a back door Trojan horse program that does not work on Microsoft Windows XP. I would like to present some of the details of this threat, especially as the malware author encoded a special trick into the functionality of the Trojan. The trick appears to have been designed to allow the threat be used in targeted attacks.
The fseek function
In this threat, the author uses the fseek function, which is unusual as it is normally used to process data. For example, if the program reads 100 bytes of data from the top of the file, the fseek function process is used to move the 100 bytes.
Figure 1. The fseek code trick used by the malware
However, in the case of this Trojan, there are three functions that continue in a loop:
- Append one string to another string (strcat)
- Move zero bytes from the end of the file (fseek)
- Split a string into tokens (strtok)
Usually, code reads or writes data after the fseek function, but in this case this process does not happen. It is also strange that such a function is written in a loop.
Looking at the code in greater detail, the fseek function works with a NULL pointer as a file handle. This means that there is no file to control. Because the fseek function controls a non-existent file, the threat crashes when it is executed on Microsoft Windows XP.
Figure 2. The threat crashes when it runs on Microsoft Windows XP
If the file is executed on Microsoft Windows Vista or later, it works fine. So what is the difference between Microsoft Windows XP and later versions of Windows?
According to the MSDN Library for Microsoft Visual Studio 2005 or later, the fseek function is documented as follows:
“If stream is a null pointer, or if origin is not one of allowed values described below, fseek and _fseeki64 invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions set errno to EINVAL and return -1.”
However, there is no mention of this in the Microsoft Visual Studio .NET 2003 MSDN Library.
I think the fseek code changed when a file handle with a NULL pointer is passed as a parameter to the function. The malware author used this change intentionally in order to create a program that doesn’t run on Microsoft Windows XP.
Microsoft Windows XP has just under 40% usage share of the operating system market as of March 2013. If a malware author creates a program that doesn’t run on Microsoft Windows XP, valuable opportunities to compromise a large number of computers will be lost. So, why would someone create malware such as this?
Why not run on Microsoft Windows XP?
One possibility is an attempt to avoid revealing the true behavior of the threat in sandboxes. I submitted a sample file to eight Automated Threat Analysis Systems found on the Internet and none of these systems logged the sample file behavior. I believe the reason for this is that the malicious code is found after the fseek function trick. If the sandboxes used for testing samples ran on Microsoft Windows Vista, or rather any operating system later than Microsoft Windows XP, they may not have logged the malware’s behavior. (Please see this blog for further details regarding how Automated Threat Analysis Systems are used by antivirus companies to analyze malware.)
If malware runs without performing any destructive or disruptive activities in silence, it can continue to compromise computers for a long time, for which the merits to the malware author cannot be overstated.
Back door Trojan horse programs usually check the operating system, CPU clock, and the installed antivirus product, if any. This threat is unusual because it also gathers the following information:
- Whether the compromised computer has a wireless network card
- The dynamic random-access memory (DRAM) type, such as Synchronous DRAM, Cache DRAM, 3DRAM, or SDRAM
- The BIOS manufacturer settings, serial number, and version
- The printer caption
- The battery description and device ID
Normally malware authors wouldn’t worry about the battery on the computer. However, the author of this threat evidently has a strong interest in the targeted company.
Conclusion
At the time of writing this blog, Symantec has only received two samples of this threat from large customers and no major infections have been recorded.
From what I can gather from my analysis of this threat, it was used in a targeted attack and the author knew that the targeted company uses Microsoft Windows Vista or later on their computers and hence attempted to infect their network with malware that does not work on Microsoft Windows XP.
If the administrator of the targeted company were to notice suspicious behavior in a suspect file and decide to test it on an Automated Threat Analysis System, it is possible that malicious activity may not be seen at all during the testing and the administrator would be none-the-wiser about the file’s true behavior.
Symantec will continue to monitor malicious code and techniques outlined in this blog. We also recommend that users not run suspicious programs and keep their operating system and antivirus software up to date.
