Analysis of a Sample Spread by New IE Zero-day (CVE-2012-4969)
On 17th, September 2012 the security researcher Eric Romang published an article Zero-Day Season Is Really Not Over Yet  at his blog, which reveals a new kind of IE Zero-Day vulnerability. This vulnerability has become the top topic and Microsoft has published the patch for it .
Antiy CERT analyzes the vulnerability and also the malware sample file 111.exe that exploits the vulnerability the first time knowing the news. The following is the analysis detail:
We use the binary tool to check through 111.exe (Figure 1) after obtaining the sample and find that it is not a PE file.
The sample might encrypt by using XOR algorithm in accordance with our past experience. Considering that 0x70 results from 3D and 4D XOR and also 2A and 5A XOR, we boldly guess that this sample may have XOR with 0x70 byte by byte.
In the contrary way, we let it XOR with 0x70 byte by byte again to decrypt and the contents we get are as follows (in Figure 2):
The file head that has been decrypted is MZ (0x4D5A). However, it is still not a valid PE file and cannot be identified by PE analysis tool.
Comparing with the normal PE file, we find the following differences: on the one hand, most bytes of the decrypted file heads are 0x70, while the normal file’s should be 0x00; on the other hand, all the decrypted file heads contain “This .rogram cannot be run in DOS mode”, while the normal file should be “This program cannot be run in DOS mode”, of which the former’s hidden hexadecimal value is 0x00 and the latter’s hexadecimal value of character p is 0x70.
Let’s think logically: we guess that the XOR key is 0x70, but this law can not apply to the situation where the original value is 0x00 and 0x70. It seems that the author skipped the XOR encryption operation for these two situations.
We try to decrypt the original sample according to this law, the result is as in Figure 3.
Until now the sample seems to be a valid PE file—The PE head has been normal and can be identified by PE tools. However, we might not know some details of the actual encryption method, the export table is in question (Shown as in Figure 4), which does not affect the following analysis.
Analysis after decryption
The sample will copy itself to the %temp% directory and rename itself by the random numbers with the .dat suffix. It uses MoveFileEx function to delete itself, traversing system process to find winlogon.exe process and terminate the module sfc_os.dll in the winlogon.exe (In Figure 5), being used to forbidden the file completion check of the system, preventing the fake mspmsnsv.dll from being restored by the system.
The sample will modify the following registration key value:
Description: it deletes its own file under TEMP directory in the next system startup.
The sample will delete the system file mspmsnsv.dll under %system32% directory and release its own resources as %system32%\mspmsnsv.dll; it modifies the file time to be the same with sfc.exe. and enable the WmdmPmSN service to load mspmsnsv.dll.
The mspmsnsv.dll is a backdoor process which registers as system WmdmPmSN service; it enables along with the service and judge whether the user belongs to the administrator group after execution; it establishes the mutex “808834455” and calls the socket function dynamically; it links ie.aq1.co.uk (invalid) every 30 seconds after initialization to obtain on-line information, being controlled by the remote host after the successful link.
According to the WHOIS information of ie.aq1.co.uk, we find that the registrant of this website is Jeroen Nieboer and the register address is Flat 9 Riverside Point Radmarsh Road Nottingham NG7 2GJ United Kingdom.
More information about ie.aq1.co.uk can be seen in reference .
Some other vendors have analyzed the situation that the sample exploits the new IE Zero-day vulnerability, so we will not repeat any more.