An IM user received the following message from a buddy on their list. Like other IM malware, the message entices the onlooker to click the link, which ultimately points elsewhere.

Files with .exe and .pif (to name a few) are much more dangerous than zip attachments in email, because two (in some cases, one) clicks and you're done. Zip attachments require a user to extract first. Attackers using the email mechanism also have to worry about catchy subject lines, From: address fields, message bodies, and spam/antivirus on email gateways. Malware that spreads over IM has a much quicker propagation avenue and has only a fraction of the hindering factors.

Image3.pif has since been removed from the hosting server, however not before a copy was obtained. The file size is 44,820 bytes (45,056 on disk) and reports having three sections: .nsp0, .nsp1, and .nsp2. Using (pedump), the following information was obtained:

C:\>pedump image3.pif

Optional Header
  size of image            80000

Imports Table
  KERNEL32.DLL
    0 LoadLibraryA
    0 GetProcAddress
    0 VirtualProtect
    0 VirtualAlloc
    0 VirtualFree
    0 ExitProcess
  USER32.DLL
    0 GetMenu
  MSVCRT.DLL
    0 _dllonexit

Of particular interest is the 0x80000 size of image (SizeOfImage) value. This indicates the amount of address space (including all headers) to reserve for the loaded executable image. 0x80000 is 524,288 bytes - quite an increase from the file's original 44,820 size. This could potentially mean that the executable imports a large number of functions into it's private address space, it's sections are aligned in memory with gaps between them, or the file is packed on disk and expands once executed. (Stud_PE), which loads 400+ signatures for known packing utilities reports that none are detected in image3.pif. Also, search engines return very few results for pages containing the term ".nsp0" and ".nsp1" - the few of which are executables themselves, which contain the same section names.

Glancing back up at the pedump output, the list of DLLs to import and functions to use are the only readable strings in the 44,820 byte file. Without knowing the packing algorithm used, it can't easily be reversed. It could probably be done with a few days/weeks work of advanced reversing with a disassembler and/or debugger. In the meantime, the easy solution is *usually* to execute the program in a controlled environment, such as (VMware), and wait for the file to unpack itself. Once the executable is loaded into memory in unpacked form, it's image can be dumped out of RAM. This usually results in an image with corrupt PE headers, but much easier to analyze since the majority of it's content would already have been unpacked/decoded.

The problem in this case is that image3.pif is just a loader and does not remain in memory for longer than a fraction of a second. This is not enough time to select it's process name and do the dumping using something like (LordPE). As an alternative, image3.pif was loaded into the (OllyDbg) program (a powerful debugger for Windows) and a breakpoint was set at a completely arbitrary offset near the end of the file (arbitrary since due to functions, code is not always executed strictly from top to bottom). Nevertheless, this method worked like a charm. The process hung at the breakpoint and lingered unpacked in memory long enough to dump it with another tool.

The result is a 532,480 byte image, which is only slightly larger than the reported SizeOfImage value discussed earlier. Given the careless method of capture, this small discrepancy would make sense. The advantage to analyzing the unpacked version is that now there are 1100+ readable strings rather than just 10 or so. Here are a few that are among my favorites:

00011590   00411590      0   Exploit FTPD: %d, Total: %d.
00012374   00412374      0   %s %s: Exploiting IP: %s\%s, %s/%s (NetScheduleJobAdd)
000123AC   004123AC      0   %s %s: Exploiting IP: %s\%s, %s/%s (CreateService)
000127E4   004127E4      0   %s Bot installed on: %s.
00012800   00412800      0   Go fuck yourself %s.
 
00012DFC   00412DFC      0   aimspread thread
00012E10   00412E10      0   %s Spreading message: %s
00012E2C   00412E2C      0   %s Automated messaging active.

00013A28   00413A28      0   NOTICE %s :%s
00013A38   00413A38      0   PRIVMSG %s :%s
00013A4C   00413A4C      0   JOIN %s

0001389C   0041389C      0   220 Reptile welcomes you..

00014878   00414878      0   %s PID "%i" killed and deleted.
000148F0   004148F0      0   %s Process "%s" killed, total: <%s>.

0001600C   0041600C      0   SOFTWARE\Microsoft\Security Center
0001610B   0041610B      0   AntiVirusOverride
0001641C   0041641C      0   SOFTWARE\Microsoft\Security Center
0001651B   0041651B      0   FirewallOverride

This is quite a mean peice of malware. It exploits FTP services and scans for vulnerable targets, installs bot programs, spreads through AIM, operates over IRC, interferes with running processes, and disables Firewall and Antivirus applications. The scanners at VirusTotal identify it as a likely variant of SDBot:

Scan results
 File: image3_dumped.pif
 Date: 12/20/2005 02:09:02 (CET)
----
Avast   4.6.695.0/20051219      found [Win32:SdBot-2938]
BitDefender     7.2/20051220    found [GenPack:Backdoor.SDBot.3F3DCB2A]
eTrust-Vet      12.3.3.0/20051219       found [Win32/Petribot!generic]
Fortinet        2.54.0.0/20051219       found [suspicious]
Ikarus  0.2.59.0/20051220       found [Backdoor.Win32.PcClient.GV]
NOD32v2 1.1328/20051219 found [probably unknown NewHeur_PE virus]
Symantec        8.0/20051220    found [W32.Spybot.Worm]
VBA32   3.10.5/20051219 found [Backdoor.Win32.SdBot.aad]

Being a variant of SDBot is not the reason image3.pif appears in this article, rather for the difficulty it presented during normal unpacking/dumping routines. In many cases, Stud_PE can easily identify the packing algorithm and report it on the Signature tab of the program:

In the case that the algorithm is natively reversable (such as UPX), it can easily be unpacked without being run, by using the (UPX utility):

C:\>upx -d packed.exe
...
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    894375 <-    849319   94.96%    win32/pe     packed.exe

Unpacked 1 file.

If an identification tool does not return results or if the algorithm used is not natively reversable, then normally dumping is a good alternative. Dumping can be done from a debugger (such as the plugin for OllyDbg), a module within Stud_PE, or (my favorite) the LordPE program. Of course others exist, but these are readily available and simple to use. Here is a screen shot with the first and third steps - the second, which could not be shown, consists of right clicking the image name and choosing "dump full":

A more advanced way to do this would involve examining the unpacking routine within a debugger or disassembler and setting a breakpoint in program execution immediately after this function completes. This would give us a pure snapshot of the image in memory after being unpacked but before any other instructions are executed.