Merge pull request #1130 from karlmortensen/user_docs

update user documentation for 3.1.2
This commit is contained in:
Richard Cordovano
2015-03-23 13:39:35 -04:00
131 changed files with 968 additions and 290 deletions
Regular → Executable
+6 -6
View File
@@ -38,7 +38,7 @@ PROJECT_NAME = "Autopsy User Documentation"
# could be handy for archiving the generated documentation or if some version
# control system is used.
PROJECT_NUMBER = 3.1
PROJECT_NUMBER = 3.1.2
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a
@@ -1372,7 +1372,7 @@ DISABLE_INDEX = NO
# The default value is: NO.
# This tag requires that the tag GENERATE_HTML is set to YES.
GENERATE_TREEVIEW = YES
GENERATE_TREEVIEW = NO
# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
# doxygen will group on one line in the generated HTML documentation.
@@ -1486,7 +1486,7 @@ MATHJAX_CODEFILE =
# The default value is: YES.
# This tag requires that the tag GENERATE_HTML is set to YES.
SEARCHENGINE = YES
SEARCHENGINE = NO
# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
# implemented using a web server instead of a web client using Javascript. There
@@ -2040,14 +2040,14 @@ ALLEXTERNALS = NO
# listed.
# The default value is: YES.
EXTERNAL_GROUPS = YES
EXTERNAL_GROUPS = NO
# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
# the related pages index. If set to NO, only the current project's pages will
# be listed.
# The default value is: YES.
EXTERNAL_PAGES = YES
EXTERNAL_PAGES = NO
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of 'which perl').
@@ -2117,7 +2117,7 @@ DOT_NUM_THREADS = 0
# The default value is: Helvetica.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_FONTNAME = FreeSans
DOT_FONTNAME =
# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
# dot graphs.
+29
View File
@@ -0,0 +1,29 @@
/*! \page EXIF_parser_page EXIF Parser Module
What Does It Do
========
The EXIF Parser module extracts EXIF (Exchangeable Image File Format) information from ingested pictures. This information can contain geolocation data for the picture, time, date, camera model and settings (exposure values, resolution, etc) and other information. The discovered attributes are added to the BlackBoard.
This can tell you where and when a picture was taken, and give clues to the camera that took it.
Configuration
=======
There is no configuration required.
Using the Module
======
Select the checkbox in the Ingest Modules settings screen to enable the EXIF Parser.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
Results are shown in the Results tree.
\image html EXIF-tree.PNG
*/
Regular → Executable
View File
+47
View File
@@ -0,0 +1,47 @@
/*! \page android_analyzer_page Android Analyzer Module
What Does It Do
========
The Android Analyzer module allows you to analyze SQLite and other files from an Android device. It works on Physical dumps from most Android devices (note that we do not provide an acquisition method). Autopsy will not support older Android devices that do not have a volume system. These devices will often have a single physical image file for them and there is no information in the image that describes the layout of the file systems. Autopsy will therefore not be able to detect what it is.
The module should be able to extract the following:
- Text messages / SMS / MMS
- Call Logs
- Contacts
- Tango Messages
- Words with Friends Messages
- GPS from the browser and Google Maps
- GPS from cache.wifi and cache.cell files
NOTE: These database formats vary by version of OS and different vendors can place the databaes in different places. Autopsy may not support all versions and vendors.
NOTE: This module is not exhaustive with its support for Android. It was created as a starting point for others to contribute plug-ins for 3rd party apps. See the Developer docs (http://sleuthkit.org/autopsy/docs/api-docs/3.1/mod_mobile_page.html) for information on writing modules.
Configuration
=======
There is no configuration required.
Using the Module
======
Simply add your physical images or file system dumps as data sources and enable the Android Analyzer module.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
The results show up in the tree under "Results", "Extracted Content".
\image html android_analyzer_output.PNG
*/
*/
+34
View File
@@ -0,0 +1,34 @@
/*! \page archive_extractor_page Archive Extractor Module
What Does It Do
========
The Archive Extractor module opens ZIP, RAR, and other archive formats and sends the files from those archive files back through the ingest pipeline for analysis.
Why would you use it?
This module expands archive files to enable Autopsy to analyze all files on the system. It enables keyword search and hash lookup to analyze files inside of archives
Configuration
=======
There is no configuration required.
Using the Module
======
Select the checkbox in the Ingest Modules settings screen to enable the Archive Extractor.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
Each file extracted shows up in the data source tree view as a child of the archive containing it,
\image html zipped_children_1.PNG
<br>
<br>
and as an archive under "Views", "File Types", "Archives".
\image html zipped_children_2.PNG
*/
+7 -5
View File
@@ -2,13 +2,15 @@
You need to create a case before you can analyze data in Autopsy. A case can contain one or more data sources (disk images, disk devices, logical files). The data sources can be from multiple drives in a single computer or from multiple computers. It's up to you.
Each case has its own directory that is named based on the case name. The directory will contain configuration files, a database, reports, and other files that modules generates. The main Autopsy case configuration file has a .aut extension.
Each case has its own directory that is named based on the case name. The directory will contain configuration files, a database, reports, and other files that modules generates. The main Autopsy case configuration file has an ".aut" extension.
\section case_create Creating a Case
\image html splashscreen.PNG
There are several ways to create a new case:
- The opening window has a button to create a new case.
- The "File" -> "New Case..." menu item
- The opening splash screen has a button to create a new case.
- The "File", "New Case..." menu item
The "New Case" wizard dialog will open and you will need to enter the case name and base directory. A directory for the case will be created inside of the "base directory". If the directory already exists, you will need to either delete the existing directory or choose a different combination of names.
@@ -21,8 +23,8 @@ After you create the case, you will be prompted to add a data source, as describ
\section case_open Opening a Case
To open a case, either:
- Choose "Open Case" or "Open Recent Case" from the opening window.
- The "File" -> "Open Case" menu item or "File" -> "Open Recent Case"
- Choose "Open Case" or "Open Recent Case" from the opening splash screen.
- The "File", "Open Case" menu item or "File", "Open Recent Case"
Navigate to the case directory and select the ".aut" file.
+23
View File
@@ -0,0 +1,23 @@
/*! \page content_viewer_page Content Viewer
The Content Viewer lives in the lower right-hand side of the Autopsy main screen and show pictures, video, hex, text, extracted strings, metadata, etc. They are enabled when you select a file in the file list above it.
The Content Viewer is context-aware, meaning it will present different views of the content based on the type of file selected. For example, a .JPG would show up as a picture, a text file would show up as text, and a .bin file would show up as hex output.
The screenshots below show some examples of content viewers in action.
<br>
\image html content-viewer-1.PNG
<br>
<br>
\image html content-viewer-2.PNG
<br>
<br>
\image html content-viewer-3.PNG
<br>
<br>
\image html content-viewer-4.PNG
<br>
<br>
\image html content-viewer-5.PNG
<br>
*/
-61
View File
@@ -1,61 +0,0 @@
/*! \page content_viewers Content Viewers
The Content Viewer area is in the lower right area of the interface. This area is used to view a specific file in a variety of formats. There are different tabs for different viewers. Not all tabs support all file types, so only some of them will be enabled. To display data in this area, a file must be selected from the Result Viewer window.
The Content Viewer area is part of a plug-in framework. You can install modules that will add more viewer types. This section describes the viewers that come by default with Autopsy.
Here's an example of a "Content Viewer" window:
\image html content-viewer-window-example.PNG
<b>Default Viewers</b>
Currently, there are 5 main tabs on "Content Viewer" window:
\li \ref result_content_viewers
\li \ref hex_content_viewer
\li \ref string_content_viewer
\li \ref media_content_viewer
\li \ref text_content_viewer
\section result_content_viewers Result Content Viewer
Result Content Viewer shows the artifacts (saved results) associated with the item selected in the Result Viewer.
<b>Example</b>
Below is an example of "Result Content Viewer" window:
\image html result-viewer-example.PNG
\section hex_content_viewer Hex Content Viewer
Hex Content Viewer shows you the raw and exact contents of a file. In this Hex Content Viewer, the data of the file is represented as hexadecimal values grouped in 2 groups of 8 bytes, followed by one group of 16 ASCII characters which are derived from each pair of hex values (each byte). Non-printable ASCII characters and characters that would take more than one character space are typically represented by a dot (".") in the following ASCII field.
<b>Example</b> \n
Below is an example of "Hex Content Viewer" window:
\image html hex-content-viewer-tab.PNG
\section media_content_viewer Media Content Viewer
The Media Content Viewer will show a picture or video file. Video files can be played and paused. The size of the picture or video will be reduced to fit into the screen. If you want more complex analysis of the media, then you must export the file.
If you select an non-picture file or an unsupported picture format on the "Result Viewers", this tab will be disabled.
<b>Example</b> \n
Here's one of the example of the "Media Content Viewer":
\image html picture-content-viewer-tab.PNG
\section string_content_viewer String Content Viewer
Strings Content Viewer scans (potentially binary) data of the file / folder and searches it for data that could be text. When appropriate data is found, the String Content Viewer shows data strings extracted from binary, decoded, and interpreted as UTF8/16 for the selected script/language.
Note that this is different from the Text Content Viewer, which displays the text for a file that is stored in the keyword search index. The results may be the same or they could be different, depending how the data were interpreted by the indexer.
<b>Example</b> \n
Below is an example of "String Content Viewer" window:
\image html string-content-viewer-tab.PNG
\section text_content_viewer Text Content Viewer
Text Content Viewer uses the keyword search index that may have been populated during Image Ingest. If a file has text stored in the index, then this tab will be enabled and it will be displayed to the user if a file or a result associated with a file is selected.
This tab may have more text on it than the "String View", which relies on searching the file for text-looking data. Some files, like PDF, will not have text-looking data at the byte-level, but the keyword indexing process knows how to interpret a PDF file and produce text. For the files the indexer knows about, there may be the METADATA section at the end of the displayed extracted text. If an indexed document contains any metadata (such as creation date, author, etc), it will be displayed there. Note that, unlike the "String View", the Text View does not have its built-in settings for the script/language to use for extracted strings. This is because the script/language is used at indexing time, and that setting is associated with the Keyword Search indexer, not the viewer.
If this tab is not enabled, then either the file has no text or you did not enable Keyword Search as an ingest module. Note that this viewer is also used to display highlighted keyword hits when operated in the "Search Matches" mode, selected on the right-hand side of the viewer's toolbar.
\image html text-view.PNG
*/
+3 -11
View File
@@ -1,7 +1,7 @@
/*! \page ds_page Data Sources
Data source is the term that we use in Autopsy to refer to disk images, logical files, etc. This is the data that you want to add in to analyze. You must have a case open before you can add a data source.
A data source the thing you want to analyze. It can be a disk image, some logical files, a local drive, etc. You must open a case prior to adding a data source to Autopsy.
Autopsy supports three types of data sources:
- Disk Image: A file (or set of files) that is a byte-for-byte copy of a hard drive or media card. (see \ref ds_img)
@@ -15,14 +15,10 @@ Autopsy supports three types of data sources:
You can add a data source in several ways:
- After you create a case, it automatically prompts you to add a data source.
- There is a toolbar item to add a Data Source when a case is open.
- The "File" -> "Add Data Source" menu item when a case is open.
- The "File", "Add Data Source" menu item when a case is open.
The data source must remain accessible for the duration of the analysis because the case contains only a reference to the data source. It does not copy the data source into the case folder.
\section ds_process Data Source Adding Process
Regardless of the type of data source, there are some common steps in the process:
1) You will be prompted to specify the data source to add (details are provided below)
@@ -41,7 +37,7 @@ Regardless of the type of data source, there are some common steps in the proces
5) After the ingest modules have been configured and the basic examination of the data source is complete, the ingest modules will begin to analyze the file contents.
You cannot remove a data source from a case.
\section ds_img Adding a Disk Image
@@ -89,8 +85,4 @@ To add logical files:
All of the files that you added in the panel will be grouped together into a single data source, called "LogicalFileSet" in the main UI.
\section ds_rem Removing a Data Source
You cannot currently remove an data source from a case.
*/
-44
View File
@@ -1,44 +0,0 @@
/*! \page directory_tree Directory Tree
\section about_data_explorer About Data Explorer (Directory Tree)
The data explorer tree is a very important area of the interface. This is where you will start many of your analysis approaches and find saved results from automated procedures (ingest). The tree has three main areas:
\li <b>Images:</b> \n Where you can find the directory tree hierarchy of the file systems in the images. Go here to navigate to a specific file or directory.
\li <b>Views:</b> \n Where you can view all of the files in the images, but organized by file type or dates instead of directories. Go here if you are looking for files of a given type or that were recently used.
\li <b>Results:</b> \n Where you can see the results from the background ingest tasks and you can see your previous search results. Go here to see what was found by the ingest modules and to find your previous search results.
\li <b>Bookmarks:</b> \n Where you can view all file and results that have been bookmarked for easy access.
Below is an example of an Data Explorer Tree window:
image html explorer-tree.PNG
\section image_details_window Image Detail Window
The Image Details window shows you basic information about a disk image. You can access it by right-clicking on an image in the tree and choosing "Image Details".
\image html show-image-details.PNG
An example is shown here:
\image html image-detail-window.PNG
\section volume_details_window Volume Detail Window
The Volume Details window shows you information about a volume. It shows information such as the starting sector, length, and description. You can view the information by right clicking on a volume in the tree and choosing "Volume Details".
\image html show-volume-details.PNG
An example is shown here:
\image html volume-detail-window.PNG
\section extracting_unallocated_space Extracting Unallocated Space
Unallocated space are chunks of the file system that is currently not being used for anything. Unallocated space can store deleted files and other interesting artifacts. On the actual image, Unallocated space is stored in blocks with distinct locations on the system. However, because of the way various carving tools work, it is more ideal to feed them a single, large unallocated file. Autopsy provides access to both methods of looking at unallocated space.
\li Individual Blocks Underneath a volume, there is a folder named Unalloc. This folder contains all the individual unallocated blocks as the image is storing them. You can right click and extract them the same way you can extract any other type of file in the Directory Tree.
\li Single Files There are two ways to extract unallocated space as a single file. Right clicking on a volume and selecting "Extract Unallocated Space as Single File" will concatenate all the unallocated files into a single, continuous file for the volume. The second way is to right click on an image, and select "Extract Unallocated Space to Single Files". This option will extract one single file for each volume in the image. Progress on extraction is sent to the progress bar in the bottom right. Progress is based on number of files concatenated. These files are stored in the Export folder under the case directory. Files are named according to ImageName-Unalloc-ImageObjectID-VolumeID.dat This naming scheme ensures that no duplicate file names will occur even if an there are two images with the same name in a case.
Below is where to find the single file extraction option
\image html extracting-unallocated-space.PNG
*/
+31
View File
@@ -0,0 +1,31 @@
/*! \page e01_verifier_page E01 Verifier Module
What Does It Do
========
The E01 Verifier module computes a checksum on E01 files and compares with the E01 file's internal checksum to ensure they match.
This can detect if the E01 module is corrupted.
Configuration
=======
There is no configuration required.
Using the Module
======
Select the checkbox in the Ingest Modules list to use this module.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
You only see results from this module if the E01 is corrupted. A failure to load is shown below.
\image html e01-verifier.png
*/
+30
View File
@@ -0,0 +1,30 @@
/*! \page email_parser_page Email Parser Module
What Does It Do
========
The Email Parser module identifies Thunderbird MBOX files and PST format files based on file signatures, extracting the e-mails from them, adding the results to the Blackboard. This module skips known files and creates a Blackboard artifact for each message. It adds email attachments as derived files.
This allows the user to identify email-based communications from the system being analyzed.
Configuration
=======
There is no configuration required.
Using the Module
======
Explore the "Results", "E-Mail Messages" portion of the tree to review the results of this module.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
The results of this show up in the "Results", "E-Mail Messages" portion of the tree.
\image html email_results.PNG
*/
+35
View File
@@ -0,0 +1,35 @@
/*! \page extension_mismatch_detector_page Extension Mismatch Detector Module
What Does It Do
========
Extension Mismatch Detector module uses the results from the File Type Identification and flags files that have an extension not traditionally associated with the file's detected type. Ignores 'known' (NSRL) files. You can customize the MIME types and file extensions per MIME type in Tools, Options, File Extension Mismatch.
This detects files that someone may be trying to hide.
Configuration
=======
One can add and remove MIME types in the "Tools", "Options", "File Extension Mismatch" dialog box, as well as add and remove extensions to particular MIME types.
<br>
\image html extension-mismatch-detected-configuration.PNG
<br>
Using the Module
======
Note that you can get a lot of false positives with this module. You can add your own rules to Autopsy to reduce unwanted hits.
Ingest Settings
------
In the ingest settings, the user can choose if the module should skip files without extensions and skip text files. Both of these options are enabled by default.
\image html extension-mismatch-detected-ingest-settings.PNG
Seeing Results
------
Results are shown ini the Results tree under "Extension Mismatch Detected".
\image html extension-mismatch-detected.PNG
*/
+5 -17
View File
@@ -1,31 +1,19 @@
/*! \page file_search File Search
/*! \page file_search_page File Search
\section about_file_search About File Search
File Search tool can be accessed either from the Tools menu or by right-clicking on image node in the Data Explorer / Directory Tree. By using File Search, you can specify, filter, and show the directories and files that you want to see from the images in the current opened case. The File Search results will be populated in a brand new Table Result viewer on the right-hand side.
The File Search tool can be accessed either from the Tools menu or by right-clicking on a data source node in the Data Explorer / Directory Tree. By using File Search, you can specify, filter, and show the directories and files that you want to see from the images in the current opened case. The File Search results will be populated in a brand new Table Result viewer on the right-hand side.
Currently, Autopsy only supports 4 categories in File Search: Name, Size, Date, and Known Status based search.
<b>Note: Currently File Search doesn't support regular expression, however the Keyword Search feature of Autopsy does also look in file names and it does support regular expressions, which can complimentary to the File Search.</b>
<b>How to Open File Search:</b>\n
To see how to open File Search, click \ref how_to_open_file_search "here".\n
<b>Note: The File Search Window is opened and closed automatically. If there's a case opened and there is at least one image inside that case, File Search Window can't be closed.</b>
<b>How to Use File Search:</b> \n
To see how to use File Search, click \ref how_to_use_file_search "here".
<b>Example</b>
Here's an example of a File Search window:
\image html file-search-top-component.PNG
Note: Currently File Search doesn't support regular expressions. The Keyword Search feature of Autopsy does support regular expressions and can be used for to search for files and/or directories by name.
\section how_to_open_file_search How To Open File Search
How to Open File Search
To open the File Search, you can do one of the following thing:
Right click an image and choose "Open File Search by Attributes".
Right click a data source and choose "Open File Search by Attributes".
\image html open-file-search-component-1.PNG
Select the "Tools" > "File Search by Attributes".
Select the "Tools", "File Search by Attributes".
\image html open-file-search-component-2.PNG
<b>Note: The File Search Window is opened and closed automatically. If there's a case opened and there is at least one image inside that case, File Search Window can't be closed.</b>
\section how_to_use_file_search How To Use File Search
+41
View File
@@ -0,0 +1,41 @@
/*! \page file_type_identification_page File Type Identification Module
What Does It Do
========
The File Type ID module identifies files based on their internal signatures and does not rely on file extensions. Autopsy uses the <a href="http://tika.apache.org/">Tika</a> library to do its primary file ID detection and that can be customized with user-defined rules.
You should enable this module because many other modules depend on its results to determine if they should analyze a file. Some examples include:
- \subpage extension_mismatch_detector_page
- \subpage keyword_search_page
Configuration
=======
You do not need to configure anything with this module unless you want to define your own types. To define your own types, go to "Tools", "Options", "File Type Id" panel.
From there, you can define rules based on the offset of the signature and if the signature is a byte sequence of an ASCII string.
\image html filetype.png
Using the Module
======
Ingest Settings
------
There are no run-time settings for this module when you run it on
a data source. All user-defined and Tika rules are always applied.
Seeing Results
------
This module does not have obvious impacts in the user interface, though it is used by many othe modules.
To see the file type of an individual file, view the "Results" tab in the lower right when you navigate to the file. You should see a page in there that mentions the file type.
The Views area of the tree does not take the results of this module into account. That part of the tree relies on extension. We will be upating it in the future to rely on extension when there is no output from this module for the file.
*/
Regular → Executable
+1 -1
View File
@@ -1,5 +1,5 @@
<hr/>
<p><i>Copyright &#169; 2012-2015 Basis Technology <br/>
<p><i>Copyright &#169; 2012-2015 Basis Technology. Generated on $date<br/>
This work is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/us/">Creative Commons Attribution-Share Alike 3.0 United States License</a>.
</i></p>
+32 -8
View File
@@ -1,11 +1,13 @@
/*! \page hash_db_page Hash Database Lookup Module
Autopsy has an ingest module that calculates hash values and looks up the hash values in a database to determine if the file is known bad, known (in general), or unknown. This page outlines that module and its configuration.
\section hash_db_config Configuring the module
What Does It Do
========
The Hash Database Lookup Module calculates MD5 hash values for files and looks up hash values in a database to determine if the file is known bad, known (in general), or unknown.
Configuration
=======
The Hash Database Management window is where you can set and update your hash database information. Hash databases are used to identify files that are 'known'.
\li Known good files are those that can be safely ignored. This set of files frequently includes standard OS and application files. Ignoring such uninteresting to the investigator files, can greatly reduce image analysis time.
\li Known bad (also called notable) files are those that should raise awareness. This set will vary depending on the type of investigation, but common examples include contraband images and malware.
@@ -17,17 +19,39 @@ Autopsy allows for multiple known bad hash databases to be set. Autopsy supports
\li NSRL: The format of the NSRL database.
\li HashKeeper: Hashset file conforming to the HashKeeper standard.
<b>NIST_NSRL:</b>
Autopsy can use the <A HREF="http://www.nsrl.nist.gov">NIST NSRL</A> to detect 'known files'. Note that the NSRL contains hashes of 'known files' that may be good or bad depending on your perspective and investigation type. For example, the existence of a piece of financial software may be interesting to your investigation and that software could be in the NSRL. Therefore, Autopsy treats files that are found in the NSRL as simply 'known' and does not specify good or bad. Ingest modules have the option of ignoring files that were found in the NSRL.
To use the NSRL, you must concatenate all of the NSRLFile.txt files together. You can use 'cat' on a Unix system or from within Cygwin to do this.
\section adding_hashsets Adding Hashsets
Autopsy needs an index of the hashset to actualy use a hash database. It can create the index if you import only the hashset. When you select the database from within this window, it will tell you if the index needs to be created. Autopsy uses the hash database management system from The Sleuth Kit. You can manually create an index using the 'hfind' command line tool or you can use Autopsy. If you attempt proceed without indexing a database, Autopsy will offer to automatically produce an index for you.
You can also specify only the index file and not use the full hashset - the index file is sufficient to identify known files. This can save space. To do this, specify the .idx file from the Hash Database Management window.
\section using_hashsets Using Hashsets
There is an \ref ingest "ingest module" that will hash the files and look them up in the hashsets. It will flag files that were in the notable hashset and those results will be shown in the Results tree of the \ref directory_tree "Data Explorer".
There is an \ref ingest_page "ingest module" that will hash the files and look them up in the hashsets. It will flag files that were in the notable hashset and those results will be shown in the Results tree of the \ref tree_viewer_page.
Other ingest modules are able to use the known status of a file to decide if they should ignore the file or process it.
You can also see the results in the \ref how_to_open_file_search "File Search" window. There is an option to choose the 'known status'. From here, you can do a search to see all 'known bad' files. From here, you can also choose to ignore all 'known' files that were found in the NSRL. You can also see the status of the file in a column when the file is listed.
\image html hash-database-configuration.PNG
<b>NIST NSRL:</b>
Autopsy can use the <A HREF="http://www.nsrl.nist.gov">NIST NSRL</A> to detect 'known files'. Note that the NSRL contains hashes of 'known files' that may be good or bad depending on your perspective and investigation type. For example, the existence of a piece of financial software may be interesting to your investigation and that software could be in the NSRL. Therefore, Autopsy treats files that are found in the NSRL as simply 'known' and does not specify good or bad. Ingest modules have the option of ignoring files that were found in the NSRL.
To use the NSRL, you must concatenate all of the NSRLFile.txt files together. You can use 'cat' on a Unix system or from within Cygwin to do this.
Using the Module
======
Ingest Settings
------
When hashsets are configured, the user can select the hashsets to use during the ingest process.
\image html hash-lookup.png
Seeing Results
------
Results show up in the tree as "Hashset Hits", grouped by the name of the hash set.
\image html hashset-hits.png
*/
+3 -4
View File
@@ -1,4 +1,4 @@
/*! \page image_viewer Image and Video Viewer
/*! \page image_viewer_page Image and Video Viewer
Overview
========
This document outlines the use of the new Image Analyzer feature of Autopsy. This feature was funded by DHS S&T to help provide free and open source digital forensics tools to law enforcement.
@@ -8,12 +8,11 @@ The new image analyzer feature has been designed specifically with child-exploit
- Allows examiner to start viewing images immediately upon adding them to the case. As images are hashed, they are updated in the interface. You do not need to wait until the entire image is ingested.
This document assumes basic familiarity with Autopsy.
Quick Start
===========
1. The Image Analysis tool can be configured to collect data about images/videos as ingest runs or all at once after ingest. To change this setting go to Tools->Options->Image /Video Analyzer. This setting is saved per case, but can not be changed during ingest.
1. The Image Analysis tool can be configured to collect data about images/videos as ingest runs or all at once after ingest. To change this setting go to "Tools", "Options", "Image /Video Analyzer". This setting is saved per case, but can not be changed during ingest.
2. Create a case as normal and add a disk image (or folder of files) as a data source. Ensure that you have the hash lookup module enabled with NSRL and known bad hashsets, the EXIF module enabled, and the File Type module enabled.
3. Click Tools->Analyze Images/Videos in the menu. This will open the Autopsy Image/Video Analysis tool in a new window.
3. Click "Tools", "Analyze Images/Videos" in the menu. This will open the Autopsy Image/Video Analysis tool in a new window.
4. Groups of images will be presented as they are analyzed by the background ingest modules. You can later resort and regroup, but it is required to keep it grouped by folder while ingest is still ongoing.
5. As each group is reviewed, the next highest priority group is presented, according to a sorting criteria (the default is the density of hash set hits).
6. Images that were hits from hashsets, will have a dashed border around them.
Binary file not shown.

After

Width:  |  Height:  |  Size: 48 KiB

View File

Before

Width:  |  Height:  |  Size: 1005 B

After

Width:  |  Height:  |  Size: 1005 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 299 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 65 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

View File

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

View File

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 80 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

View File

Before

Width:  |  Height:  |  Size: 9.8 KiB

After

Width:  |  Height:  |  Size: 9.8 KiB

View File

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

View File

Before

Width:  |  Height:  |  Size: 5.5 KiB

After

Width:  |  Height:  |  Size: 5.5 KiB

View File

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.1 KiB

After

Width:  |  Height:  |  Size: 5.3 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 41 KiB

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

After

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 109 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

View File

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 47 KiB

Before

Width:  |  Height:  |  Size: 45 KiB

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 192 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

View File

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 40 KiB

BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 185 KiB

After

Width:  |  Height:  |  Size: 191 KiB

BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 48 KiB

BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 42 KiB

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 48 KiB

View File

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 32 KiB

View File

Before

Width:  |  Height:  |  Size: 68 KiB

After

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

View File

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

View File

Before

Width:  |  Height:  |  Size: 116 KiB

After

Width:  |  Height:  |  Size: 116 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 464 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

Regular → Executable
+34 -40
View File
@@ -1,61 +1,55 @@
/*! \page ingest Ingest
/*! \page ingest_page Ingest Modules
\section ingest_ingest Image Ingest
Autopsy tries to automate as many things as possible for the user. There are many tasks that will always be performed in a digital investigation and they normally involve some type of image or file analysis and extraction of a certain type of information. The analysis can be a lengthy process, especially for large images and when a number of types of analysis needs to be performed.
Ingest modules analyze the data in a data source. They perform all of the analysis of the files and parse their contents. Examples include \ref hash_db_page "hash calculation and lookup", \ref keyword_search_page "keyword searching", and \ref recent_activity_page "web artifact extraction".
Ingest is a technique of automating these tasks. Autopsy allows to run these lengthy analysis tasks in the background, while the user can browse the application interface and review the ingest results as their appear. Ingest is similar to triage. Autopsy attempts to process files inside the ingested image in such order so that the more interesting files (user-related files) are processed files.
Immediately after you add a data source to a case (see \ref ds_page), you will be presented with a dialog to configure the ingest modules to run on it. Once configured, they will run in the background and provide you real-time results when the find relevant information.
The ingest process begins after the basic file system information has been added to the database. A series of ingest modules (described in a following section) run automatically behind the scenes and make their results available as soon as possible. Autopsy is designed so that these results are reported to the user in real-time, and even for very large images to be processed there can be initial results available minutes, sometimes seconds after the analysis has started.
This page covers the use of ingest modules. Specific pages will cover the configuration of specific modules. See \ref module_install_page for details on installing 3rd-party ingest modules.
You can start image ingest in two ways. When you add an image with the Add Data Source wizard, you will be shown the list of ingest modules and you can choose which you want to run. You can also launch the Ingest Manager run ingest by right clicking on an image in the explorer tree and choosing "Restart Image Ingest".
\section ingest_performance Multi-threaded and Priority
Ingest modules are configured to find user content quickly. The ingest modules are grouped into pipelines and each file goes down the pipeline, module by module. A pipeline may have modules in the following order:
\image html ingest_pipeline.png
Multiple pipelines may be running at the same time. By default, two pipelines are running, but you can add more depending on how many cores you have on your system. You can configure the number of pipelines to make in the "Tools", "Options", "General" area.
Autopsy prioritizes user content over other types of files and will send data from the "Documents and Settings" folder or "Users" folder into the pipelines before the "Windows" folder. It prioritizes each folder in the system to ensure that user content is analyzed before other content.
\section ingest_running Running Ingest Modules
There are two ways to start ingest modules:
-# Immediately after you add a data source
-# By right-clicking on a data source from the tree in the main interface and choosing "Run Ingest Modules"
Once ingest is started, you can review the currently running ingest tasks in the task bar on the bottom-right corner of the main window. The ingest tasks can be canceled by the user if so desired.
<b>Note: sometimes the cancellation process make take several seconds or more to complete cleanly, depending on what the ingest module was currently doing. </b>
<b>Note: sometimes the cancellation process may take several seconds or more to complete cleanly, depending on what the ingest module was currently doing. </b>
The ingest message inbox will provide notifications when the particular ingest modules start and finish running. There may also be error notifications, and result notifications sent by specific ingest modules.
\section ingest_configure Configuring Ingest Modules
The results from the ingest modules can typically be found in the Results area of the explorer tree. However, some modules may choose to write results to a local file or to some other location and not make them available in the UI.
You will be presented with an interface to configure the ingest modules. From here, you can choose to enable or disable each module and some modules will have further configuration settings.
\section ingest_modules Ingest Modules
An ingest module is responsible for extracting data from and searching images. Different modules will do different things. Examples include:
\li Calculate MD5 hash of each file
\li Lookup MD5 hash in database
\li Detect file type of each file
\li Keyword search each file
\li Extract web artifacts (downloads, history, installed programs, web search engine queries, etc.)
\li Extract Email messages
\li Extract connected device IDs.
\li Extract EXIF meta-data from picture files
\image html select-ingest-modules.png
\subsection ingest_modules_config Configuring Ingest Modules
There are two places to configure ingest modules. When you select the module name, you may have some "run time" options to configure in the panel to the right. These are generally settings that you may want to change from image to image.
There are two places to configure ingest modules. When the Ingest Manager is launched, there may be a small set of options the module allows you to edit directly in the Ingest Manager. Additionally, the Ingest Manager may display an "Advanced" button, which will open up a larger configuration menu with more available settings. This advanced configuration menu can often be found in the "Tools" > "Options" menu, along with the advanced settings for numerous other ingest modules.
There may also be an "Advanced" button that is enabled in the lower corner. Pressing this button allows you to change global settings that are not specific to a single image. This advanced configuration panel can often be found in the "Tools", "Options" menu too.
Before launching ingest, you should go over the modules configuration by selecting every module in the list and review the current ingest module settings. Some modules need to be configured at least the first time Autopsy is used to have default configuration populated, otherwise they won't perform any analysis. Changing the modules configuration will potentially affect number of results found, it might also affect the total time required for ingest to run and how fast the results are reported in real-time.
\subsection ingest_modules_adding Adding Ingest Modules
Ingest modules can be created by third-party-developers and can be added independently of Autopsy. This can be done through Autopsy's plugin manager. This is accessible through the "Tools" > "Plugins" menu. Currently, the best way to add an ingest module is by navigating to the module's NBM file after choosing "Add Plugin..." in the "Downloaded" tab of the plugin manager. Autopsy will require a restart after any modules are installed in order to properly load and display them.
As an example, the hash lookup module will allow you to enable or disable hash databases in the "run time" options panel, but requires you to go to the "Advanced" era to add or remove hash databases from the Autopsy configuration.
\section ingest_results Viewing Ingest Module Results
\section message_inbox Message Inbox
\subsection ingest_message_inbox Ingest Message Inbox
The ingest message inbox is used by Autopsy to provide real-time updates during ingest. To open the inbox, click on the yellow warning sign in the top/right corner of the Autopsy window. The sign can display a number of incoming unread (not yet clicked) messages during ingest in its upper-right corner.
Ingest modules run in the background. An ingest module can provide you results in a variety of ways, but we recommend specific methods:
-# If they post results to the Blackboard, then you will find them in the "Results" area of the tree in the main interface.
-# They can send a message to the Ingest Inbox so that you get a message each time something really important is found.
\image html inbox-button.PNG
Ingest modules are able to post messages when notable events occur, such as a keyword or hash database hit. If a module posts many similar messages in a short time span, the inbox will group those messages so that unique updates are not lost among the noise.
The grouped messages are colored with different shades to indicate their importance; if a message group contains a lower number of unique messages, it is potentially more important than another group with a large number of unique messages. The more unique important messages have a lighter background color.
The ingest messages can be sorted by uniqueness/importance, or by chronological order in which they had appeared.
A message can be clicked to view the message details. When a message is clicked, it is marked as "read". When updates are posted with regard to a specific result or file, the message is linked to that file and the buttons in the top/right corner of the message details view can be used to browse to that data.
\image html inbox-main-screen.PNG
-# If the module is a wrapper around another forensics tool, they may simply provide a link to the output of that tool, in which case you will see a new entry in the "Reports" area of the tree.
\image html inbox-detail-screen.PNG
All of the official Autopsy modules send results to the blackboard, but if you install third-party apps, then they may choose any approach -- including a pop-up window each time they find something.
*/
*/
+28
View File
@@ -0,0 +1,28 @@
/*! \page XYZ_page XYZ Module
What Does It Do
========
What does it do?
Why would you use it?
Configuration
=======
Is there anything that you need to configure?
Using the Module
======
Ingest Settings
------
Are there runtime ingest settings?
Seeing Results
------
Where do you see results? In the tree?
*/
+7 -5
View File
@@ -19,13 +19,15 @@ Optimizing Performance
After installing Autopsy, there are several hardware-based things that we suggest you do to optimize performance:
1) Change the number of parallel pipelines that can be run at a time. The default is 2 pipelines, but this can be increased if you are running on a system with several cores. To do this:
- Run Autopsy from the start menu or desktop
- When presented with the case creation screen, cancel/close the menu window
- Select tools > options
- On the first tab, there is a drop down for "number of ingest" threads. We recommend that you set this value to be smaller than the number of cores minus two. If you set this number too high, performance can degrade because the pipelines are fighting for the same resources. Testing should be done to find an optimal setting.
- Run Autopsy from the Start Menu or desktop
- When presented with the case creation splash screen, cancel/close the window
- Select "Tools", "Options"
- On the "Autopsy" tab, there is a drop down for "Number of thread to use for file ingest". We recommend that you set this value to be smaller than the number of cores minus two. If you set this number too high, performance can degrade because the pipelines are fighting for the same resources. Individual testing should be done to find an optimal setting.
- After each change, restart Autopsy to let this setting take effect.
2) When making a case, use different drives to store the case and the images. The case directory is where the SQLite database and keyword search index is stored. This allows the maximum amount of data to be read and written at the same time.
\image html threadcount.PNG
2) When making a case, use different drives to store the case and the images. The case directory is where the SQLite database and keyword search index are stored. This allows the maximum amount of data to be read and written at the same time.
3) We have had best performance using either local solid state drives or fibre channel-attached SAN storage.
+79
View File
@@ -0,0 +1,79 @@
/*! \page interesting_files_identifier_page Interesting Files Identifier Module
What Does It Do
========
The Interesting Files module allows you to search for files or directories in a data source and generate alerts when they are found. You configure rules for the files that you want to find.
You would use this to be notified when certain things are found. There are examples below that generate alerts when VMWare images are found or when iPhone backup files are found. This module is useful for file types that will frequently have a consistent name and that may not be part of the standard checklist that you look for, or if you simply want to automate your checklist.
Configuration
=======
Add rules using "Tools", "Options", "Interesting Files".
All rules need to be part of a set. Sets need to have the following defined:
- Set Name (required)
- Set Description (optional)
Rules specify what to look for in a data source. Each rule specifies:
- Type: If the rule should be applied to only files, only directories, or both files and directories.
- Name Pattern: String to match the file name against.
- Name Pattern Type: Should the pattern be matched against the full file type or just the extension.
- Path Pattern: A substring of the parent path that must be matched. This allows you to restrict generic names to a specific structure (such as an application name). A substring match is performed.
- Rule Name: Additional details that are displayed in the UI when that rule is matched. Allows you to determine which rule in the set matched.
\image html interesting_files_configuration.PNG
VMWare Example
--------
This set of rules is to detect VMWare Player or vmdk files. This would help to make sure you look into the virtual machines for additional evidence.
NOTE: This is not extensive and is simply a minimal example:
- Set Name: VMWare
- Rule 1:
- Type: Files
- Full Name: vmplayer.exe
- Name: Program EXE
- Rule 2:
- Type: Files
- Extension: vmdk
- Name: VMDK File
iPhone Backups Example
-------------
This set of rules is to detect a folder for iPhone Backups. These are typically in a folder such as "%AppData%\Roaming\Apple Computer\MobileSync\Backup" on Windows. Here is a rule that you could use for that.
- Set Name: iPhone Backups
- Rule 1:
- Type: Directory
- Name: Backup
- Path: Apple Computer/MobileSync
Using the Module
======
When you enable the Interesting Files module, you can choose what rule sets to enable. To add rules, use the "Advanced" button from the ingest module panel.
When files are found, they will be in the Interesting Files area of the tree. You shoudl see the set and rule names with the match.
Ingest Settings
------
When running the ingest modules, the user can choose which interesting file rules to enable .
<br>
\image html interesting_files_ingest_settings.PNG
Seeing Results
------
The results show up in the tree under "Results", "Interesting Items".
\image html interesting_files_results.PNG
*/
+69 -29
View File
@@ -1,27 +1,18 @@
/*! \page keyword_search Keyword Search
/*! \page keyword_search_page Keyword Search Module
Autopsy ships a keyword search module, which provides the \ref ingest "ingest capability" and also supports a manual text search mode.
What Does It Do
========
The keyword search ingest module extracts text from the files on the image being ingested and adds them to the index that can then be searched.
The Keyword Search module facilitates both the \ref ingest_page "ingest" portion of searching and also supports manual text searching after ingest has completed. It extracts text from the files being ingested and adds them to a Solr index that can then be searched.
Autopsy tries its best to extract maximum amount of text from the files being indexed. First, the indexing will try to extract text from supported file formats, such as pure text file format, MS Office Documents, PDF files, Email files, and many others. If the file is not supported by the standard text extractor, Autopsy will fallback to string extraction algorithm. String extraction on unknown file formats or arbitrary binary files can often still extract a good amount of text from the file, often good enough to provide additional clues. However, string extraction will not be able to extract text strings from binary files that have been encrypted.
Autopsy tries its best to extract the maximum amount of text from the files being indexed. First, the indexing will try to extract text from supported file formats, such as pure text file format, MS Office Documents, PDF files, Email, and many others. If the file is not supported by the standard text extractor, Autopsy will fall back to a string extraction algorithm. String extraction on unknown file formats or arbitrary binary files can often extract a sizeable amount of text from a file, often enough to provide additional clues to reviewers. String extraction will not extract text strings from encrypted files.
Autopsy ships with some built-in lists that define regular expressions and enable user to search for Phone Numbers, IP addresses, URLs and E-mail addresses. However, enabling some of these very general lists can produce a very large number of hits, many of them can be false-positives.
Configuration
=======
Once files are in the index, they can be searched quickly for specific keywords, regular expressions, or using keyword search lists that can contain a mixture of keywords and regular expressions. Search queries can be executed automatically by the ingest during the ingest run, or at the end of the ingest, depending on the current settings and the time it takes to ingest the image.
Search queries can also be executed manually by the user at any time, as long as there are some files already indexed and ready to be searched.
Keyword search module will save the search results regardless whether the search is performed by the ingest process, or manually by the user. The saved results are available in the Directory Tree in the left hand side panel.
To see keyword search results in real-time while ingest is running, add keyword lists using the \subpage keyword_search_configuration_dialog "Keyword Search Configuration Dialog" and select the "Use during ingest" check box. You can select "Send messages to inbox during ingest" per list, if the hits on that list should be reported in the Inbox, which is recommended for very specific searches.
See (\ref ingest "Ingest") for more information on ingest in general.
Once there are files in the index, the \subpage keyword_search_bar "Keyword Search Bar" will be available for use to manually search at any time.
<!----------------------------------->
Autopsy ships with some built-in lists that define regular expressions and enable the user to search for Phone Numbers, IP addresses, URLs and E-mail addresses. However, enabling some of these very general lists can produce a very large number of hits, and many of them can be false-positives. Regular expressions involving backtracking can potentially take a long time to complete.
Once files are placed in the Solr index, they can be searched quickly for specific keywords, regular expressions, or keyword search lists that can contain a mixture of keywords and regular expressions. Search queries can be executed automatically by the ingest during the ingest run, or at the end of the ingest, depending on the current settings and the time it takes to ingest the image.
\section keyword_search_configuration_dialog Keyword Search Configuration Dialog
@@ -35,48 +26,97 @@ To create a list, select the 'New List' button and choose a name for the new Key
<b>List Import and Export</b> \n
Autopsy supports importing Encase tab-delimited lists as well as lists created previously with Autopsy. For Encase lists, folder structure and hierarchy is currently ignored. This will be fixed in a future version. There is currently no way to export lists for use with Encase. This will also be added in future releases.
<b>Lists tab</b> \n
\image html keyword-search-configuration-dialog.PNG
<br>
<b>String extraction setting</b> \n
The string extraction setting defines how strings are extracted from files from which text cannot be extracted because their file formats are not supported. This is the case with arbitrary binary files (such as the page file) and chunks of unallocated space that represent deleted files.
When we extract strings from binary files we need to interpet sequences of bytes as text differently, depending on the possible text encoding and script/language used. In many cases we don't know what the specific encoding / language the text is be encoded in in advance. However, it helps if the investigator is looking for a specific language, because by selecting less languages the indexing performance will be improved and a number of false positives will be reduced.
The default setting is to search for English strings only, encoded as either UTF8 or UTF16. This setting has the best performance (shortest ingest time).
The user can also use the String Viewer first and try different script/language settings, and see which setting gives satisfactory results for the type of text relevant to the investigation. Then the same setting that works for the investigation can be applied to the keyword search ingest.
<br>
<b> String Extraction tab</b>
\image html keyword-search-configuration-dialog-string-extraction.PNG
<br>
<br>
<b>General Settings</b> \n
<br>
<b>NIST NSRL Support</b> \n
The hash database ingest service can be configured to use the NIST NSRL hash database of known files. The keyword search advanced configuration dialog "General" tab contains an option to skip keyword indexing and search on files that have previously marked as "known" and uninteresting files. Selecting this option can greatly reduce size of the index and improve ingest performance. In most cases, user does not need to keyword search for "known" files.
<b>Result update frequency during ingest</b> \n
To control how frequently searches are executed during ingest, user can adjust the timing setting available in the keyword search advanced configuration dialog "General" tab. Setting the number of minutes lower will result in more frequent index updates and searches being executed and the user will be able to see results more in real-time. However, more frequent updates can affect the overall performance, especially on lower-end systems, and can potentially lengthen the overall time needed for the ingest to complete.
<b>Lists tab</b> \n
\image html keyword-search-configuration-dialog.PNG
<b> String Extraction tab</b>
\image html keyword-search-configuration-dialog-string-extraction.PNG
One can also choose to have no periodic searches. This will speed up the ingest. Users choosing this option can run their keyword searches once the entire keyword search index is complete.
<b>General tab</b>
\image html keyword-search-configuration-dialog-general.PNG
<!----------------------------------------->
<br>
Using the Module
======
Search queries can be executed manually by the user at any time, as long as there are some files already indexed and ready to be searched. Searching before indexing is complete will naturally only search indexes that are already compiled.
See (\ref ingest_page "Ingest") for more information on ingest in general.
Once there are files in the index, the \subpage keyword_search_bar "Keyword Search Bar" will be available for use to manually search at any time.
<!----------------------------------->
Ingest Settings
------
The Ingest Settings for the Keyword Search module allow the user to enable or disable the specific built-in search expressions, Phone Numbers, IP Addresses, Email Addresses, and URLs. Using the Advanced button (covered below), one can add custom keyword groups.
\image html keyword-search-ingest-settings.PNG
<br>
\section keyword_search_bar Keyword Search Bar
The keyword search bar is used to search for keywords in the manual mode (outside of ingest). The existing index will be searched for matching words, phrases, lists, or regular expressions. Results will be opened in a separate Results Viewer for every search executed and they will also be saved in the Directory Tree.
The keyword search bar is used to search for keywords in the manual mode (outside of ingest). The existing index will be searched for matching words, phrases, lists, or regular expressions.
<b>Individual Keyword Search</b> \n
Individual keyword or regular expressions can be quickly searched using the search text box widget. To toggle between keyword and regular expression mode, use the down arrow in the search box.
Individual keyword or regular expressions can be quickly searched using the search text box widget. You can select "Exact Match", "Substring Match" and "Regular Expression" match.
\image html keyword-search-bar.PNG
<br>
Results will be opened in a separate Results Viewer for every search executed and they will also be saved in the Directory Tree as shown in the screenshot below.
<br>
\image html keyword-search-hits.PNG
<br>
<b>Keyword List Search</b> \n
Lists created using the Keyword Search Configuration Dialog can be manually searched by the user by pressing on the 'Keyword Lists' button, selecting the check boxes corresponding to the lists to be searched, and pressing the 'Search' button.
\image html keyword-search-list.PNG
<br>
The results of the keyword list search are shown in the tree, as shown below.
<br>
\image html keyword-search-list-results.PNG
<br>
<b>Searching during ingest</b> \n
The manual search for individual keywords or regular expressions can be executed also during the ongoing ingest on the current index using the search text box widget. Note however, that you may miss some results if not entire index has yet been populated. Autopsy enables you to perform the search on an incomplete index in order to retrieve some preliminary results in real-time.
The manual search for individual keywords or regular expressions can be executed also during the ongoing ingest on the current index using the search text box widget. Note however, that you may miss some results if the entire index has not yet been populated. Autopsy enables you to perform the search on an incomplete index in order to retrieve some preliminary results in real-time.
The manual search for individual keywords or regular expressions can be executed also during the ongoing ingest on the current index using the search text box widget. Note however, that you may miss some results if the entire index has not yet been populated. Autopsy enables you to perform the search on an incomplete index in order to retrieve some preliminary results in real-time.
During the ingest, the manual search by keyword list is deactivated. A newly selected list can instead be added to the ongoing ingest, and it will be searched in the background instead.
Keywords and lists can be managed during ingest.
\image html keyword-search-bar.PNG
Seeing Results
------
The Keyword Search module will save the search results regardless whether the search is performed by the ingest process, or manually by the user. The saved results are available in the Directory Tree in the left hand side panel.
To see keyword search results in real-time while ingest is running, add keyword lists using the \subpage keyword_search_configuration_dialog "Keyword Search Configuration Dialog" and select the "Use during ingest" check box. You can select "Send messages to inbox during ingest" per list, if the hits on that list should be reported in the Inbox, which is recommended for very specific searches.
*/
*/
Regular → Executable
+24 -10
View File
@@ -18,19 +18,33 @@ The following topics are available here:
- Cases and Adding Data Sources
- \subpage cases_page
- \subpage ds_page
- Automated Analysis
- \subpage ingest "Ingest"
- \subpage hash_db_page
- \subpage keyword_search "Keyword Search"
- \subpage uilayout_page
- Automated Analysis (Modules)
<!-- Try to put in order they are shown in Ingest panel -->
- \subpage ingest_page "Ingest Modules"
- \subpage recent_activity_page
- \subpage hash_db_page
- \subpage file_type_identification_page
- \subpage archive_extractor_page
- \subpage EXIF_parser_page
- \subpage keyword_search_page
- \subpage email_parser_page
- \subpage extension_mismatch_detector_page
- \subpage e01_verifier_page
- \subpage android_analyzer_page
- \subpage interesting_files_identifier_page
- \subpage photorec_carver_page
- Manual Analysis
- \subpage directory_tree "Directory Tree"
- \subpage file_search "File Search"
- \subpage result_viewers "Result Viewers"
- \subpage content_viewers "Content Viewers"
- \subpage image_viewer
- \subpage timeline
- \subpage tree_viewer_page
- \subpage result_viewer_page
- \subpage content_viewer_page
<!-- - \subpage image_viewer_page Not released yet-->
- \subpage file_search_page
- \subpage timeline_page
- \subpage stix_page
- Reporting
- \subpage tagging_page
- \subpage module_install_page
If the topic you need is not listed, refer to the Help system in the tool or the wiki (http://wiki.sleuthkit.org/index.php?title=Autopsy_User%27s_Guide).

Some files were not shown because too many files have changed in this diff Show More