Identification Data Acquisition Data Recovery Analysis Reporting

[Figure-1: Forensics steps]

A brief about various Linux tools available

There are multiple Linux tools used for imaging and analysis of disks and drives. They also come as several distributions containing all necessary tools to carry out Forensics, e.g. BackTrack, FIRE, Knoppix-STD, Linux LEO, Penguin Sleuth. All of them have an excellent collection of tools required for forensics. Some useful tools we require: Image-acquiring tools: Dd, DdRescue, dc3dd, Aimage Data Recovery tools: Foremost, Magic Rescue,SafeCopy Forensics Analysis tools: bulk_extractor, Miss Identify, RegLookup, readpst Forensics suites: Autopsy, Sleuth Kit, PTK

As published elsewhere, the complete description of tools and their uses are out of scope of this article, we’ll be just using them for our forensics, as you may get a fair idea about them during our process. We shall be using BackTrack(BT) for our analysis. You could pretty much use any distribution available as all have mostly common necessary tools. You could use any normal Linux flavors such as Fedora, RedHat, and Ubuntu as well, but the advantage of using distributions like BT is that they already have a fair collection of these tools. Otherwise you may need to install them. To keep our work neat, clean, and easily understandable, we will create a few directories in order to organize the data. We may need one directory for collecting our proofs, and another directory to browse the suspected image of the disk. We shall redirect all of the results from our analysis to the proof directory. The location of the directories is completely arbitrary but I prefer them on the root’s home:

mkdir /evidence

Now make a directory where we’ll be doing our most of the analysis:

mkdir /mnt/investigation

Here we are creating the folder ‘investigation’ under ‘mnt’ directory, where we will mount all the external data for our investigation. You are completely free to create your own folder at any place; this is just for sake of better organization.

Acquire the image

Identify the machine which needs to be investigated, and take an image of the hard disk. You can capture the disk and connect to your forensics machine in order to take its image. The disk may be anything from a hard disk to a floppy. That way, you’ll have two copies of the suspected disk-one image as well as the physical disk itself. We’ll be examining both images one by one. The tool ‘dd’ can be used to take an image of the disk by using this command: dd if=<media/partition on a media> of=<image_file>, Example: dd if=/dev/sdc of=image.dd Here, we are taking image of the disk sdc and saving it as image.dd. You can give the image any name, and .dd is an extension just to denote that it’s an image taken through ‘dd’ tool. Now for this article, we’ll use sample test images already available on few open source sites such as http://dftt.sourceforge.net/ , http://pyflag.sourceforge.net or http://linuxleo.com/ etc. They list excellent test images in every format to carry out test forensics. Download any disk images and unzip it in the ‘evidence’ directory already created. I shall be using one of the images already downloaded from similar sites at my PC. This was created using the same command dd if=/dev/sdc of= pyflag_stdimage_0.1, where we have taken image of disk sdc [Figure-2]:

[Figure-2: List of sample images] Once you download the above image copy it in blank floppy disk, we may require it later on:

dd if= pyflag_stdimage_0.1 of=/dev/fd0

So, the image is copied into your floppy device(/dev/fd0). Now we have two copies, one in the /evidence directory and one in physical floppy device.

Image analysis

Now that an image has been captured, let’s mount the contents to see how we can use tools. We’ll mount it in our /investigation directory:

mount -o ro,noexec,loop pyflag_stdimage_0.1 /mnt/investigation

Here ‘ro’ and ‘noexec’ denotes that the file should be mounted as read-only and non-executable. Now switch over to /mnt/investigation directory, where you can browse through the file system of the disk image [Figure-3]:

[Figure-3: File system in the disk image] Now you can redirect the above output to a simple file and place it into your evidence directory. This file can be used for analyzing the files and their various attributes [Figure-4]. #ls -Ralit > /evidence/ListOfFiles

[Figure-4: Detailed listing of files] Using this list you can search for any specific file such as ‘.txt’ [Figure-5]:

grep txt ListOfFiles:

[Figure-5: Using grep to search specific files] Another useful command might be for checking the file types. This would be useful in the scenarios where file extensions are modified. So if any .txt file is modified as a .jpg, the grep command won’t be able to find it. Go to your investigation folder and provide the following command and again redirect the results in your ‘evidence’ directory:

find. -type f -exec file {} ; > /evidence/TypeOfFile

Go to evidence directory and see the contents of TypeOfFile, you get the nice view of file types [Figure-6]:

[Figure-6: Type of files] Now we may want to view the contents of the files:

less hello.txt

strings hello.txt

Or, if you want to see HexDump:

xdd hello.txt

Searching strings can be also useful in the cases where you might want to look for notoriously used terms that may give you some idea about the incident and purpose: such as, ransom, virus, secrets etc. They may provide vital clue to in the investigation. So, we shall extract all the zipped files in order to search them for any particular string. The following commands now can be used for searching a term [Figure-7]:

grep -r -i secret ./ , It will look for term ‘secret’ in all the files of current directory

[Figure-7: Looking for suspicious keywords through the image]

grep –r –i rootkit ./ [Figure-8]:

[Figure-8: Looking for suspicious keywords] It seems that a rootkit has also been injected to the system. But where is the file? If we search through the file, at the bottom we find path of rootkit binary file. Finding of NTROOT.sys suggest that the system was infected from process hiding Trojans. So here’s another search [Figure-9]:

[Figure-9: We confirmed the path of rootkit file] Now, let’s move to few more interesting folders. Let’s see what lies inside them. Keep digging into them. The file DonVittos_private_key.txt contains a private DSA key, which might have been used to get access the machine [Figure-10]:

less DonVittos_private_key.txt

[Figure-10: View of a private key file] Let’s drill into other folders such as ‘Document and Settings’. One file ‘index.dat’ under ‘Document and Settings/ Administrator/ Local Settings’ gives tracking information about sites visited. Keep looking other folders. We found something more interesting, one outlook.pst file under ‘Document and Settings/ Administrator/’. This may give us more information. We will use a tool called ‘readpst’ available in BackTrack. ‘readpst’ is a command line tool which converts pst files into mbox format which in turn can be viewed and manipulated using any mail reading software.

readpst -D outlook.pst

Option ‘D’ includes deleted items in the output. This creates several folders Inbox, Sent Items, MailBox, Deleted Items etc [Figure-11].

[Figure-11: Output of pst file] Now all of these folders which are in mbox format can be easily viewed using any mail client. For this purpose, I shall use ‘KMail’ to open the items. You just need to show the path of the folders and it will open them in your client interface. So if there are any attachments in the mail, you can easily open it and download for further evidence. So, while examining Inbox we can see the mails, one of the mails says [Figure-12]:

[Figure-12: View of one received mail] We can view any attachment now easily. Similarly let’s examine Sent Items folder now [Figure-13].

[Figure-13: View of a mail in Sent Items] The above mail appears to be threatening. We can see the contents of the files as well. Let’s open ‘document.doc’ above attached above to see its contents [Figure-14].

[Figure-14: View of an attachment in the mail] Further, we would like to redirect all the mail items to our ‘Evidence’ directory in order to collect them for producing proof:

readpst -D outlook.pst -o /evidence/MailsEvidence

Data recovery

Now, I shall introduce one more tool which has a nice GUI—Autopsy. Autopsy analyzes the disk image and helps you browse the file contents and recover the data. It even has capabilities for retrieving deleted files as well. So, once you are done with the image acquisition, we can use Autopsy to analyze the image [Figure-15.

[Figure-15: Autopsy tool] We’ll open a new case, provide the case name, description and investigator names at the second step, then add a host in the third step. In fourth step, you need to give path of the image stored at your machine. In few next steps, it will ask you to select the file system and partition, etc. Once done, click on ‘Analyze’ button, the following screen will appear [Figure-16].

[Figure-16: Autopsy functions] ‘File Analysis’ lets you browse through the entire file system, ‘Keyword Search’ can be used for searching specific terms in the file system, ‘File Type’ lets you see the allocated and unallocated files, ‘Image Details’ gives information about File System architecture, size and other metadata information, ‘Meta Data’ gives information about inodes, ‘Data Unit’ shows contents of any fragment. We’re interested in File Analysis and Keyword Search. Let’s click File Analysis tab [Figure-17]:

[Figure-17: Browsing the file system] We can browse and view contents of the entire file system. The files in blue are existing files and if in red, they are deleted. We can see the contents of the files by clicking on them. Autopsy also gives you much information about dates of access, change, size, name etc of the files. Let’s click on of the red files, which were deleted. It shows the contents of the deleted file, file type, and various options for displaying it in ASCII, HEX or exporting the file [Figure-18].

[Figure-18: View of deleted files] Now we’ll go to Keyword Search tab and try to search some important terms such as SSN, ransom, virus, Trojan, secret etc. Actually, it’s suggested to create a list of terms or regular expressions, which can give vital clues about the file. We searched for the term ‘warn’ here; it shows all of the hits it found in the entire file system. We can show the contents of the file after clicking on them [Figure-19].

[Figure-19: Keyword searches in Autopsy] Apart from these, there are a few more options which we can try and get more useful evidence as far as possible. It’s not possible to cover all of the tools and their functionalities in single article; hence we may look at them in future articles.

Sources

DFTT – Sourcesforge PYflag – Sourceforge Linuxleo Linux – Deft