From time to time, we register higher than usual volumes of malicious spam emails being spread in certain locations. These spam campaigns are usually geographically and language specific to make them more trustworthy and successful but otherwise are very similar. They can take the guise of a fake traffic ticket from the New York State Department of Motor Vehicles, or a Tax Refund Notice from UK’s tax department. And of course there is a malicious file or document attached in all these cases.
Recently, we have registered this kind of spam campaign targeting Czech users. The message is pretending to be an MMS sent through any one of the local mobile operators. The following screenshot shows the typical scenario where T-Mobile was misused to fool users.
The attached archive contains a malicious executable file with double extension pretending to be a JPG image (e.g. “MMS img 76897644.jpeg.exe“). This technique is quite common in these cases. The sample itself is usually a Zeus bot downloader which contacts its C&C server and downloads other malicious files. The downloader itself contains some quite interesting features from a technical point of view:
1) After execution, the first encryption layer is decrypted and several checks to detect controlled environment are performed. For example by:
– checking the disk device ID (by querying HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum\) for any of the strings qemu, virtual, vmware or xen.
– checking the BeingDebugged flag in the PEB (Process Environment Block) data structure
– verification whether the process does not contain “sample” in its name
2) If all these tests are successfully passed and no virtual environment or debugger is detected, the program then changes its flow by registering FileIOCompletionRoutine callback function:
This infinite SleepEx function, as shown on the screenshot above, is set as “Alertable” and is interrupted by registered FileIOCompletionRoutine as soon as the previous IO operation (ReadFileEx) completes (which happens almost immediately). This routine makes single-step debugging little bit more difficult.
3) As a next step, the malware tries to inject code and encrypted data into the explorer.exe process. One of two available injection methods is then chosen, depending on the version of Windows (32-bit/64-bit) sample is running on:
3a) For 32-bit version, the following steps are taken:
i) Process ID and Shell_TrayWnd window handle of the explorer.exe is found by calling:
hWnd = FindWindow(“Shell_TrayWnd”, 0);
GetWindowThreadProcessId(hWnd, &pid);
ii) A view of the section is then mapped into explorer.exe address space using these functions respectively:
NtOpenProcess, NtCreateSection, NtMapViewOfSection
iii) Malicious code is then copied to the explorer.exe address space using previously mapped views.
iv) The sample then executes the following functions to get specific procedure of the Shell_TrayWnd window and change it to point to the malicious code:
old = GetWindowLongA(hWnd, 0);
SetWindowLongA(hWnd, 0, malAddr);
– Where malAddr contains an entry point address of the malicious code injected in the explorer’s address space. It is then executed almost immediately after this step as the routine sample has changed is triggered repeatedly by the explorer.exe process. The following screenshot shows what this change looks like:
A similar technique was introduced in the complex bootkit droppers in the end of the last year. It seems that this way of remote code execution will now become more popular among different types of malware.
v) Once the malicious code has gained the control, it performs several steps (see below) and then restores the altered routine of Shell_TrayWnd to the original state:
SetWindowLongA(hWnd, 0, old);
3b) In the case of 64-bit Windows, the malware chooses a more ordinary approach:
i) Process ID of explorer.exe is found by calling Process32First/Process32Next functions.
ii) Malicious code is injected to this process using the same steps we described above (NtOpenProcess, NtCreateSection, NtMapViewOfSection).
iii) Injected code is then executed by calling CreateRemoteThread WinAPI function.
4) Injected explorer.exe then creates new suspended svchost.exe process using CreateProcessInternal function, writes its code and data there and pass the control to this newly injected svchost.exe using NtQueueApcThread and NtResumeThread functions.
5) Code in svchost.exe decrypts DLL encrypted in its injected data which finally does all the malicious work:
i) Moves malware to the randomly named subfolder of the user’s %APPDATA%. The name of this new file is random as well. For example:
C:\Documents and Settings\Administrator\Application Data\vfevufui\deghfhsh.exe
ii) Creates following registry entry to ensure, that sample is started after computer restart (when the user logs in):
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run “<Value>” = “C:\Documents and Settings\Administrator\Application Data\vfevufui\deghfhsh.exe”
– where <Value> is a randomly chosen name selected from the keys stored in HKCU\Software\ to make this entry more trustworthy
iii) Finally, this injected DLL contacts its C&C server and eventually receives new encrypted binary file. This new file (Zeus bot) is then executed on the user’s PCs and connects it to the botnet. Stealing of the victim’s sensitive information may begin.
AVG detects this file as Trojan horse Generic_r.CIW and MD5 of the sample is: 5F7649B9DF358814B19E09EDD5F56D87
Tomas Prochazka
Leave a reply
