Summerschool Aachen 2004/Incident Research Lab
Contents
Notes on Presentations
Notes on Lab Session
Analyzing the content of an old hard drive and the content of a downloaded FAT16 image
We first took a used Maxtor 90845d4 8GB (S26361-H435-V100, SAM-2004-10-04-I) hard drive and built it in into our box for external hard drives (photos of that will be available soon). Then we used the command cat /dev/sda | strings > strings.txt in order to write all the strings contained in the image into the file called strings. The image contained a lot of strings, among other things several Windows log-in passwords. We also found a lot of text about inventories and customer data which made us guess that the hard drive was used in a company before. We later found out from Max that the hard drive was used by a computer shop before. On the hard drive there was a HPFS/NTFS filesystem installed. As we wanted to play around a little bit more with the content of that hard drive we decided to copy it to another external hard drive, mount it and further analyze its content. Copying the image from one hard drive to another took us almost three and half hours...After that we tried to mount the partition on the copied image which unfortunately didn't work out. We should have just copied the partition from the image instead of the whole image. But it was too late by the time we had realized this... During the time the image was copied we did several different things: - we took out an scsi hard drive from a Sparc 5 workstation and build it in with an scsi controller into another computer from the laboratory. - we downloaded an image and analyzed its content: There was a password protected zip file which we opened using a zip cracking tool and using the image itself as a dictionary. The password was found very easily and we could read the secret message...
--Samad Nasserian, Boris Leidner
Software packages you might find useful
You might want to look into the following tools:
- graverobber - grab important data from system
- ddrescue - spiced up dd
- sleuthkit, autopsy - forensic toolkit (includes inode cat, ...)
- fcrackzip - zip password cracker
- nasm - netwide disasembler
- e2undel - undelete for ext2
- ntfstools - undelete for ntfs
- bview - nice hex editor, vim-like
- bsdmainutils (includes hd), or vim (includes xxd)
- chntpw - reset windows passwords, browse registry
Have a look at the Links page!
Images to look at
Forensic Imaging Best Practice
1. get a disk and ensure that there is a ID on that disk. IDs should look like UU-YYYY-MM-DD-X where UU is your user ID, YYYY, MM, DD represent the date and X is a roman number used as a serial number to distinguish several hard disks you image in one day. So I might use something like md-2004-10-04-I as an ID. Write it on the disk with marker and create a directory with the same name for your evidence data.
2. Connect the disk to your computer. You might want to try to remove the original disk from one of our external USB disk and put in the disk to image. We find that "real" IDE and SCSI works better.
3. Go to you evidence directory and create a file like md-2004-10-04-I.txt where you note model, serial number manufacturer, etc. of the HD, other noteworthy thinks, your name and actual time. Then create the image with something like dd if=/dev/hdX of=./md-2004-10-04-I.image
4. Upload the your whole evidence directory to ftp://discovery.informatik.rwth-aachen.de/incoming/DiskImages/
5. Now start analyzing the Image, add your observations to the evidence directory and upload missing stuff when done.
Lab Session today
Today I started with analysing the challenge Max gave to us. The first thing I've done after checksuming the image was to mount it, extract the three files and used a tool for cracking the Zip-archive. After an attack with a word-list didn't work out and I got bored by staring at the screen while the computer was performing a brute-force search for the password, I aborted it when it finished the exhaustive search for passwords of length 5.
Afterwards I tried the Sleuth Kit together with Autopsy to search for deleted or hidden stuff in the filesystem and it worked quite well. It is always a pleasure to have the right tools (which also includes a hex-editor). Overall a nice challenge, I especially like these hidden motivations like "good job" or "well done". :)
In the afternoon I tried to optimise our project from last week, the java application which displays a wardriving session. Though we worked only two days on it, the program is already better than gpsmap (to my view), or it least will be when a few missing features will be implemented. I didn't get to manage to speed up the displaying performance, but I learned that a java application might keep on running after a NullPointerException.
--Jan Gall
playing around with images
For the labsession we had gotten a 30 megabyte image from a flash- card. The first thing I did was run file over it, the reply from file was:
LabAssignment.image: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0", sectors/cluster 4, root entries 512, sectors 62560 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 61, heads 4, hidden sectors 32, serial number 0x1d6615db, unlabeled, FAT (16 bit)
Then I did a strings on it. Some of the things I saw were "canon digital IXUS" which turned out to be the type of the flash card being used. I also saw some directory listing of some image files. That's about all the usefull things I got out of strings.
Then I mounted the image (which wasn't a problem since I had another copy of the image, incase something got damaged). It gave me 3 files:
-rwxr--r-- 1 ilja ilja 7.3K Oct 4 11:30 Secrit.exe* -rwxr--r-- 1 ilja ilja 553K Oct 4 11:29 dcim* -rwxr--r-- 1 ilja ilja 329 Oct 4 11:28 meeting.pst*
file gave me some more information:
Secrit.exe: Microsoft Office document data dcim: JPEG image data, EXIF standard 0.73, 10752 x 2048 meeting.pst: Zip archive data, at least v2.0 to extract
Secrit.exe is password protected, so is meeting.pst. I found a program that extracted some data out of EXIF files, but found nothing interesting.
Then I decided to use a tool called autopsy which is a frontent for another tool called sleuthkit. When I examined the the image file with autopsy I found some more files that were previously deleted. The first one I found was a jpeg file:
images-LabAssignment.image-home.ilja.mnt._CIM.: JPEG image data, EXIF standard 0.73, 10752 x 2048
I then saw if something might be encoded in there:
../images-LabAssignment.image-home.ilja.mnt._CIM. : negative
Nothing there (as it turns out the picture itself was sort of a decoy). So I looked further into the delted files and found 2 word documents who look very simular. I extracted both. One seemed to be password protected, The other however wasn't. It contained a password (the password for the meeting.pst) "Well done!". When I entered that as a password for the meeting.pst file, it extracted a file called Xstuff.mov. I first tried to play it with mplayer, but that didn't work. then I did a list of the file:
-rw-r--r-- 1 ilja ilja 146 Oct 4 01:24 Xstuff.mov
So there is no way that this is a movie. So I ran it true file:
Xstuff.mov: Big-endian UTF-16 Unicode English character data, with no line terminators
Then I did a cat and pipe it to xxd:
0000000: feff 0054 0068 0065 0020 0073 0065 0063 ...T.h.e. .s.e.c 0000010: 0072 0065 0074 0020 006d 0065 0065 0074 .r.e.t. .m.e.e.t 0000020: 0069 006e 0067 0020 0077 0069 006c 006c .i.n.g. .w.i.l.l 0000030: 0020 0074 0061 006b 0065 0020 0070 006c . .t.a.k.e. .p.l 0000040: 0061 0063 0065 0020 0061 0074 0020 0057 .a.c.e. .a.t. .W 0000050: 0065 0064 006e 0065 0073 0064 0061 0079 .e.d.n.e.s.d.a.y 0000060: 0020 006f 006e 0020 0074 0068 0065 0020 . .o.n. .t.h.e. 0000070: 0074 006f 0070 0020 006f 0066 0020 0074 .t.o.p. .o.f. .t 0000080: 0068 0065 0020 0074 0068 0069 006e 0067 .h.e. .t.h.i.n.g 0000090: 002e ..
So there is the answer to the question that isn't documented (as far as I knowI was unable to find a .pdf or something on Max's homepage that asked questions about these evil people). From the forensics evidence it also showed that most of these files were produced on a mac and the name 'Maximillian Dornseif' kept popping up for some odd reason :).
As a side note, I came up with 2 more possible ways to get the answer, The first is to look at the password protected word file and just change the password hash in it. I haven't actually done that today, but I know it's possible, I had done it once a while ago with some document for school.
The second was to attack the encryption used to encrypt the zip file. Apparenty the pkzip algorithm was used. And this is known to be broken. After some googling I came up with a program called pkcrack which allowes you to find the password with a known plaintext attack. So I came up with a few assumptions that probably allows you to recover the password. The plaintexts that I'd probably choose would be: secret, meeting and place. Then ofcourse you'd still need to figure out to use unicode, but I suppose you'd figure that out after a while.
I spend the latter part of the afternoon with making an image of one of the hard disks and anaysing that.
There were these great devices given to us that allowed you to put a hard disk in them and then hook it up to your laptop with usb. Seems easy doesn't it. Unfortunatly that wasn't the case. I tried it with one hard disk for about 2 hours but nothing seemed to work.
My kernel did detect that something was being connected to one of the usb ports, but beyond that nothing happend:
Oct 4 14:14:35 nikita kernel: hub.c: USB hub found Oct 4 14:14:35 nikita kernel: hub.c: 3 ports detected Oct 4 14:14:35 nikita kernel: hub.c: new USB device 00:01.3-2, assigned address 2 ... Oct 4 14:31:24 nikita usb.agent[899]: missing kernel or user mode driver usb-storage ...
So for some reason that cool gadget that allowed me to use the harddisk didn't want to play with me. After looking for the problem for 2 hours I finaly found out that it wasn't the cool gadget that didn't want to play, it was the hard disk itself. Apparently they are too old. Max then provided me with a system of his own on which I could hook up this hard disk directly (using an ide cable). This worked like a charm. Taking the image took 10 minutes, I put it on my box with ftp and halted Max's machine.
When Cpunkt Wanted to do the same all the suddon the hard disk in Max's box died, we were unable to get it back to work :(.
Anyways, When I looked at the image with autopsy it didn't see it as a FAT16 or some other filesystem, So after some playing with autopsy I figured I'll just let it see it as a 'raw' image. When I did some further invstigation it turned out that I had also copied the master boot record and hence it didn't get recognized as a FAT 16 image:
img: x86 boot sector, MS-DOS MBR, german version 5.00 to 4.00.950
So after determining where the MBR ended and the FAT16 started I did another dd and got the actual FAT16 image:
img2: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0", sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 249, heads 15, hidden sectors 17, sectors 254983 (volumes > 32 MB) , serial number 0x1add4063, label: "MS-DOS_5 " , FAT (16 bit)
Then I also mounted the image:
root@nikita:/home/ilja#mount img2 /home/ilja/mnt -o loop root@nikita:/home/ilja#cd /home/ilja/mnt root@nikita:/home/ilja/mnt#ls -alhp total 36K drwxr--r-- 2 root root 16K Jan 1 1970 ./ drwxr-xr-x 120 ilja ilja 20K Oct 4 17:41 ../ root@nikita:/home/ilja/mnt#
It seemed kinda odd to me that there wasn't a single file there. Then I decided to look at the root directory entry with autopsy:
0 00000000 00000000 00000000 00000000 .... .... .... .... 16 00000000 00000000 00000000 00000000 .... .... .... .... 32 00000000 00000000 00000000 00000000 .... .... .... .... 48 00000000 00000000 00000000 00000000 .... .... .... .... 64 00000000 00000000 00000000 00000000 .... .... .... .... 80 00000000 00000000 00000000 00000000 .... .... .... .... 96 00000000 00000000 00000000 00000000 .... .... .... .... 112 00000000 00000000 00000000 00000000 .... .... .... .... 128 00000000 00000000 00000000 00000000 .... .... .... .... 144 00000000 00000000 00000000 00000000 .... .... .... .... 160 00000000 00000000 00000000 00000000 .... .... .... .... 176 00000000 00000000 00000000 00000000 .... .... .... .... ...
Hm, the guy who sold the hard disk had apparently deleted everything on it, what a bummer. Though I decided to look a little deeper into it. I started looking at the Image sector per sector (I did 1-1100 or something) and it appeared that most data was still on the harddisk. It was just warked as being gone. I recovered files like command.com, autoexec.bat and some more stuff, there wasn't much interesting on the hard disk. It was still fun to see how a hard disk where everything appears to be deleted is still filled with information. Just as proof, here is the autoexec.bat file:
@ECHO Off PATH C:\MOUSE;c:\;C:\NWDOS;C:\WINDOWS;C:\MOUSE;C:\NC;C:\DB\DB3;C:\NU;C:\WINDOWS\SYSTEM MOUSE SET CBACKUP=C:\CBEDOS PATH=C:\CBEDOS;%PATH% APPEND C:\ra6 PROMPT $p$g LH /L:1,35536 MOUSE LH /L:0;1,45968 /S C:\WINDOWS\SMARTDRV.EXE /X 1024 128 SET TEMP=c:\nwdos\temp KEYB GR+ VERIFY OFF c:\mouse\mouse IF NOT DIREXIST %TEMP% MD %TEMP% SET NWDOSCFG=C:\NWDOS\temp SET FBP_USER=Baupha GmbH Groáschnau loadhigh C:\NWDOS\SHARE /L:100 /F:17060 c:\skeybgr copy c:\nc\nc.ver c:\nc\nc.ini
I considered this to be a very successfull labsession. I leared quite a lot.
