In our everyday world, we sometimes make use of thin clients, which don’t have a lot of functionality but are easy to maintain, as their functionality is based on data they receive from remote servers. Malware authors have adopted a similar technique, in which malware is able to download executable code without actually downloading an executable image. We’re talking about malware that isn’t a typical trojan downloader.
The typical routine for trojan downloaders is that the downloaded file is normally modified on the server side, and the downloader itself offers only a download and execute function, which is cheap to produce and therefore expendable in terms of antivirus detection. As a result, we currently detect over eight million trojan downloaders for Windows, most of which download the executable to disc or inject it into other processes.
Unfortunately there is no need for malware writers to download an executable at all. We recently analyzed a sample, TrojanDownloader:Win32/Poison.A (SHA1: 2cc1b2cca8d07b55144141625aea3e61f2eca182), that downloads a blob of position-independent code, and executes it in the context of a previous non-malicious application.
At first, the sample appeared to be a very small Visual Basic-written application that accesses the website of a Tibetan restaurant. I expected a trojan downloader using the normal routine, but during fast static analysis I couldn’t see any file access operation, or any other suspicious system call. Instead, it simply displayed Figure 1 below:
Figure 1: Error message displayed when run on an isolated machine
Once the application was run on a machine with a simulated Internet connection, it got the contents of the HTML page of the restaurant website mentioned previously. The application copied itself to the Windows system folder as “misys.exe” (as shown in Figure 2 below), and started keylogging, although the static analysis did not indicate this kind of functionality.
Figure 2: The file “misys.exe” on a computer connected to the Internet
The question is: where does that file come from? The mystery was solved when I looked at the HTML code of the restaurant webpage, which begins with the following hex instructions:
&H55, &H8B, &HEC
These characters make up the standard x86 function prolog:
Figure 3: The assembly code for the hex instructions
So the VB Application is extending its functionality dynamically by downloading and executing x86 instructions in the context of its own process. The “downloader” becomes malware by executing this downloaded blob of x86 instructions. And the downloaded instructions will be not injected to a different process and not dropped to disc, they will be executed in the process context of the “downloader”, thus the “downloader” inherits the malware functionality.
After the whole HTML page was converted into binary as in Figure 4, the file name in Figure 2 was clearly visible:
Figure 4: The file name is visible after conversion to binary
The downloaded binary blob is a variant of the Win32/Poison family. The functionality of the downloaded code is widely documented in its entry in the MMPC Encyclopedia.
The Win32/Poison trojan can be created with an easy-to-use Builder Tool, which allows malware authors to customize a build according to what they want to steal. We discuss the kit and its distribution in the MMPC Threat Report – Poison Ivy paper we released in November of this year. A possible reason why Win32/Poison is so prevalent, although it’s quite an old trojan, is the fact that it allows malware authors to create with one click of the mouse, position-independent code that has the trojan functionality, instead of creating an executable, as shown in Figure 5:
Figure 5: Win32/Poison builder allowing shellcode or PE creation
So while the malware we discussed here, TrojanDownloader:Win32/Poison.A, is a different kind of trojan that takes a while to build, in minutes it was just another threat detected by Microsoft AV products.
— MMPC
Leave a reply
