Autopsy Basics and Hands

On; Sections 0-4

___

Notes (5/22/20)

What is the course?

● Covers basics of using Autopsy; online version of 1-day course

● Assumes basic knowledge of digital forensics
○ Concepts like MD5 hashes and acquiring data are not covered
● Several videos and hands-on session in between many of them

What is Autopsy?

● Open source digital forensics platform

● Analyzes hard drives, smart phones, media cards, etc.
● Designed for ease of use, fast results (show info ASAP), extensibility (many plug-in
frameworks)
● Has the features you need (and more)
● Free to download and use
● Has commercial support and development backing
● Main UI is simple and other specialized UIs: timeline

Section 1: Basic Concepts

Section concepts

Goal: outline the general concepts before we make a case and start analyzing data

● Investigation workflow
● Deployment types
● Central repository

Basic Investigation Workflow

 ● Step 1: Make a Case by giving name and directory to case
● Step 2: Add a data source; add one or more data sources
● Step 3: configure ingest models; analyze data
● Step 4: review and manually analyze data from those modules and examine things
● Step 5: tag results to track them and use data in final report
● Step 6: generate report

Deployment types

● desktop/single user
● cluster/multi-user

Single-user Deployment

● Functionality
○ Cases can be opened by one person at a time
○ Similar approach to other forensics tool
● Technical:
○ Everything runs on a single computer
○ Works out of the box with installer
○ Launching autopsy will start all embedded services

Multi-user deployment

● Functionality
○ Cases can be opened by many users at the same time
○ Allows auto ingest mode; media is auto analyzed non-stop by multiple nodes
○ Faster analysis; db is faster
● Technical
○ User experience is the exact same
○ Uses central servers dbs, text index, etc.
○ Uses central high speed storage

Central repository

● Database that stores data from past cases

○ MD5 Hash values, Comments, Wifi SSIDs, etc.
● Why is it needed?
○ Allows you to easily access important data from past cases
 ○ Autopsy typically has case-specific databases; easy to manage, dbs are smaller,
allows for archival

Use cases

● “Other occurrences” content viewer shows you if file was in past case
● Comments about a file can be stored in the CR and shown when file is seen again
● Centralize management of notable hash sets
● Auto flags files if they were previously tagged as notable

Central Repository Deployment Types

● SQLite
○ Requires no other installations
○ Can be used by only one user at a time (do not put on a network share and have
multiple examiner using it at the same time)
● postgreSQL
○ Database is stored on a server
○ Can be used by multiple users at a time
○ Can use the same server for multi-user cases

Picking a type

● If you are a single-person shop, stick with SQlite

● Multiple people → PostgreSQL

Section 2: Installation
● Outline how to install and configure Autopsy

Basic steps

● Install Autopsy on each examiner’s computer; can install multi-user cluster services
● Configure each Autopsy client

Installing Autopsy on Windows

● Needs to be installed on computer/VM; applies to both deployment

● Download .msi installer → use defaults values → install in a version specific folder; can have
multiple versions at same time
Installing Multi-User Services

● Details are in the Autopsy documentation

● Should have at least 2 dedicated servers and Central NAS storage
● Install PostgreSQL and ActiveMQ on one server; Solr on the other
● Ensure all clients can access central storage at the same UNC or drive letter path

Config

● Go to multi-user section of options → fill in names of host and user; test each connection

Config Central Repo

● Step 1 -- enable: tools, options, central repository panel

● Step 2 -- SQLite Repository: Default location is in your AppData folder; PostgreSQL:
enter server name, user name, password

Machine Translation Config

● Enter google/microsoft key, details in doc; tools, options, translation

Other config

● Other things to set up; hash sets, keywords, etc.

Section 3: Cases and Data Sources

● Outline basic ideas about organizing data into a case and how to add data to the case
○ Creating cases
○ Adding data sources
○ Types of supported data sources

What is a Case?

● Groups investigation data for analysis

● Up to you how many cases created
○ By investigation or host within investigation
● Factors
○ One case at a time
○ Reporting is done at case-level
● Cases are autosaved
Creating a case

● Step 1: name and other info

● Step 2: optional info to add to case

Case directory

● Each case has directory

● Notion of ‘base’ directory like C:\cases
● Makes a folder in the base directory with case name
● Multi-user cluster, examiners need to all have access to case dir at same path

Case directory contents

● Autopsy.db: SQLite database that will store basic case info and data source info unless it
is a multi-user caser
● Export folder: default location to store exported files
● Reports folder: default location to store reports
● ModuleOutput folder: default location for modules to write output to

What are data sources?

● Data you want to analyze

● Autopsy supports disk images, local drives, local/logical files, output from logical
imager, unallocated space files (no structure)
● Brought to add data source after making case; choose type

What happens depends on the data source

● Goal is to populate the case database with basic info about source and files inside
○ Size and name info of E01 files are added; system is scanned and a row is created
in database for each file

What gets stored in the database?

● File metadata (name and parent folder path, times, etc.)

● Partition layouts and others of lots of tables
● Database only has metadata, stays fairly small

Disk image formats

Supported formats:
 ● Raw (dd) single and split, E01, raw of phones, VM , etc
● Point autopsy at first image → will do rest
○ 001 -> 002, etc.
● Does not validate E01 files directly on input

Analysis

● The sleuth kit (TSK) to analyze contents of image

● Detects volume systems that break the disk into partitions
● Detects file systems that organize a partition so that files can be stored

Volume system analysis

● Volume systems organize disk image into one or more partitions

● Located near beginning of disk image
● autopsy/TSK supports DOS, GPT, legacy formats
● Autopsy will show areas of disk that are not in volume
● Each volume is analyzed to look for a file system
○ No volume found, entire image will be analyzed

File system analysis

● Allows files to be stored; located at beginning of disk image or inside volume

● Supports NTFS, FAT, ExFat, HFS+, etc.

Orphan files

● No longer have parent folder and deleted; accessible in $OrphanFiles folder

● Finding them in FAT files is time intensive
○ Every cluster read and analyzed
○ Can be disabled when image is added

Carving

● Recovers deleted files w/o relying on system knowledge

● Relies on file structure internals; JPEG, PDF, EXE, etc.
● Needed when file system doesn’t have pointers to file content anymore
● File1.jpg → metadata → blocks; when deleted, unallocated and separated and picture is still at
the bottom

Process
 ● Scan each unallocated block to see if file type starts there
● When found, scan for footer for that type (starts with JPEG header, ends with footer)

In autopsy

● Includes photorec/open source tool; runs on allocated space

● Added to $carvedfiles folder
● Technically not done when data source is added; with ingest models

Unallocated space

● Represented in Autopsy as files; directly in volume/$Unalloc folder

● Name structure is -Unalloc_ParentID_StartByte_EndByte

Adding a disk image

● Add data source → disk image option → popup for adding disk images and navigate path, all
info

Limitations

● No RAID (redundant array of independent disks)

● No logical volume management/dynamic disks
● No bitlocker

Data sources: Local Drives

● Local drives are your C: or E: drives

● You can analyze them
○ Preview a live system (triage)
○ USB-attached device (write blocker)

Analysis

● Same process as disk images

○ Scan volumes & file systems; add files to database
● Will need to run as admin for all access to drives
● Analysis cannot be performed if USB device is removed
● Goes to popup, add info

VHD file
 ● Allows you to make a ‘sparse VHD’ image while you analyze a local drive
○ Useful for triage situations
● When data is read, Autopsy determines if sector has been seen; if not → save copy
● Analyze entire drive = complete image
● Makes copy of data read to do later on analysis on results

Making

● Choose “make a VHD...” option

● By default it will pick file name in case folder
● Choose the “update database...” option if you want Autopsy to update the case db to refer →
VHD file after complete
○ Otherwise will have reference to \\.\E: or something

Local files

● Local files are those that are stored on file system (collection of JPEG or word, L01 file)
● User specifies file/folder to add
● Folders are recursively added
● Basic info about each file is added to DB
○ Time are ignored
○ Files are not copied or moved
■ Manually copy if they are on USB
● Files added at the same time are grouped together in the UI -- local file sets

Summary

● Data sources are what you add to a case

● Adding a data source means structure is analyzed and metadata is added to db
● Autopsy supports disk images, local drives, local files

Section 3: Lab
● Reinforce concepts in videos with hands-on exercises
● Provided text about what to do and questions; write down answers to use them in follow
up quiz

Workflow Caveat

● Order the lab is done is not like a real investigation

 ● Only often run a subset of modules just learned about
● In practice, run all relevant modules at the same time for faster performance
● Done in this order for understanding, and not waiting until the end for hands-on

Data set high-level scenario

● renzik/mascot has been dognapped, ransom notes have been sent

● Nappers are spotted at shopping complex and get away as nation is on high alert
● Police are able to find a laptop in a car in the parking lot; scenario starts with analyzing
laptop
● Police obtain search warrant for house that car was registered to
● Nothing obvious is found until a K9 named Siri finds a hidden media card (incorperated
at the end of labs)

Lab answers
1. There are 8 volumes in the disk image
2. The name of the unallocated space file in vol1 is Unalloc_3_0_1048576
3. The file system for vol7 is NTFS

Windows questions

1. The name of the db is ‘autopsy’

2. The database is 225MB big, roughly 230

Section 4: UI basics
Outline basic UI concepts needed after data is added to case

● UI flow
● Contents of the tree
● Ways to view file contents

Basic UI flow

● Tree on left-hand side; you can find everything in the tree

● From tree → file, volume, etc. → can view images, etc.

The tree
Structure

● 5 top-level nodes: data sources, views, results, tags, reports

“Data sources” area

● Shows data in the case organized by drive layout and directories

● Allows you to find specific files by path
○ You explicitly want to see their desktop folder
● Collapsed by default; faster and more specific with background analysis like hash hits

“Views” area

● Shows files organized by metadata

● Same data as data sources, organized differently

View by type

● Use this area to focus on files of a certain type

○ Images, documents, executables
● Can organize by extension or file sig (MIME type)
○ Extension filtering can be done immediately
○ File type filtering requires all files to be analyzed

View by size

● Use this area to find large files

○ Encrypted volumes, virtual disks

Results area

● Shows results from analysis ingest modules

● Has lower-levels of organization
○ Extracted content contains most; most falls here be default
○ Specialized ones are separated out; hash hits

Tags and reports area

● Tags area shows what files and results have been tagged
● Reports area shows the reports generated by the user or a module

Groups by data source

 ● Tree is organized with top level nodes by default; can choose how to organize the tree
by data sources
○ Easier to focus on results for specific data source; usually 2 data sources merged
but not grouped
● Change grouping in 2 different ways: display settings and gear setting
● Also prompted if there are over 5 data sources in case

The table

Viewing tree contents

● When node is selected, contents are shown in upper right

● By default, table view is shown; can rearrange columns that will be saved
● Results organized to pgs to improve performance
● Note: can search within the table by typing when any row is selected

Table icons

● Many rows have 3 columns to give you quick context about an item
● First column -- Score (S)
○ Stop sign with ! means item is notable; could be hash hit or a notable tag applied
○ Yellow sign with triangle means item was suspicious; module marked it as
interesting or tag was applied normally
● Second column -- Comment
○ Yellow page shown if file has a comment
○ Either in current case or past with Central Repo
● Third column -- Occurrences
○ How often item has been seen in past cases (requires Central Repo) to see which
files are unique and how interesting it might be

Translating file names

● Names can be translated (if configured) with Google/Microsoft

○ Original name in first column, second is translation

Thumbnails

● Use thumbnail tab to see images and videos; identifies them and shows thumbnails for
them
Content viewers

● Displays contents or metadata of selected item

Hex viewer

● Shows raw content in usual form with offset on left, numbers in middle, actual text on
right
● Always enabled if file has content
● Can launch HxD for more powerful features

text/strings

● Text contains various “sub viewers” that are all related to text
● Strings show data that could be text in a given encoding
○ Can have false positives

Text / Indexed text

● Shows what is in the keywork search index

● For supported file types, shows text after parsing structure and knows how to do so
○ Knows PDF vs. DOC
● For unsupported → strings

text/translation

● Uses google or bing translate when configured; translates same text as shown in
“indented text”

Application

● File type-specific viewer: pictures, video, SQLite, HTML, Registry, Binary PList, etc.
● Not a generic viewer like hex or raw text***; only enables if supported
● If picture put into application view, shows it and allows for rotation and zooming
● Plays videos
● Will give pulldown tab with all tables when looking at db/sql, all rows and can page
through them; not very powerful but to see basics; to do more, export
● Can display HTML files and remotely load images (optional to load)
○ Will strip out tags that will reach out to some website; may have evidence and
notify someone but only so much can be done (can download full image to avoid
detection)
Message

● Email-like display for email and text messages; includes header info, RTF, HTML
● Dedicated message reviewer, straight forward and has all info

File metadata

● Shows metadata about a selected file; similar to data in table, easier to copy and paste
● May not have all info from hash hits, under is output from sleuth; lots of info not stored
and usually generic, but can utilize this output for more info

Results

● Shows all analysis results performed and data extracted on selected item
● Data comes from database blackboard

Annotations

● Shows all examiner-specified data, tags and comments

○ Data from both current and past cases (again C. Repo)

Other occurrences

● Shows where else the selected item was seen

○ occurrences on other data sources in same case/past cases (C Repo)

3rd party: text summarizer and video triage

● Not part of open source package; name finder and translator

○ Uses basis technology analytics
● Second module gives snapshots from parts of vid to see if there is data hiding

Defaults

● When a new file is selected, can either stay or name viewer/choose most relevant one
○ Hex and strings are only relevant viewer if nothing else is (depends on Autopsy
decisions)
● To change, use gear icon above tree and to change it to only stay on 1 viewer

Other

● History buttons to pull out of dead end lead; forward and back
● Progress bars and cancellation when using ingest modules
 ● Ingest inbox shows what has been found in background tasks, records number of unread
messages and can scroll down through to investigate
● File searching by metadata; search db for files with all criteria except for keywords
● File exporting, viewing, etc. through right click actions
○ Can export, view in external view/new (“undocked”; floats around and won’t
change to keep around or as reference) content viewer

Additional interfaces

● Nearly all data can be found in main UI

● More focused interfaces:
○ timeline -- displays events sorted by time
○ Image gallery -- pictures and vids by folder
○ Communication -- accounts, messages, call logs, etc.
● Can be opened from toolbar

Section 4 Lab
1. There are 8 databases by extension (6 dbs last section)
2. The size of the largest database is 5242880 bytes
3. There are no dbs with MIME type yet
4. The names of the files between 200MB and 1GB are $BadClus:$Bad, Winre.wim,
chrome.7z