P. 1
A Practitioner's Guide to Linux as a Computer Forensic Platform

A Practitioner's Guide to Linux as a Computer Forensic Platform

|Views: 2,297|Likes:
Published by jformica
The law enforcement and forensic examiner's introduction to Linux.
The law enforcement and forensic examiner's introduction to Linux.

More info:

Published by: jformica on Jul 12, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/04/2013

pdf

text

original

At this point we've done a couple of intermediate exercises using an
ext2 file system from a Linux disk image.  Another common suggestion I receive
in class feedback and from other users of this guide is to provide a more
advanced exercise using a file system more commonly encountered by
examiners in the field.  So, in the following exercises we will do some simple
analyses on an NTFS file system.

Some might ask, “why?” There are many tools out there capable of
analyzing an NTFS file system in its native environment.  In my mind there are
two very good reasons for learning to apply the Sleuthkit on Windows file
systems.  First, the Sleuthkit is comprised of a number of separate tools with
very discrete sets of capabilities.  The specialized nature of these tools means
that you have to understand their interaction with the file system being
analyzed.  This makes them especially suited to help learning the ins and outs
of file system behavior.  The fact that the Sleuthkit does less of the work for you
makes it a great learning tool.  Second, an open source tool that operates in an
environment other than Windows makes for an excellent cross­verification
utility.

The following exercise follows a set of very basic steps useful in most any
analysis.  Make sure that you follow along at the command line.
Experimentation is the best way to learn.

If you have not already done so, I would strongly suggest (again) that
you invest in a copy of Brian Carrier's book: File System Forensic Analysis
(Published by Addison­Wesley, 2005).  This book is the definitive guide to file
system behavior for forensic analysts.  As a reminder (again), the purpose of
these exercises in NOT to teach you file systems (or forensic methods, for that
matter), but rather to illustrate the detailed information Sleuthkit can provide
on common file systems encountered by field examiners.

The file we will use for this exercise can be obtained from:

http://www.LinuxLEO.com/Files/ntfs_pract.dd.gz

Let's create a directory in our /root (the root user's home) directory
called /root/ntfs_pract/  and place the file in there.  First, we will decompress the
gzipped file using the gzip command we learned earlier and check its SHA1
hash:

Barry J. Grundy

163

v. 3.78                                         The Law Enforcement and Forensic Examiner's Introduction to Linux

Now we will run through a series of basic Sleuthkit commands as we
would in any analysis.  The structure of the forensic image is viewed using
mmls:

The output shows that an NTFS partition (and most likely the file
system) begins at sector offset 59.  This is the offset we will use in all our
Sleuthkit commands.  We now use fsstat to have a look at the file system
statistics inside that partition:

Barry J. Grundy

164

root@rock:~/ntfs_pract # ls
ntfs_pract.dd.gz
root@rock:~/ntfs_pract # gzip -d ntfs_pract.dd.gz
root@rock:~/ntfs_pract # ls
ntfs_pract.dd
root@rock:~/ntfs_pract # sha1sum ntfs_pract.dd
0cbce7666c8db70377cb5fc2abf9268821b6dafe ntfs_pract.dd

root@rock:~/ntfs_pract # fsstat -o 59 -f ntfs ntfs_pract.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: E4D06402D063D8F6
OEM Name: NTFS
Volume Name: NEW VOLUME
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 42625
First Cluster of MFT Mirror: 63937
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 144
Root Directory: 5

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096

root@rock:~/ntfs_pract # mmls ntfs_pract.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000058 0000000058 Unallocated
02: 00:00 0000000059 0001023059 0001023001 NTFS (0x07)
03: ----- 0001023060 0001023999 0000000940 Unallocated

v. 3.78                                         The Law Enforcement and Forensic Examiner's Introduction to Linux

Looking at the fsstat output on our NTFS file system, we see it differs
greatly from the output we saw running on a Linux EXT file system.   The tool is
designed to provide pertinent information based on the file system being
targeted.  Notice that when run on an NTFS file system, fsstat provides us with
information specific to NTFS, including data about the Master File Table (MFT)
and specific attribute values.

We will now have a look at how the Sleuthkit interacts with active and
deleted files on an NTFS file system, given the structure of MFT entries.

Let's begin this exercise with the output of fls.   We can specify that fls
only show us only “deleted” content on the command line with the ­d option.
We will use ­F (only file entries) and ­r (recursive) as well:

As of Sleuthkit version 3, the output of fls now shows content that
includes NTFS “orphan” files.20

Previous versions required the user to run an
additional command, ifind, on parent directories in order to recover orphan
files.  The article in the footnote explains how this works.

The output above shows that our NTFS example file system holds 7
deleted files.  Let's have a closer look at some NTFS specific information that
can be parsed with the Sleuthkit.

Have a look a the deleted file at MFT entry 112.  The file is  ./ My
Documents/My Pictures/bandit­streetortrack2005056.jpg .  We can have a closer
look at the file's attributes by examining its MFT entry directly.  We do this
through the istat tool.  Recall that when we were working on an EXT file system
previously, the output of istat gave us information directly from the inode of
the specified file (see Sleuthkit Exercise #1).  As we mentioned earlier, the
output of the Sleuthkit tools is specific to the file system being examined.  So
let's run the command on MFT entry 112 in our current exercise:

20

TSK Informer, issue #16: http://www.sleuthkit.org/informer/sleuthkit­informer­16.txt “NTFS Orphan Files”

Barry J. Grundy

165

root@rock:~/ntfs_pract # fls -Frd -o 59 ntfs_pract.dd
r/r * 42-128-1: Cookies/buckyball@revsci[2].txt
r/r * 43-128-1: Cookies/buckyball@search.msn[1].txt
r/r * 44-128-1: Cookies/buckyball@slashdot[1].txt
r/r * 45-128-1: Cookies/buckyball@sony.aol[2].txt
r/r * 112-128-4: My Documents/My Pictures/bandit-streetortrack2005056.jpg
r/r * 116-128-4: My Documents/My Pictures/fighterama2005-ban4.jpg
r/r * 81-128-4: My Documents/direct_attacks.doc

v. 3.78                                         The Law Enforcement and Forensic Examiner's Introduction to Linux

The information istat provides us from the MFT shows values directly
from the $STANDARD_INFORMATION attribute (which contains the basic
meta data for a file), the $FILE_NAME attribute and basic information for other
attributes that are part of an MFT entry.  The data blocks that contain the
actual file content are listed at the bottom of the output (for Non­Resident
data).

Take note of the fact that there are two separate attribute identifiers for
the $FILE_NAME attribute, 48­3 and 48­2.  It is interesting to note we can
access the contents of each attribute separately using the icat command.

The two attributes store the DOS (8.3) filename and the Win32 (long) file
name.  By piping the output of icat to xxd we can see the difference.  By itself,
this may not be of much investigative interest, but again we are illustrating the
capabilities of the Sleuthkit tools.

Barry J. Grundy

166

root@rock:~/ntfs_pract # istat -o 59 ntfs_pract.dd 112
MFT Entry Header Values:
Entry: 112 Sequence: 2
$LogFile Sequence Number: 4201668
Not Allocated File
Links: 2

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created:

Sat Apr 7 00:52:53 2007

File Modified:

Sat Oct 14 10:37:13 2006

MFT Modified:

Sat Apr 7 00:52:53 2007

Accessed:

Sat Apr 7 20:00:04 2007

$FILE_NAME Attribute Values:
Flags: Archive
Name: bandit-streetortrack2005056.jpg
Parent MFT Entry: 110 Sequence: 1
Allocated Size: 0

Actual Size: 0

Created:

Sat Apr 7 00:52:53 2007

File Modified:

Sat Apr 7 00:52:53 2007

MFT Modified:

Sat Apr 7 00:52:53 2007

Accessed:

Sat Apr 7 00:52:53 2007

Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-3) Name: N/A Resident size: 90
Type: $FILE_NAME (48-2) Name: N/A Resident size: 128
Type: $DATA (128-4) Name: $Data Non-Resident size: 112063
60533 60534 60535 60536 60537 60538 60539 60540
60541 60542 60543 60544 60545 60546 60547 60548
60549 60550 60551 60552 60553 60554 60555 60556
60557 60558 60559 60560

v. 3.78                                         The Law Enforcement and Forensic Examiner's Introduction to Linux

Note the difference in output between the attribute identifiers 112­48­3

and 112­48­2:

The same idea is extended to other attributes of a file, most notably the
“Alternate Data Streams” or ADS.   By showing us the existence of multiple
attribute identifiers for a given file, the Sleuthkit gives us a way of detecting
potentially hidden data.  We cover this in our next exercise.

Barry J. Grundy

167

root@rock:~/ntfs_pract # icat -o 59 ntfs_pract.dd 112-48-2 | xxd
0000000: 6e00 0000 0000 0100 3071 be99 d078 c701 n.......0q...x..
0000010: 3071 be99 d078 c701 3071 be99 d078 c701 0q...x..0q...x..
0000020: 3071 be99 d078 c701 0000 0000 0000 0000 0q...x..........
0000030: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
0000040: 1f01 6200 6100 6e00 6400 6900 7400 2d00 ..b.a.n.d.i.t.-.
0000050: 7300 7400 7200 6500 6500 7400 6f00 7200 s.t.r.e.e.t.o.r.
0000060: 7400 7200 6100 6300 6b00 3200 3000 3000 t.r.a.c.k.2.0.0.
0000070: 3500 3000 3500 3600 2e00 6a00 7000 6700 5.0.5.6...j.p.g.

root@rock:~/ntfs_pract # icat -o 59 ntfs_pract.dd 112-48-3 | xxd
0000000: 6e00 0000 0000 0100 3071 be99 d078 c701 n.......0q...x..
0000010: 3071 be99 d078 c701 3071 be99 d078 c701 0q...x..0q...x..
0000020: 3071 be99 d078 c701 0000 0000 0000 0000 0q...x..........
0000030: 0000 0000 0000 0000 2000 0000 0000 0000 ........ .......
0000040: 0c02 4200 4100 4e00 4400 4900 5400 7e00 ..B.A.N.D.I.T.~.
0000050: 3100 2e00 4a00 5000 4700 1...J.P.G.

v. 3.78                                         The Law Enforcement and Forensic Examiner's Introduction to Linux

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->