OMFG! http://.../handcuffs.pif! An Analysis by Ryan Cartner
INTRODUCTION:
-------------
On February 18th 2005, I recieved an MSN Instant Message from a friend with the following content:
"OMFG! http://member.home.nl/marnixstal/handcuffs.pif :o!"
Further discussion with the sender confirmed my suspicions that the Instant Message was automated
and unintentional, likely the propagation technique of some new malware.
This paper will detail my analysis of handcuffs.pif.
Relevant handcuffs.pif info (PRE-ANALYSIS):
-------------------------------------------
download mirrors found through google:
http://member.home.nl/marnixstal/handcuffs.pif
http://members.chello.nl/g.geurts1/handcuffs.pif
http://www. digitalsmackdown.com/handcuffs.pif
File information:
C:\quarantine>dir | find /I "ndcu"
02/18/2005 12:18 AM 160,256 handcuffs.pif
c:\quarantine>..\utils\filever /v handcuffs.pif
--a-- W32i APP ENU 1.0.0.0 shp 160,256 02-18-2005 handcuffs.pi_
Language 0x0409 (English (United States))
CharSet 0x04b0 Unicode
OleSelfRegister Disabled
CompanyName cia
InternalName SHIT
OriginalFilenam SHIT.exe
ProductName S
ProductVersion 1.00
FileVersion 1.00
VS_FIXEDFILEINFO:
Signature: feef04bd
Struc Ver: 00010000
FileVer: 00010000:00000000 (1.0:0.0)
ProdVer: 00010000:00000000 (1.0:0.0)
FlagMask: 00000000
Flags: 00000000
OS: 00000004 Win32
FileType: 00000001 App
SubType: 00000000
FileDate: 00000000:00000000
C:\quarantine>..\utils\md5 handcuffs.pif
FC18FD70B93F3B9FA7821C9425F0D460 handcuffs.pif
AVG 7.0.300 with Virus base 265.8.8 (2/14/2005)
detects no virus.
See appendix A for UUENCODED handcuffs.pif
Notes:
While searching google for references to handcuffs.pif I found multiple sites claiming that
this was a 'W32.Bropia' variant. Bropia opens and locks cmd.exe and taskmgr.exe to prohibit
their execution. Handcuffs.pif does not mimic this behavior. According to Symantec, The J and
N strings of W32.Bropia do not mimic this either. We will further compare our specimen to Bropia
after more analysis.
Preliminary File analysis (PRE-EXECUTION):
------------------------------
The PIF extension indicates the Program Information File type. PIF files provide Windows with
information on how to execute a DOS application. This includes screen resolution and color density,
compatibility modes, but most importantly, the path and filename along with any commandline parameters.
When checking the properties of handcuffs.pif I recieve the following error on the 'program' tab:
NOTE: opening the properties of a file taints the files 'Last accessed' attribute.
The err is assumptive, I have plenty of ram. ;)
This could indicate a few things. Perhaps our malcoder has discovered a way to hide the contents
of the program tab from the properties dialogue. Lets take a closer look.
Figure 3 shows a hex dump of handcuffs.pif. I've highlighted the parts that seem to be of interest.
The first 2 bytes of the file are our first clue as to why windows couldn't load the PIF configuration
data.
This is the DOS MZ HEADER. It's a standard identifier built into executable files to inform
the OS that the file is, infact, executable. PIF files do not require the MZ header. This leads
me to believe that this PIF file is actually an executable masquarading as a PIF file.
In order to prove this theory, we would need to prove that executable files with a PIF extension
execute properly. Renaming notepad.exe to notepad.pif provides sufficient proof after seeing it
execute seemlessly.
Ironically, the second and third box indicate that, despite the PIF extension, this file has no
desire to run as a DOS application. The second box is a portion of the DOS STUB. Basically, the
DOS STUB is a section of DOS compatible code that executes if the application is run from DOS. In
this case, it merely displays the message I've highlighted. The third box tells us that this file
is a Portable Executable (PE), the standard windows executable file format.
So why the PIF extension then? Possibly because its an obscure and rarely used file extension
compared to EXE. Or maybe because of its uncanny resemblence to GIF. Who wouldn't want to see
handcuffs.gif when accompanied by 'OMFG' ? *smirk*
From this point on, we'll treat handcuffs.pif as though it were a standard executable.
Scrolling down a little further with our hex editor reveals another interesting anomaly
There appears to be a second MZ identifier located in the middle of the file. This means that
handcuffs.pif is actually two seperate binaries bound together. The general reason for this is
to bind a peice of malicious code to a harmless application to avoid suspicion after the file
is executed. Assuming this is the case with handcuffs.pif, the question to ask here is whether
the malicious code was appended, or prepended to the harmless host program.
At this point, its important to understand a little about file infection. Basically, the windows
PE loader is not capable of executing two PE binaries in sequence from the same file. We can prove
this in the following way:
copy /b prog1.exe+prog2.exe test.exe
The end result is that 'test.exe' becomes a byte-for-byte copy of prog1.exe and prog2.exe linked
end to end. Executing this code yields unpredictable results, and is not recommended. However, were
you to execute it you'd probably see that only the first binary executes properly.
In order for multiple PE binaries to be executed in sequence from the same file, the first binary
should have a 'loader'. This is basically a functional, built-in PE loader that executes the second
binary. If the malware binary has been prepended to the host program, the loader could simply be
part of the malwares code. Whereas, if the the malware was appended, the host program would need to
be patched with the loader.
There are generally two ways in which a file can become infected. If the malcode in handcuffs.pif
is actually viral, and capable of rewriting its own code, its possible that handcuffs.pif is just
a file that has fallen victim to an actual viral propagation. It is more likely, however, that our
malcoder infected the file himself with one of the many publicly available exe binders in order to
hide its true purpose. This assumption is based on the propagation technique the program is using,
where the filename 'handcuffs.pif' is actually written into the binary.
Lets examine our two new slices of handcuffs.pif. We'll name them binA (consisting of the first
10,043 bytes) and binB (consisting of the final 150,213 bytes). The difference in filesize is worthy
of note, but so far can give no indication of which binary is which.
Have another look at Figure 3. The format for a Portable Executable file is as follows:
DOS MZ HEADER
DOS STUB
PE HEADER
SECTION TABLE
SECTION 1
...
SECTION x
Lets first examine the PE HEADER's of our two binaries. The PE HEADER is formatted as follows:
PE identifier (32bit) always: "PE"+null+null
Machine (16bit)
NumberofSections (16bit)
TimeDateStamp (32bit)
PointerToSymbolTable (32bit)
NumberofSymbols (32bit)
SizeofOptionalHeader (16bit)
Characterisics (16bit)
Each value is stored in 'little endian' byte order, meaning we need to flip the bytes to get the proper
value.
For the purpose of analysis the only value of interest is the TimeDateStamp. The value in this 32bit
container is set by the linker at the time of linking and is NOT always set properly. But by standard
this value equates to the number of seconds since January 1 1970 00:00:00. In order to find the
TimeDateStamp container we must first locate the beginning of the PE header.
Lets look at the PE HEADER for binA:
This 4byte/32bit container consists of the 2byte string "PE" followed by 2 null bytes. Now follow
along:
2 byte container for the value of Machine: 4c 01, after flipping it becomes 0x14c
2 bytes for NumberofSections: 04 00, 0x4
4 bytes for our TimeDateStamp: 00 00 00 00, 0x0
Apparently there is no TimeDateStamp in binA. At the time of writing I am unaware of any likely reason
for this and can only assume that either A) the linker our malcoder used didn't implement a proper stamp
or B) our malcoder removed the stamp.
Lets look at binB:
I've highlighted the PE HEADER, again follow along:
2 byte container for the value of Machine: 4c 01, 0x14c
2 bytes for NumberofSections: 09 00, 0x9
4 bytes for out TimeDateStamp: FB 3C 11 42, 0x42113cfb
We convert our value (0x42113cfb) to decimal: 1108425979
As I've said, this number represents the number of seconds since January 1 1970 00:00:00.
Therefore, assuming validity of this stamp, the file was created, or more specifically 'linked',
on Feb 14 2005 at 19:06:19 GMT
The first thing that seems to be worthy of note is the SECTION TABLE of binA.
Note the string 'BJFnt'. This is the name given to a PE SECTION, definately not one I've seen before.
Running it through google, we find that BJFnt is an executable packer. Essentially, 'packers' compress
executable files so that they can be decompressed at runtime. The end result is that the overall
filesize is smaller, but more importantly for a malware writer the content of the entire file is
modified, and therefore any strings that may have appeared in the original binary are now unreadable
by an analyst.
After seperating binA and binB my antivirus (AVG) recognizes binA as Bropia.J but we will continue
analysis regardless.
(continue)