Autopsy as a Reliable Forensic Tools

In 2008/09, I joined MSc in Forensic Informatics at the University of Strathclyde, UK through the Chevening scholarship funded by the UK government and administered by the British Council. At that moment, most experiments and assignments conducted in the lab used command line tools running in Linux platform, such as dcfldd for forensic imaging, foremost for carving, exiftool for viewing exif data, and so on. One of the tools which were frequently used for forensic analysis was Autopsy created by Brian Carrier. Autopsy which is a forensic browser running in Linux operating system are derived from The Sleuthkit which is a group of command line forensic tools. I can say that Autopsy is a GUI of The Sleuthkit. Autopsy for Linux is version 2.

On 26 March 2013, Brian Carrier issued new version of Autopsy which runs on Windows platform. It is version 3.0.5 with nice GUI. This version does not use browser as a medium to view the results of forensic analysis like Autopsy v2 in Linux. The good news about Autopsy is that it is free of charge which is distributed under a Apache 2 license. For my self and others, I recommend this tool is one of forensic tools used for digital forensic analysis in more details.

Below is the description about Autopsy which is quoted from its website:

Autopsy is a graphical interface to The Sleuth Kit and other analysis tools. It was designed to be an extensible platform so that it can be an end-to-end digital forensics solution that incorporates plug-in modules from both open and closed source projects.

This page describes the concepts of version 3, which is a complete re-write from version 2. Version 3 currently only runs on Windows. If you perform digital forensics on a non-Windows system, refer to the version 2 page.



You can download Autopsy from the Downloads page and see the full set of features on the Features page.

The following concepts were essential to the design of Autopsy 3:

• Extensibility: No single vendor can provide a solution to every analysis problem and no one knows what analysis techniques will work best on tomorrow's problems. Autopsy was designed with this in mind. In several places, it uses frameworks that allow plug-in modules to be easily inserted. This allows you to customize Autopsy to suit your analysis needs and extend it with custom or third-party modules.
• Ease Of Use: Digital forensics tools should be intuitive and approachable so that they can be effectively used by non-technical investigators. Autopsy 3 uses wizards to help the investigator know what the next step is, uses common navigation techniques to help them find their results, and tries to automate as much as possible to reduce errors.
• Fast Results: As media grows in size, it takes longer to analyze all of it. Autopsy tries to give the investigator relevant information as soon as possible. It analyzes user folders over system folders. It alerts you to hash set hits as soon as they are found and you can change the settings to only focus on important things if you have limited time (i.e. triage).

In order to allow for modules and future extensibility, Autopsy uses a central SQLite database to store its results. This database stays small because file content is not stored in it. This means that you get the benefits have having the data stored in a database without having to install a database or be a database administrator. The schema is documented on the wiki. 
Ingest Modules analyze the disk image contents. When the investigator adds a disk image to the case, he is prompted to enable and configure the ingest modules (screen shot). The basic version of Autopsy comes with ingest modules for:

• Hash calculation and lookup
• Indexed keyword search using open source SOLR/Lucene
• Recent user activity (web artifacts, recent documents, etc) using Pasco2, RegRipper, and SQLite libraries.
• MBOX / Thunderbird files
• EXIF Extraction

These modules are run in parallel. Refer to the wiki page for the latest list of third-party modules. Developers are encouraged to write ingest modules because then can then let Autopsy deal with file access, reporting, and the UI and they can focus on fancy analysis techniques.

Content viewers allow the examiner to view a single file. Different viewers display the file in different formats. Examples include hex, strings, and media (images, video, etc. using gstreamer) (screen shot). Additional viewers can be created to view different file types (such as advanced text analytics or image analysis).

Report modules create the final report. They access the central database to collect the results from all of the ingest modules. The basic version of Autopsy comes with an HTML and Excel report format. You can make other modules to report in custom formats.

Add-on Viewers show data in a more complex way than the three panel design. As an example, the timeline viewer (screen shot) displays the timeline data in graph form.

Several features were added to make sure Autopsy was easy to use for non-technical users.

• Wizards are used in several places to guide the user through common steps.
• History is maintained so that the user can use back and forward buttons to back track after they have gone down an investigation path.
• Previous settings are often saved with the modules so that you can more easily analyze the next image with the same settings as the last image.

Autopsy's default view is a simple interface where all of the analysis results can always be found in a single tree on the left(screen shot). When the examiner is looking for something, he should immediately review the tree. He doesn't have to dig through menus or layers of tabs to find the information.

Autopsy tries to be non-invasive with popups and messages from the background tasks that are running. The motivation for this is that you could be focusing on an investigation path based on some web activity or keyword search results. By having to deal with messages from background ingest modules, you could get distracted. The ingest inbox is where modules send messages. You can then open the inbox when you are ready to see the results, review what has been found since you last opened it, and choose which results to start focusing on.

SOP 3 about Reporting of Digital Forensic Analysis Results

SOP 3 about Reporting of Digital Forensic Analysis Results

This SOP comprises 7 parts, namely:
1. Introduction
2. Purpose
3. Scope
4. Reference
5. Materials and Device
6. Implementation
7. Related Documents


1. Introduction

Once electronic evidence such as a Personal Computer (PC), laptops / notebooks, netbooks, tablet PCs, mobile phones, flash disk, memory cards and and so on are examined and analyzed through the procedures as described in SOP 8 to 15, the next stage is to write down examination and analysis procedures used and the results for each of the evidence in a technical report. The form of the report is the Official Report of Forensic Laboratory that is pro justicia so it can be used as legal evidence in a court of law. Due to the official nature, the report can be issued if there is a written official request and investigative administration files from the police office unit who submit electronic evidence to be examined, in which the letter is addressed to the Chief of Forensic Laboratory Centre.

Because the report will be finally brought to the court, the language style used in the report must be as simple as possible without removing its essential meaning. It is aimed that the jury/judges, prosecutors and/or lawyers can properly understand the process and results of digital forensic examination and analysis. They are not a digital forensic analyst who can understand about digital forensic thoroughly.

2. Purpose

For the orderly administration and technical in making the official report of forensic laboratory that is comprehensive, including mention of the procedures used and the results of digital forensic examination and analysis for each electronic evidence.

3. Scope

The scope of this SOP are as follows:
3.1. Introduction
3.2. Chapter I: Evidence Received
3.3. Chapter II: Purpose of Examination and Analysis
3.4. Chapter III: Procedures of Examination and Analysis
3.5. Chapter IV: Results of Examination and Analysis
3.6. Chapter V: Conclusion
3.7. Chapter VI: Packaging and Labeling Evidence
3.8. Chapter VII: Closing

4. Reference

4.1. ACPO, 7Safe (2008). Good Practice Guide for Computer-Based Electronic Evidence. UK ACPO and 7Safe.
4.2. National Institute of Justice (2004). Forensic Examination of Digital Evidence: A Guide for Law Enforcement. US National Institute of Justice.
4.3. Al-Azhar, M.N. (2012). "Digital Forensic: Practical Guidleines for Computer Investigation". Salemba Infotek, Jakarta.

5. Materials and Device

5.1. Analysis workstation
5.2. Form 1: Receiving Electronic Evidence
5.3. Form 2: Submitting Electronic Evidence
5.4. Technical data yielded from forensic examination and analysis
5.5. Investigative administration files

6. Implementation

6.1. Introduction

It contains the date of examination and analysis is accomplished, the names of the examiners completed with rank and position, warrant for examination and analysis and others.

6.2. Chapter I: Evidence Received

It contains all electronic evidence received completed with technical specifications of each item of evidence as described in SOP 4.

6.3. Chapter II: Purpose of Examination/Analysis

It contains a description of the purpose of examination and analysis which is based on the official request letters or memos that provides information on the type of investigation cases completed with police report.

6.4. Chapter III: Procedures of Examination and Analysis

It contains SOPs which are used, such as SOP 8 and 9 for the Acquisition and Analysis of hard drive, flash and Memory Card. In addition, it also lists the MD5 hash value of the image / backup files generated from forensic imaging or acquisition process as described in SOP 8 and 10.

6.5. Chapter IV: Results of Examination and Analysis

It contains whole data of electronic evidence found as described in SOP 6 to 15, including investigative data related to the case which has been clarified by investigators, and the results of further analysis of the data. If there is an evidence in which the investigative data is not found, so it is stated that on the evidence, the investigative data related to the case is not found.

6.6. Chapter V: Conclusion

It contains the conclusion yielded from the digital forensic examination and analysis which is based on the investigative data found.

6.7. Chapter VI: Packaging and Labeling Evidence

It contains a description of the process of packaging and sealing evidence as well as labeling which contains numbers of evidence, its types, and the police office unit as the origin of electronic evidence, as described in SOP 5.

6.8. Chapter VII: Closing

It contains a closing sentence which is followed with the signature of the examiners and known by Chief of Forensic Laboratory or his representative.

7. Related Documents

It is the same as Reference at point 4, and added with:
7. 1. Carrier, B. (2007). File System Forensic Analysis. Addison-Wesley.
7. 2. Casey, E. (2004). Digital Evidence and Computer Crime: Forensic Science, Computers and the Internet. Elsevier Academic Press.
7. 3. Johnson, T. A. (2005). Forensic Computer Crime Investigation. Taylor & Francis.
7. 4. Marcella, A.J. and Greenfield, R. S. (2002). Cyber Forensics : A Field Manual for Collecting, Examining, and Preserving Evidence of Computer Crimes. CRC Press.
7. 5. Middleton, B. (2002). Cyber Crime Field Handbook. CRC Press.
7. 6. Sammes, T. and Jenkinson, B. (2007). Forensic Computing: A Practitioners Guide. Springer.
7. 7. Indonesian Act No. 11 year 2008 about Electronic Information and Transaction.


Written by:
Chief of Computer Forensic Sub-Department
Indonesian Police Forensic Laboratory Center

Muhammad Nuh Al-Azhar, MSc., CHFI, CEI
Superintendent Police


Agreed by:
Chief of Physics and Computer Forensic Department
Indonesian Police Forensic Laboratory Center

Drs. Andi Firdaus
Senior Superintendent Police

Note:

To download the SOP 3 in Indonesian version, please click the link below:

https://dl.dropboxusercontent.com/u/4868186/DFAT_SOP_2013/SOP3_PelaporanHasilPemeriksaanDigitalForensik.pdf

Travnet, a new Trojan designed to steal files in compressed data

When reading news of SC Magazine dated on 26 April 2013, I was surprised that there is a new trojan, Travnet found by McAfee Labs with unique style. The trojan steals many files in various formats, and then the files are sent to a remote server in a compressed data chunks of 1,024 bytes. It is very small file through the protocol of http.
In my point of view, in the last several years, there is a change of cyber attack which frequently uses trojan as  a useful tool to attack targets. With trojan, the attackers can do many things from DDoS to stealing confidential data on target, even it can be designed to destroy system on targets, like Stuxnet and Flames. Such trojans are also used by criminals to attack banks and finance institution. There has been many cases due to trojan attacks. Officers of banks, governments, law enforcements and so on must be aware on this type of cyber attack. They should have steps to minimize the risks caused by this attack, and steps to prevent and avoid such attacks.

SC Magazine:
A new trojan capable of compressing stolen data and uploading document files to remote servers is being used in a targeted operation, researchers have found.
Upon infecting a machine, the malware, dubbed “Travnet,” gathers victims' information – such as their computer name, IP address, IP configuration details and a list of running processes – to communicate the information to a command-and-control server.
From there, botnet operators can determine the value of information on the compromised machines at their disposal, while sending further instructions, McAfee Labs researchers discovered.

For further info, please go the link below:
http://www.scmagazine.com/travnet-trojan-compresses-files-to-send-more-info-to-data-thieves/article/290486/