I've recently come across a file AVG classifies as Trojan horse Downloader.Istbar.6.BU and Kaspersky Labs as Trojan-Downloader.Win32.IstBar.gen. I've decided to have a closer look at it. It turned out to be a major disappointment because there are basically not many interesting things to tell about the code in there. I'm nevertheless going to discuss my findings briefly because there are still one or two remarkable things.
If you downloaded the file don't worry about accidentaly running it, I've applied a small patch to it to make it unrunnable. If you know what you're doing you can restore it's functionality. Even if you run it in it's fixed form nothing bad will happen as long as you deny it access to the internet.
The header of the file is moderately interesting. Merging MZ header and PE header apparently caught on with the writers of EXE packers over the last time. The last time I saw it was when I had a brief look at .kkrieger, the 96KB small 3D shooter made by .theprodukkt. Istbar gets bonus points for storing the kernel32.dll string in the unused parts of the MZ header though.
The import directory of the file is only 0x14 bytes large and slightly malformed. It lacks an empty import directory entry which is supposed to terminate the import directory. I was glad to find out that my Filedump tool from the PeLib library was able to handle this correctly and to produce a correct dump of the headers.
Apparently the terminating empty import directory entry must only be available when the import directory is initialized after the file was loaded by the Windows PE loader, it's not necessary to exist in the file on disk. If the import directory is placed at the end of a section it's easy to get an empty import directory entry "for free". Make the virtual section size (sufficiently) larger than the physical section size, the bytes which can't be found in the physical section are by default added in memory and initialized to zero. That's where the terminating import directory entry comes from.
PeLib was able to handle this behaviour because I had observed it before. There's a PE packer floating around on the net called FSG 2.0 which also employs this technique and a file packed by this packer is a test case in the PeLib unit test library.
The code of the file consists of only four major parts:
- The unpacking code of the PE packer.
- The VC++ init code.
- The main function.
- A function that downloads a file from the internet.
I've basically skipped the unpacking code because I couldn't get the free version of IDA to diassemble it. The problem was that the code of the packer is not located in any section. The instruction at the entry point is a jmp to the actual unpacking code which is located at offset 0x158 (right behind the PE header). The unpacking code is pretty compact. It ends at offset 0x1FA and uses only calls to two trivial functions. The location of these two functions amused me. You've actually already seen it on this page if you looked closely. It's the names of the two sections in the PE header. The names really are code that's executed. I had never seen that before.
After the code was unpacked the packer initializes the import directory manually by calling LoadLibrary/GetProcAddress for all necessary functions.
To look through the unpacked code of the executable I've made a dump using OllyDbg. Much to my regret IDA still did not recognize the header as valid. This problem was quickly remedied by replacing the old header by a valid header from a valid exe file. After a few changes (NumberOfSections, EntryPoint and PhysicalOffset of the first section IIRC) IDA disassembled it correctly. The dump I've linked to already has the new header.
I won't discuss the VC++ initialization code.
The main function (Click for IDA log) is the smaller function of the two remaining functions. It has three responsibilities: To get the name of the temp path of the current user, to call the function that downloads a file from the internet and stores it in that temp path and to execute that file then.
The last function, which I've called DownloadFile (Click for IDA log), takes two parameters: A lpstr to the URL from where to download the file and a lpstr to the name of the file in the temp path where the file is stored. It's also pretty straight-forward. The Visual C++ classes CFile, CInternetSession, CInternetFile and CHttpFile (all imported from MFC42.dll; some are only used because they are base classes of the others) are used to download the file and store it. The download happens in chunks of 1024 bytes between the offsets 0x40115E and 0x4011AF. A flag is returned to the calling function that indicates whether the download was succesful.
The two parameters given to this function are "[TEMP-PATH]\fGCdZb6.exe" and "http://www.slotch.com/ist/softwares/v4.0/istdownload.exe". I wouldn't necessarily recommend to download that file.
A minor problem was that MFC42.dll exports functions by ordinal. That made finding out which function is called by Istbar appear problematic at first. Thankfully I found out that VC++ 6 comes with a MFC42.def file that can be used to translate ordinals from that DLL to function names. Unfortunately I don't have a copy of VC++ 6 but I've also found the file online. But even using that file I wasn't able to find out what two functions (ordinals 823 and 825) do. "??3YAXPAXZ @ 825 NONAME" is a bit too cryptical although I'm positive that somewhere out there a tool exists that tells you the original name for mangled function names. Those two functions were not critical at all though and therefore I didn't bother to research the issue further.
There's one thing left I haven't discussed yet. Just what does that downloaded file do? This appears to the real Trojan, or at least some kind of ad-ware that doesn't like to be removed from a system. I've had a brief look, it's a UPX packed executable of 21 KB (48 KB unpacked). There's apparently absolutely nothing interesting about it. I've heard it installs things like toolbars in browsers, and looking at the string references in that file that might very well be true. I'm not the one to find out though, I know of more amusing things than looking through 48 KB files just for fun.
Looking back this particular piece of malware was pretty boring. Better luck next time I guess.
The annotated IDA disassembly file can be downloaded here. It can be read using the IDA freeware version 4.1
By the way: I'm aware of the format errors in this post. In the hex dump of the headers the NL2BR plugin conflicts with the BBCode plugin. Maybe I'll get that problem fixed one day. There's also a slight problem in the cryptic line I've copied from MFC42.def.
The file is so old that it should be picked up by any recent anti-virus tool. According to http://virusscan.jotti.org/ all scanners but ClamAV, Fortinet and VBA32 are able to detect it.
The real problem however is that the downloader itself can download files with any imaginable malware functionality. In case the virus was granted internet access that means it's probably not possible to reliably clean infected systems without re-installing Windows.
For more information you should consult the websites of the various anti-virus vendors.