HoneyNet Scan of the Month October -- Scan 24
Project submission by the CERIAS Computer Forensics Research Group
Analysis
Our analysis was performed on a Pentium III based Laptop running
Debian 3.0.
We started by downloading the image from the HoneyNet web site at
http://www.honeynet.org/scans/scan24/image.zip .
Then the MD5 checksum of the image was generated and it matched the
checksum provided with the image:
florian@schlaraffenland:~/honeynet> md5sum image.zip
b676147f63923e1f428131d59b1d6a72 image.zip
After unzipping the image, we decided to first mount the image
via the loopback device to a local directory and examine if there
was anything useful there.
schlaraffenland:/home/florian/honeynet # mount -o loop image mnt/
schlaraffenland:/home/florian/honeynet # ll mnt/
total 25
drwxr-xr-x 2 root root 7168 Dec 31 1969 .
drwxr-xr-x 4 florian users 992 Oct 22 22:20 ..
-rwxr-xr-x 1 root root 15585 Sep 11 08:30 cover page.jpgc
-rwxr-xr-x 1 root root 1000 May 24 08:20 schedu~1.exe
Trying to open the file 'cover page.jpgc' in an image viewer resulted
in an error, and since we were operating on a Linux computer we
didn't try anything with the .exe file for now.
Next, we performed a 'strings' command on the image. This yielded
a very large amount of useful information already. In addition to the
two file names 'COVERP~1JPG' and 'SCHEDU~1EXE', a third file name,
'IMMYJ~1DOC', hinted at the existence of a (deleted?) Word document.
This suspicion was confirmed as the entire text portion of the document
as well as some Word formatting strings were shown a little further
down in the 'strings' output. Furthermore, the string 'pw=goodtimes'
could be some sort of password configuration or reminder. Finally,
the two strings 'Scheduled Visits.xls' and 'Scheduled Visits.xlsPK'
hint at the presence of some Excel file somewhere on the disk, possibly
in PK-zip format. As there is too much other junk in the output of
the 'strings' command we limit ourselves to only show the text
portion of the supposed Word document:
Jimmy Jungle
626 Jungle Ave Apt 2
Jungle, NY 11111
Jimmy:
Dude, your pot must be the best
it made the cover of High Times Magazine! Thanks for sending me the Cover Page.
What do you put in your soil when you plant the marijuana seeds? At least I kno
w your growing it and not some guy in Columbia.
These kids, they tell me marijuana isn
t addictive, but they don
t stop buying from me. Man, I
m sure glad you told me about targeting the high school students. You must have
some experience. It
s like a guaranteed paycheck. Their parents give them money for lunch and they s
pend it on my stuff. I
m an entrepreneur. Am I only one you sell to? Maybe I can become distributor of
the year!
I emailed you the schedule that I am using. I think it helps me cover myself and
not be predictive. Tell me what you think. To open it, use the same password t
hat you sent me before with that file. Talk to you later.
Thanks,
Joe
As a next step we utilized Brian Carrier's excellent
Autopsy
Forensic Browser to further investigate the image. After
copying the image to the autopsy server's morgue directory and
starting the autopsy server we were able to use a web browser
to look at the file system.
The file browsing mode of Autopsy showed three files present on the
system: cover page.jpgc(COVERP~1.JPG),
Jimmy Jungle.doc(_IMMYJ~1.DOC), which was marked as deleted,
and Scheduled Visits.exe(SCHEDU~1.EXE). Clicking on the file
names to show the file contents produced junk for the first two files.
The .exe file had a PK-zip header, leading us to believe that that
file is a self-extracting zip archive. This was further confirmed by
executing the 'file' command on the file from the mounted image:
florian@schlaraffenland:~/honeynet/mnt> file schedu~1.exe
schedu~1.exe: Zip archive data, at least v2.0 to extract
However, trying to unzip the file with 'unzip' produced an error
"End-of-central-directory signature not found". We then decided to
investigate the three files individually
The JPEG file
In Autopsy we performed a keyword
search for the string 'JFIF', which should be a string found at
byte 6 of each JPEG image. The search reported one occurrence of
'JFIF' found at block 73 of the image, with an offset of 6 bytes.
Thus block 73 had to be the start of a JPEG file. We now went into
Autopsy's data browsing mode and displayed the block allocation list.
The list showed that blocks 0 through 32 were allocated, blocks
33 through 72 were free, blocks 73 through 108 allocated again,
and the remainder of the blocks free. Given that the JPEG file
starts at block 73, the first one of a range of allocated blocks,
we copied out that range to a file via 'dd':
dd skip=73 bs=512 count=36 if=image of=cover.jpg
We were now able to view the file in an image viewer. But when
we further examined the file 'cover.jpg' with hexdump, we
noticed that there is a block of zeroes at address 0x3ce0 and
following, the string "pw=goodtimes" at address 0x3d20,
and the start of the PK-zip file at address 0x3e00 (all addresses
relative to the beginning of the JPEG file). As byte 0x3e00
marks the beginning of block 31 within the image, we need only
copy 31 instead of 36 blocks to copy out all the blocks that
belong to the JPEG image:
dd skip=73 bs=512 count=31 if=image of=cover.jpg
The last end-of-file marker for the image 'ff d9' ends at
address 0x3ce0 (15584), and 15585 is the length listed for the
file in the directory. If one only wanted to copy out the file,
one can do the following:
dd skip=37376 bs=1 count=15585 if=image of=cover.jpg
But this way the "pw=goodtimes" string in the slack space is
lost! As a matter of fact, there is an earlier end-of-file
JPEG marker located ending at address 0x2231 (8753). A
dd skip=37376 bs=1 count=8754 if=image of=cover.jpg
produces a file 'cover.jpg' that looks just like the larger ones.
This is our strongest clue for the bonus question, but we
do not have enough knowledge about image manipulation software
to be able to identify what product simply places EOF markers
in the middle of files, keeping the JPEG file artificially large.
The PK-zip archive
Given that the last 5 blocks that we initially copied out with
'dd' for the JPEG file didn't actually belong to it and the first
of them (block 104 of the image) contained the beginning of the
PK-zip file, we examined the last block of the five (block 108)
of the image with Autopsy and found the string
'Scheduled Visits.xlsPK' toward the end. Thus
dd skip=104 bs=512 count=5 if=image of=schedule.exe
copied out all the blocks belonging to the PK-zip file. Again,
the actual file is only 2420 bytes large (not the 2560 that
the 5 blocks occupy) -- the size of 2420 was found by trying the
smallest file size under which the file was successfully unzipped.
Thus to only copy the file data, one can use:
dd skip=53248 bs=1 count=2420 if=image of=schedule.exe
Unzipping the file with 'unzip' now prompted us for a password
and after typing in 'goodtimes' the Excel spreadsheet file
'Scheduled Visits.xls' was extracted. We were able to view the
document via Excel through a Windows session started by a Citrix
server.
The Word document
Since word file was deleted from the floppy and there was a chunk of
free blocks from block 33 to 72, that we saw in Autopsy's allocation
list in between chunks of allocated blocks, we simply copied out that
range of free blocks:
dd skip=33 bs=512 count=40 if=image of=jimmy.doc
The resulting file 'jimmy.doc' appears to be a valid word file,
which could be viewed with 'kword'.
Answers to the Questions
1. Who is Joe Jacob's supplier of marijuana and what is the address listed for the supplier?
Joe Jacob's supplier of marijuana is Jimmy Jungle, and the address
listed is as follows:
626 Jungle Ave Apt 2
Jungle, NY 11111
2. What crucial data is available within the coverpage.jpg file and why is this data crucial?
Technically, the crucial data is not part of the file itself, but
rather is found in the unallocated slack space of the file's
ending block. There the string "pw=goodtimes" can be found.
This data is crucial as it is the password used to uncompress
the password protected PK-zip file, which contains the schedule
with the times and locations of the schools the drug dealer visits.
3. What (if any) other high schools besides Smith Hill does Joe Jacobs frequent?
In addition to Smith Hill High School, Joe also frequents
Key High School, Leetch High School, Birard High School,
Richter High School, and Hull High School.
4. For each file, what processes were taken by the suspect to mask them from others?
The .exe file
The actual PK-zip file was password protected with the password
"goodtimes". However, one could still see that the file that was
contained in the archive was "Scheduled Visits.xls". Furthermore,
since the password contains only letters it might be vulnerable
to a dictionary password cracking attack.
In addition to the password protection, however, the actual length
of the file was truncated in the directory entry. The following
shows the hexdump output for the entry with the relevant bytes
highlighted:
| 000026c0 | | 42 | 69 | 00 | 74 | 00 | 73 | 00 | 2e | 00 | 65 | 00 | 0f | 00 | 9e | 78 | 00 | | B | i | . | t | . | s | . | . | . | e | . | . | . | . | x | . |
| 000026d0 | | 65 | 00 | 20 | 00 | 20 | 00 | 20 | 00 | 20 | 00 | 00 | 00 | 20 | 00 | 20 | 00 | | e | . | | . | | . | | . | | . | . | . | | . | | . |
| 000026e0 | | 01 | 53 | 00 | 63 | 00 | 68 | 00 | 65 | 00 | 64 | 00 | 0f | 00 | 9e | 75 | 00 | | . | S | . | c | . | h | . | e | . | d | . | . | . | . | u | . |
| 000026f0 | | 6c | 00 | 65 | 00 | 64 | 00 | 20 | 00 | 56 | 00 | 00 | 00 | 69 | 00 | 73 | 00 | | l | . | e | . | d | . | | . | V | . | . | . | i | . | s | . |
| 00002700 | | 53 | 43 | 48 | 45 | 44 | 55 | 7e | 31 | 45 | 58 | 45 | 20 | 00 | 53 | 53 | 46 | | S | C | H | E | D | U | ~ | 1 | E | X | E | | . | S | S | F |
| 00002710 | | 2b | 2d | 2b | 2d | 00 | 00 | 90 | 42 | b8 | 2c | 49 | 00 | e8 | 03 | 00 | 00 | | + | - | + | - | . | . | . | B | ¸ | , | I | . | è | . | . | . |
The marked bytes indicate a length of 1000 bytes. To fix this,
the value should be changed to 2560 bytes (00 0a 00 00) or
to 2420 (74 09 00 00). Please see the above analysis part
for the reasoning about the file length.
The JPEG file
This file's directory entry was also modified:
| 00002660 | | 42 | 67 | 00 | 63 | 00 | 20 | 00 | 20 | 00 | 20 | 00 | 0f | 00 | f4 | 20 | 00 | | B | g | . | c | . | | . | | . | | . | . | . | . | | . |
| 00002670 | | 20 | 00 | 20 | 00 | 20 | 00 | 20 | 00 | 20 | 00 | 00 | 00 | 20 | 00 | 20 | 00 | | | . | | . | | . | | . | | . | . | . | | . | | . |
| 00002680 | | 01 | 63 | 00 | 6f | 00 | 76 | 00 | 65 | 00 | 72 | 00 | 0f | 00 | f4 | 20 | 00 | | . | c | . | o | . | v | . | e | . | r | . | . | . | . | | . |
| 00002690 | | 70 | 00 | 61 | 00 | 67 | 00 | 65 | 00 | 2e | 00 | 00 | 00 | 6a | 00 | 70 | 00 | | p | . | a | . | g | . | e | . | . | . | . | . | j | . | p | . |
| 000026a0 | | 43 | 4f | 56 | 45 | 52 | 50 | 7e | 31 | 4a | 50 | 47 | 20 | 00 | 6d | 4d | 46 | | C | O | V | E | R | P | ~ | 1 | J | P | G | | . | m | M | F |
| 000026b0 | | 2b | 2d | 2b | 2d | 00 | 00 | da | 43 | 2b | 2d | a4 | 01 | e1 | 3c | 00 | 00 | | + | - | + | - | . | . | . | C | + | - | . | . | . | < | . | . |
The two highlighted bytes make up the first cluster number
for the file. The indicated cluster number 420 points into
a large sequence of continuous bytes with the value 0xf6.
To compute the correct cluster number, we need to take the
first block on the floppy that belongs to the file (73).
The first 33 blocks on the image are reserved for the boot
sector (block 0), the first FAT table (blocks 1-9), the
second FAT table (blocks 10-18), and the root directory
(blocks 19-32). Also, the first 2 clusters (0 and 1) are
reserved. Thus cluster number 2 starts at block 33.
This makes block 73 identical to cluster 42. To fix the
directory entry, the highlighted bytes need to be changed
to 2a 00.
The long file name of the JPEG file is also messed up as
it lists the file's suffix as ".jpgc" followed by numerous
spaces and special characters. While this seems odd it doesn't
really mask the contents from anyone.
The Word document
First of all, the file was deleted from the floppy. This shows
in the file's directory entry as follows:
| 00002600 | | e5 | 64 | 00 | 6f | 00 | 63 | 00 | 00 | 00 | ff | ff | 0f | 00 | bc | ff | ff | | å | d | . | o | . | c | . | . | . | ÿ | ÿ | . | . | ¼ | ÿ | ÿ |
| 00002610 | | ff | ff | ff | ff | ff | ff | ff | ff | ff | ff | 00 | 00 | ff | ff | ff | ff | | ÿ | ÿ | ÿ | ÿ | ÿ | ÿ | ÿ | ÿ | ÿ | ÿ | . | . | ÿ | ÿ | ÿ | ÿ |
| 00002620 | | e5 | 4a | 00 | 69 | 00 | 6d | 00 | 6d | 00 | 79 | 00 | 0f | 00 | bc | 20 | 00 | | å | J | . | i | . | m | . | m | . | y | . | . | . | ¼ | | . |
| 00002630 | | 4a | 00 | 75 | 00 | 6e | 00 | 67 | 00 | 6c | 00 | 00 | 00 | 65 | 00 | 2e | 00 | | J | . | u | . | n | . | g | . | l | . | . | . | e | . | . | . |
| 00002640 | | e5 | 49 | 4d | 4d | 59 | 4a | 7e | 31 | 44 | 4f | 43 | 20 | 00 | 68 | 38 | 46 | | å | I | M | M | Y | J | ~ | 1 | D | O | C | | . | h | 8 | F |
| 00002650 | | 2b | 2d | 2b | 2d | 00 | 00 | 4f | 75 | 8f | 2c | 02 | 00 | 00 | 50 | 00 | 00 | | + | - | + | - | . | . | O | u | . | , | . | . | . | P | . | . |
The byte e5 at address 0x02640 indicates that file
was deleted. The value needs to be changed back to 4a ("J")
-- actually any valid character would work. However, this did not
fix the problem so we examined the cluster number, which pointed correctly
at cluster number 2, and the file size (20480 bytes) was also correct.
We therefore further looked at the file allocation table (FAT) and found
that the entries for clusters 2 through 41 had the value of 0:
| 00000200 | | f0 | ff | ff | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | ð | ÿ | ÿ | . | . | . | . | . | . | . | . | . | . | . | . | . |
| 00000210 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| 00000220 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| 00000230 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 2b | | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | + |
| 00000240 | | c0 | 02 | 2d | e0 | 02 | 2f | 00 | 03 | 31 | 20 | 03 | 33 | 40 | 03 | 35 | 60 | | À | . | - | à | . | / | . | . | 1 | | . | 3 | @ | . | 5 | ` |
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
The second FAT starting at address 0x1400 looks exactly the same.
So, the FAT entry for the file had been zeroed out. Given this, we can say
we were lucky that all clusters for the file were in one continuous range.
To reconstruct the FAT entry, one needs to consider that 2 clusters share
3 bytes. Given six half-bytes 123456, they belong to the cluster numbers AB
in the following fashion:
412: A
563: B
Also, the actual FAT entry for a cluster is the next cluster it points to
with the very last entry being 0xfff. Thus the correct FAT entry
for the file for both FAT1 and FAT2 needs to look like this:
| 00000200 | | f0 | ff | ff | 03 | 40 | 00 | 05 | 60 | 00 | 07 | 80 | 00 | 09 | a0 | 00 | 0b | | ð | ÿ | ÿ | . | @ | . | . | ` | . | . | . | . | . | | . | . |
| 00000210 | | c0 | 00 | 0d | e0 | 00 | 0f | 00 | 01 | 11 | 20 | 01 | 13 | 40 | 01 | 15 | 60 | | À | . | . | à | . | . | . | . | . | | . | . | @ | . | . | ` |
| 00000220 | | 01 | 17 | 80 | 01 | 19 | a0 | 01 | 1b | c0 | 01 | 1d | e0 | 01 | 1f | 00 | 02 | | . | . | . | . | . | | . | . | À | . | . | à | . | . | . | . |
| 00000230 | | 21 | 20 | 02 | 23 | 40 | 02 | 25 | 60 | 02 | 27 | 80 | 02 | 29 | ff | 0f | 2b | | ! | | . | # | @ | . | % | ` | . | ' | . | . | ) | ÿ | . | + |
| 00000240 | | c0 | 02 | 2d | e0 | 02 | 2f | 00 | 03 | 31 | 20 | 03 | 33 | 40 | 03 | 35 | 60 | | À | . | - | à | . | / | . | . | 1 | | . | 3 | @ | . | 5 | ` |
5. What processes did you (the investigator) use to successfully examine the entire contents of each file?
The analysis section above and our answer to Question 4 should describe
the processes sufficiently.
Appendix
Tools used
Autopsy Forensic File Browser
dd
strings
hexdump
khexedit
unzip
file
kword
MS Excel
References
"FAT: General Overview of On-Disk Structure", Microsoft Corporation,
http://www.nondot.org/sabre/os/files/FileSystems/FatFormat.pdf
People
The members of the CERIAS Computer Forensics Research Group can be found
here