Websense has shared in its security labs blog that it has detected a malware-ridden spam campaign that attempts to exploit subscribers of major mobile phone companies. Elaborating upon the nature of the campaign exposed, the blog post shares that they managed to detect thousands of emails, wherein users claimed to have received MMS content via email localised to Australian and German carriers. The cause of concern here is that since mobile phones are a tool of everyday activity, it made it possible for the malware to dupe users into opening and running attachments, especially the ones coming from their carriers.
Once the malware is launched, it connects to a list of remote servers to download more malicious binaries. A point to note here is that these samples are heavily encrypted and have several anti-debug tricks. This sample is especially adept at deploying many decryption phases before it finally puts into action its malicious intentions. Interestingly, it implements decryption and patching only in memory.
The malicious email
The decryption process comprises three phases. In the first phase, the malware copies itself as “C:Documents and SettingsAll Userssvchost.exe”, and then registers itself as autorun by creating a Registry Key. Because of this, the malware starts automatically once Windows boots up. Citing one example, the report shares:
Telstra-picture:656 “C:Documents and SettingsAll Userssvchost.exe" RunSunJavaUpdateSched HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunSunJavaUpdateSched
It then decrypts itself and rewrites the memory image of itself. This way, the malware does not need to create a new PE file on the disk, and the original malware becomes a totally different one in memory, even the PE header and code entry point, thus leading us to the next phase. The phase two file is encrypted too, and implements many anti-debug tricks.
The post further shares that the malware detects all the running processes in the system and tries to locate “VmwareService.exe”, ”VmwareUser.exe”, ”wireshark.exe”, and other monitors or antivirus processes. What is interesting here is that the malware does not use plain text strings to find all the process names, but uses some self-defined hash algorithm to calculate the name of a process into a HEX string, instead.
Going further, the sample looks for the registry value of “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesdiskenum”. It also moves to check the local disk value and whether the 8-12 character of disk name references “awmw” or “xobv” or “umeq”. "In other words, the malware checks to see if it's been run under VMware, VirtualBox, and QEMU (an open source processor emulator). If it has, the malware stops infecting the computer. **Notice the malware creator's typo on 'awmw'; it should be 'awmv'," adds the post further.
Once it has carefully looked around, the malware goes to the next phase, i.e. decrypting itself. Then, instead of modifying the Windows Update Agent service “wuauclt.exe” file on the disk, or trying to find the process memory of “wuauclt.exe” and inject malicious code into it, the malware maps an image of "wuauclt.exe" into memory using the “Section” kernel object. It injects all the malicious code into the memory page, and finally executes “wuauclt.exe”.
Since the malware does not modify the Windows Update Agent on the hard disk and patches the process in memory with the the “Section” kernel object, some monitors that hook APIs like “OpenFile” or “CreateFile” fail to catch this injection. Also, since the malware does not call “WriteProcessMemory”, it is hard for AV monitors to catch this memory injection.
The post goes on to add that the patched “wuauclt.exe” with the push-return above does the real malicious function. It connects to several remote servers and downloads extra malicious binaries from some of them.
According to the findings published in the WebSense report, some of the remote servers were still available and the malicious binary files were still downloadable.