This weekend I received another “postcard” e-mail. It looked different than those seen around Christmas so I went to investigate what’s going on here. The main difference was that this was an HTML e-mail, without any attachments, but with a “hidden” link to malware (of course, by moving your mouse over the link shown by the HTML message, one was able to see where it really goes).
The link was pointing to http://www.pettrans [dot] sk/[removed].exe (the site is still up and happily serving malware).

After I downloaded the malware I did couple of quick tests on my Linux machine, as always with new malware:

$ ls -l PostCard.exe
-rw-r--r-- 1 no no 861031 Dec 28 21:37 PostCard.exe
$ md5sum PostCard.exe
866efca20e87813350e325c92680accc PostCard.exe
$ file PostCard.exe
PostCard.exe: MS-DOS executable (EXE), OS/2 or MS Windows

So it was definitely a Windows executable. At this stage we typically want to know if the malware is packed or not, as that can delay the analysis. There are various ways of identifying packed malware – probably the best way to do this is by using PEiD (peid.has.it), a nice utility for identifying PE (Portable Executable) files. PEiD can do most of the job for us as it has a database of fingerprints for well known packers, and besides this it has a really nice feature of calculating the entropy of the analyzed file. This allows you to determine if a file is packed or not, without knowing the packer – files with high entropy are almost certainly packed or encrypted.
However, before starting PEiD, I usually go the easiest way and that’s to run the strings command on the file. If a file is packed, the strings command typically just shows us couple of imported functions and the rest will be garbled. If the file is not packed we will be able to see all text strings in the file, provided that the author didn’t protect this differently.
Running strings on this malware showed something interesting:

$ strings PostCard.exe | less
=A t
:jgS

[…]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Roshal.WinRAR.WinRAR" type="win32" /> <description>WinRAR archiver.</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> </assembly>

Oh! So the file is “packed”, but it is basically just a self extracting archive created with WinRAR. This can be unpacked with any RAR handling application, and I simply used unrar on Linux:

$ unrar t -v PostCard.exe

UNRAR 3.30 freeware Copyright (c) 1993-2004 Eugene Roshal


Testing archive PostCard.exe

Path=C:\WINDOWS\system\
SavePath
Setup=C:\WINDOWS\system\svchost.exe
Setup=C:\WINDOWS\system\sup.bat
Silent=1
Overwrite=1

Testing download OK
Testing logs OK
Testing sounds OK
Testing aliases.ini OK
Testing control.ini OK
Testing fullname.txt OK
Testing icon.ini OK
Testing ident.txt OK
Testing mirc.ico OK
Testing mirc.ini OK
Testing mircs OK
Testing nicks.txt OK
Testing popups.txt OK
Testing poza.txt OK
Testing remote.ini OK
Testing script.ini OK
Testing servers.ini OK
Testing sup.bat OK
Testing sup.reg OK
Testing svchost.exe OK
Testing users.ini OK
All OK

So it’s a bunch of files packed with WinRAR. We can see an interesting thing here as well. The author used WinRAR’s possibility of specifying the setup script. This is typically used when you download an installation file that has been compressed with WinRAR as a self extracting archive (so you don’t have to have WinRAR on your machine to decompress this). Unrar nicely showed at the beginning what will happen if we execute this file:

Path=C:\WINDOWS\system\
SavePath
Setup=C:\WINDOWS\system\svchost.exe
Setup=C:\WINDOWS\system\sup.bat
Silent=1
Overwrite=1

This file uses silent unpacking mode (so no information is shown to the user) and will overwrite any files it already finds on the system. It will extract everything into C:\WINDOWS\System and upon extraction it will run two files, svchost.exe and sup.bat.
The rest of the analysis was easy – sup.bat file just copied svchost.exe again into the C:\WINDOWS\System directory and set up registry keys needed so this file is started when the system is rebooted. Svchost.exe is a version of the Mirc client and the other files in the archive are simply Mirc configuration files that create a local bot which will join the Undernet IRC network. What’s funny is that the Mirc file was infected with another virus – I bet that even the author’s machine is infected with that virus.

Lessons learned

Due to an easy packer and an old virus almost every AV program detected this without any problem. The effort of creating something like this is absolutely minimal – the Mirc configuration is in various text files and WinRAR was used to pack this.
So what does this tell us?
The huge user base that Windows operating systems have gives enough potential victims that the bad guys do not even have to use any sophisticated techniques. A simple executable file, which was “hidden” by a bit of social engineering was probably enough for them to get a /decent/ infected bot base.
Besides patching systems and keeping your AV program up to date, it is obvious that user awareness/education is the most important element in an average user's protection arsenal.

UPDATE

David pointed to another analysis of practically the same malware. As this (other) analysis happened way back in April 2006, it looks like they are just rehashing the same (probably profitable) way of fishing for new victims.

The domain on which malware was hosted was, of course, different than the previous one. Robert pointed that the same domain www[dot]pettrans[dot]sk has been used previously in various phishing attempts, so if you are blocking web traffic to certain domains, this is definitely a candidate.