This  next section of code generates the list of IP addresses for the network and stores them in a dictionary (hash table) with a status of "no" indicating Vmware is not running on the host.

This section of code enumerates through the hosts and attempts to make a complete TCP connection on the host and port. A timeout is set to .5 seconds to help expedite the processing, if not it can take up to 60 seconds for each host. 

This section reads the banner information and checks for VMware, if the host checks out, the status in the dictionary is updated.

The final section of code enumerates through the dictionary and prints all of the found hosts.

Due to the timing I wanted to find anything that really stuck out, that maybe of use. For me tackling an unknown problem works best by trying the simple things first, looking for strings, patterns, large voids in the data etc. First I ran the Unix/Linux program Strings against the .doc file to see if anything sticks out. Generally for me this simple yet affect tool more often then not leads me in the right direction, or gives me an idea of what I need to start looking at. 

The image above is a simplified version of the document content. Based on the structures it was a Microsoft Word Document, but a few extra "goodies" were added for that special user.  We see lots of overflow content (0x40 : @) and the possible shellcode (more on that later), what really interested me is  the seemingly random string (00077696e6c6f67696e2e657865000). As you may already know Strings only displays the ASCII content in a file (thats plain old English for the uninitiated). Since this block of hex did not convert to ASCII in strings, this suggested it served another purpose in the document and needed a look (the previous flurry of  @ symbols also helped). What sticks out to me is, why the padding of zeros? Is this important? I think so.

Thats were WTF.py comes into play, deciphering hexadecimal usually is straightforward, a hex editor is all you need, then instant ASCII, but sometimes (situations like this)  each byte needs to be assembled first. The resulting string is winlogin.exe which is important, because winlogon.exe and not winlogin.exe is a part of the standard Microsoft Windows installation. 

For the first test, assume the 0x00 are just padding, easiest way to be sure is the hex string characters should total to an even number. The table below is broken down into four columns: 

File Hex - The two bytes of data in the payload.

File ASCII - The ACII string the two hex bytes represent.

Converted Hex - The hex formatted ASCII content.

Converted ASCII - The decoded ASCII character based on the previous data.

Doing something like this manually, although fun (depending on your definition) is time consuming and overflowing with opportunity to miss something or make a mistake; automating the process seems a lot more efficient.  There are tools available that can do this for you, a little googling and trial/error may find what you are looking for (Do you have the time, is it faster to write something?). The purpose of this exercise is to create my own tool. For this I am using Python and the binascii module. The binascii module is feature rich and can do most of the conversions for you in about four lines of code (which a friend showed me after). For the sake of argument, we do or did not know about binascii's cleverness. For me to fully grasp the problem, I broke it apart into individual steps or problems I needed to solve. The final solution had to be written in a way to be scriptable.