Scan of the Month Challenge 24 Analysis

The Honeynet Project Scan of the Month
Challenge 24 for October 2002
Analysis by Derek Marcotte <derekm@rogers.com>

Tools

Methodology

Jimmy Jungle.doc

cover page.jpgc

Scheduled Visits.exe

Questions

References

Listings

Thanks

Tools

Norton DiskEdit from Norton Utilites 6 (no version specific URL)

Encase v3.07

PKZip 2.04g

rawritent written by bhoc@pentagroup.ch

Serveral GNU utilities

Methodology

Download image.zip from the Honeynet website, and verify the md5 sum:

> md5 image.zip
B676147F63923E1F428131D59B1D6A72

Once we have verified the file has the same MD5 sum as the what website states, we can be reasonably assured that the file has not been modified. We may then proceed to decompress the image:

> pkunzip image.zip

We then write the image to a floppy disk, to be compatible with the functionallity of some windows programs, and to have a safe media to preform operations that will change the recovered image:

> rawritent image a

Immediately we aquire the image into EnCase 3. Now, let's take a look at what was written:

> dir a:
Volume in drive A has no label.
Volume Serial Number is C4B1-CDCF

Directory of A:\

09/11/2002 08:30a 15,585 cover page.jpgc
05/24/2002 08:20a 1,000 SCHEDU~1.EXE
2 File(s) 16,585 bytes
0 Dir(s) 1,439,232 bytes free

Within EnCase, we see three files, "cover page.jpgc", "Jimmy Jungle.doc", and "Scheduled Visits.exe." "Jimmy Jungle.doc" was marked as deleted in the filesystem. Each of these files will be addressed individually.

Jimmy Jungle.doc

We can recover this file by using the UnErase option in EnCase.

To Undelete this file by hand, there are several steps. First we must determine the start and ending cluster. Second, the FAT table must be modified to show that data is there again. Third, we need to rename the directory entry "sIMMYJ~1.DOC" to "JIMMYJ~1.DOC", and re-attach the LFN entries.

To determine the start and ending cluster, we highlight "Jimmy Jungle.doc" in EnCase, and click on the first cluster with a black square around it. The status line tells us that the first cluster of the file is 2. We the click on the last cluster with a black square around it. The status line tells us that the last cluster of the file is 41.

To modify the FAT table I used Norton's DiskEdit from Norton Utilities 6. Although not very compatible with Windows 2000, it's very useful to look at the directory structure/FAT tables in a manner a little more intelligable than hex digits. We click on "Object\First FAT..." to begin editing. We also presume that the file's clusters are in sequential order, which would make sense if the file was simply copied over, or edited on the disk. Since the first cluster of the file is 2, and we are moving in sequential order, we mark in the FAT entry that maps to cluster 2, that the next cluster in the file is 3. Move to cluster 3, and mark 4. We do this until cluster 41, which we previously determined was the end of the file, which we mark accordingly. When writing the changes to disk, we must syncronise the FAT tables, so that they both show the space as allocated.

To modify the directory entry "sIMMYJ~1.DOC" click on "Object\Directory..." and choose A:\. The first character in the file name is an 8-bit ascii character. Change this from it's current character to "J". To be thorough, we will also reconnect the long file name entries. To do this we need to change their ordinal, from 165 (which signifies deletion) to the proper number. The ordinal specifies the order that the LFN entry appears in the file name. The entry "Jimmy Jungle." is the first string in order of the file name "Jimmy Jungle.doc", so we give it an ordinal of 1. "doc" is the second part, so we give it an ordinal of 2. We now reconnect the LFN entry "its.exe" to the file "schedu~1.exe" using the Tools\Attach LFN... option.

To be able to reproduce what we've done to recover only this file from the original image, I write protected the floppy at this point, and rebooted to FreeBSD. I then took an image of the modified disk using the command:

$ dd if=/dev/fd0 of=jimmy

Then I compared it to the original image with the command:

$ cmp -x image jimmy

The output is available here. The first column displays the offset in the file (the first byte being 0), the second column indicates the byte value in hex of the file named "image" the third indicates the byte value in the file named "jimmy". By modifying the "image" file with these changes, the file "Jimmy Jungle.doc" should now be accessable to read.

The destructive nature of these operations on our disk prompts me to start with a fresh image of the disk to recover the "cover page.jpgc" file.

cover page.jpgc

Going back into EnCase and selecting "cover page.jpgc," we see that it is allocated to a deleted cluster, and that no good data follows.

Looking back at the directory listing, we can see that the file is supposed to be much larger than 1 cluster (1 cluster = 512 bytes). It reports that the file size should be 15,585 bytes. We can also see a large number of contigious clusters marked as lost toward the beginning of the disk. By looking at the first cluster in the lost cluster chain, we see the tell-tale JFIF header indicating that this file is an image file. It makes sense that this is the data that should be attached to the file "cover page.jpgc." To do this we need to know the cluster number that the data starts at. We can see that the start of the chain is cluster 42. While examining the slack space on the end of the lost cluster chain, I notice a string "pw=goodtimes". By modifing the directory entry for "cover page.jpgc," we will re-attach these clusters to the filename.

Going into diskedit, we modify the starting cluster of the directory entry from 420 (decimal) to 42, the starting cluster of the lost clusters. The filename is now re-attached to the clusters.

Copying the file may pose difficulties for those using Windows, as the name contains trailing spaces. For simplicity, we rename the file using DiskEdit, we modify the LFN directory entry named "gc           ", and truncate it to "gc".

To be able to reproduce what we've done to recover only this file from the original image, I write protected the floppy at this point, and rebooted to FreeBSD. I then took an image of the modified disk using the command:

$ dd if=/dev/fd0 of=cvrpage

Then I compared it to the original image with the command:

$ cmp -x image cvrpage

The output is available here. The first column displays the offset in the file (the first byte being 0), the second column indicates the byte value in hex of the file named "image" the third indicates the byte value in the file named "cvrpage". By modifying the "image" file with these changes, the file "cover page.jpgc" should now be accessable to read.

The destructive nature of these operations on our disk prompts me to start with a fresh image of the disk to recover the "Scheduled Visits.exe" file.

Scheduled Visits.exe

Looking at the file "Scheduled Visits.exe" within EnCase, two things stand out immediately. First, the number of clusters that are allocated to the file would cover nearly twice the data that our directory listing has stated is in the file. Second the first two bytes of the file are not "MZ", or "PE" which are headers of executable files under Windows. Instead they are "PK" which indicates that this is a pkzipped file.

To recover the entire file, we need to modify it's directory entry to report the correct size. The first step is to determine the correct size. Although the standard for the ZIP file layout is publically available at: http://www.pkware.com/support/appnote.html, I decided to "wing it" first. I created a plain text file in with the command:

> copy con test.txt
this is a test
^Z
1 file(s) copied.

I then zipped it using pkzip 2.04g:

> pkzip test.zip test.txt
Creating ZIP: TEST.ZIP

Adding: TEST.TXT Storing ( 0%), done.

I then checked the file size:

> dir test.zip
Volume in drive C has no label.
Volume Serial Number is 74C2-CFF0

Directory of C:\

10/02/2002 07:00p 130 TEST.ZIP
1 File(s) 130 bytes
0 Dir(s) 3,451,695,104 bytes free

Using debug I viewed the binary contents of the file:

>debug test.zip
-d 100 181
0AE9:0100 50 4B 03 04 0A 00 00 00-00 00 74 97 42 2D 0F E4 PK........t.B-..
0AE9:0110 5D 8E 10 00 00 00 10 00-00 00 08 00 00 00 54 45 ].............TE
0AE9:0120 53 54 2E 54 58 54 74 68-69 73 20 69 73 20 61 20 ST.TXTthis is a
0AE9:0130 74 65 73 74 0D 0A 50 4B-01 02 14 00 0A 00 00 00 test..PK........
0AE9:0140 00 00 74 97 42 2D 0F E4-5D 8E 10 00 00 00 10 00 ..t.B-..].......
0AE9:0150 00 00 08 00 00 00 00 00-00 00 01 00 20 00 00 00 ............ ...
0AE9:0160 00 00 00 00 54 45 53 54-2E 54 58 54 50 4B 05 06 ....TEST.TXTPK..
0AE9:0170 00 00 00 00 01 00 01 00-36 00 00 00 36 00 00 00 ........6...6...
0AE9:0180 00 00 ..

We can see here that there is a trailing 5 null bytes after the last non-null byte. Using this method, I located the similar pattern within the last cluster within EnCase. I retain the size mentioned by EnCase (2420), and return to diskedit. I also modify the file size to be 2420. There are LFN entries for the file "Scheduled Visits.exe" that are not connected to the file "schedu~1.exe". To be thorough, I reconnect the LFN entry "its.exe" to the file "schedu~1.exe" using the Tools\Attach LFN... option.

Copying the file may pose difficulties for those using Windows, as the name contains trailing spaces. For simplicity, we rename the file using DiskEdit, we modify the LFN directory entry named "its.exe      ", and truncate it to "its.exe".

I then write the changes to disk, and write protect it.

At this point the file is accessable to Windows, so we copy it to a working folder to extract it:

>copy a:\*.exe .
a:\Scheduled Visits.exe
1 file(s) copied.

We've also determined that this is a zipped file, so we rename it to a name that would imply it's type:

> move "Scheduled Visits.exe" sched.zip

Now to extract the file (password protected) using pkunzip 2.04g:

>pkunzip -s sched.zip
Password ? *********
Searching ZIP: SCHED.ZIP
Inflating: Scheduled Visits.xls

I tried the password "goodtimes", because it seemed like a good place to start, being written in the slack space of "cover page.jpgc". This version renamed the file to schedule.xls, because it doesn't understand long file names. A newer version would correctly name the file, but I like 2.04g.

To be able to reproduce what we've done to recover only this file from the original image, I write protected the floppy at this point, and rebooted to FreeBSD. I then took an image of the modified disk using the command:

$ dd if=/dev/fd0 of=sched

Then I compared it to the original image with the command:

$ cmp -x image sched

The output is available here. he first column displays the offset in the file (the first byte being 0), the second column indicates the byte value in hex of the file named "image" the third indicates the byte value in the file named "sched". By modifying the "image" file with these changes, the file "Scheduled Visits.exe" should now be accessable to read.

Refrences

Nick DeBaggis' SotM 23 Entry borrowed formatting and layout. ;)

Listings