Wednesday, Feb 3rd, 2010
Posted By eoghan

At long last and with the help of many talented experts, I have put together a new Handbook. This book provides an advanced reference for conducting digital investigations and performing forensic examinations. The first part of the book provides comprehensive methodologies and practical tips from experienced practitioners in the areas of forensic analysis, electronic discovery and intrusion investigation. The second part of the book delves into technical aspects of digital evidence on computers, networks, and embedded systems. The technologies covered include Windows, UNIX, and Macintosh computers, cellular telephones and other mobile devices, networks and mobile telecommunications technology.


The Network Investigations chapter written by cmdLabs personnel is available in PDF form upon request.


F-Response is giving a copy of the Handbook with purchase of their tool:
Buy F-Response, Get a copy of The Handbook of Digital Forensics and Investigation

My deepest thanks to the contributors: Cory Altheide (Mandiant) – Christopher Daywalt (cmdLabs) – Andrea de Donno (Lepta) – Dario Forte (DFLabs) – James Holley (Ernst & Young) – Andy Johnson (University of Maryland, Baltimore County) – Ronald van der Knijff (Netherlands Forensic Institute) – Anthony Kokocinski (CSC) – Paul Luehr (Stroz Friedberg) – Terrance Maguire (cmdLabs) – Ryan Pittman (US Army) – Curtis Rose (Curtis W. Rose & Associates) – Joseph Schwerha (TraceEvidence) – Dave Shaver (US Army) – Jessica Reust Smith (Stroz Friedberg).

(No Comments)

Thursday, Dec 10th, 2009
Posted By Christopher

Mobile device forensics tools have come a long way in the past year, giving us access to more data on a wider range of devices. Even when a full copy of physical memory is not possible, for many devices the complete logical file system can be acquired. Although this generally does not include deleted items, it can still provide access to substantial digital evidence including MMS messages, IM fragments, and Web browsing history.

However, even when a tool can acquire the entire file system from a mobile device, it may not be able to display items of interest like MMS messages. In such situations, the forensic examiner must locate the desired information within the file system and interpret it themselves.

This is one of the main reasons why it is important for practitioners to have an understanding of the underlying technology, and not be overly reliant on automated tools.

Locating MMS Data

A good example of when a tool can acquire but not display evidence of interest came up in a recent case involving MMS messages on a Verizon LG phone. Although the commonly used tool called Cellebrite could acquire data from the mobile device, including a copy of the file system, it did not present MMS messages in the output report. As a result, the investigating agency was only able to view the incriminating evidence through the device itself by performing a manual “scroll” examination.

Until cmdLabs came along to help…

By examining the file system acquire using Cellebrite, we found MMS messages in the “mms” folder on the LG device. For the sake of illustration, this file system location is shown using BitPim.

The MMSMsg.db file contains metadata associated with the messages, and the PDU files contain the original file name as well as the actual data of the pictures and videos in the message. The header of one PDU file is shown here, revealing some Synchronized Multimedia Integration Language (SMIL) tags and the original file name on the device (0920091201a.3g2).

Even after the original video file is deleted from the device, a copy remains in the MMS message.

Extracting MMS Data

The media portion of the PDU message file can be extracted using simple file carving techniques. Although you could remove the file header manually using a hex editor, it is more effective to use a file carving tool like Foremost. By automating the file carving process, your process is repeatable. In addition, Foremost generates an audit log that can be useful for forensic documentation purposes.

The file header (a.k.a. signature) of the 3gp videos from an LG VX series device is “ftyp3g2a” preceded by 4 bytes. The configuration entry for the Foremost file carving tool is shown here:

3gp	y	4000000	????\x66\x74\x79\x70\x33\x67\x32\x61

Using a configuration file that contains the above signature, the command ‘foremost -c foremost.conf MMS*‘ will extract the 3gp video content from PDU files acquired from an LG device. The resulting videos will be saved in the default Foremost output directory and can be played using Quicktime as shown here.

For those forensic practitioners who are interested in learning more about mobile device forensics and related data recovery techniques, cmdLabs is teaching the SANS Mobile Device Forensic course (SEC 563) in New Orleans from January 11–15, 2010 and again in San Antonio from January 25–29, 2010.

(No Comments)

Friday, Aug 21st, 2009
Posted By admin

An increasing number of programs are employing SQLite to store data that can be of relevance in an investigation. Forensic practitioners who become familiar with SQLite and learn how to interpret these files will be in a better position to obtain the most usable information from available digital evidence. We cover this and other useful forensic techniques in our Mobile Device Forensics course (SANS SEC563).

Backup files from an iPhone or iPod Touch provide an excellent example of SQLite databases that digital forensic examiners can exploit with relative ease, provided they are not encrypted. Data backed up from an iPhone using iTunes such as call logs, contacts, multimedia, and other files are, by default, stored in SQLite database files under “~/Library/Application/Support/MobileSync/Backup” Mac. On Windows XP these backup files are stored in the user’s profile under “C:\Documents and Settings\[userprofile]\Application Data\Apple Computer\MobileSync\Backup” and Windows Vista has a “Roaming” subfolder in this path.

SQLite databases can be examined using a command line tool like sqlite3.exe (http://www.sqlite.org/) or with a GUI tool like SQLite Database Browser (http://sqlitebrowser.sourceforge.net/) shown here with the call log backed up from an iPhone.

The dates are in Unix string format and can be converted using Perl as shown here:

$ perl -e "print scalar(gmtime(1247848584))"
Fri Jul 17 16:36:24 2009

The use of SQLite databases gives forensic practitioners the ability to query the available data directly using the SQL database language. Although a full treatment of SQL is beyond the scope of this discussion, simple examples are provided here to get you started.

C:\>sqlite3.exe E:\iPhoneBackup\call_history.db
SQLite version 3.6.16
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
_SqliteDatabaseProperties call
sqlite> select * from call WHERE address like '%868%';
2|+186835xxxxx|1247848584|60|4|-1
3|+186835xxxxx|1247853361|0|5|-1
4|+186835xxxxx|1247854453|0|5|-1
9|+186831xxxxx|1247895923|60|4|-1
10|+186835xxxxx|1247936960|60|5|-1
11|+186835xxxxx|1247941792|0|4|-1
12|+186835xxxxx|1247941827|0|4|-1
13|+186835xxxxx|1247941920|0|4|-1
14|+186835xxxxx|1247942844|0|4|-1
16|+186835xxxxx|1248015352|60|4|-1
17|+186835xxxxx|1248015674|0|4|-1
18|+186835xxxxx|1248016092|0|5|-1
26|+186835xxxxx|1248177103|0|5|3

The Symbian operating system for mobile devices also makes use of SQLite databases, and other computer applications store investigatively useful information in SQLite databases, including Firefox 3 and Skype. For instance, the moz_places table in the places.sqlite file from Firefox 3 is shown below.

This file can also be queried using SQL, as shown here being queried for all URLs containing the cmdLabs web site.

C:\tools>sqlite3 E:\firefox\places.sqlite
SQLite version 3.6.16
Enter ".help" for instructions
Enter SQL statements terminated with a ";"

sqlite> .tables
moz_anno_attributes  moz_favicons         moz_keywords
moz_annos            moz_historyvisits    moz_places
moz_bookmarks        moz_inputhistory
moz_bookmarks_roots  moz_items_annos

sqlite> select * from moz_places WHERE url like '%cmdlabs%';
621|http://www.cmdlabs.com/|Home|moc.sbaldmc.www.|1|0|1||2000
622|http://www.cmdlabs.com/page11/page11.html|Blog|moc.sbaldmc.www.|1|0|0||100
623|http://www.cmdlabs.com/services/services.html|Services|moc.sbaldmc.www.|1|0|0||100
624|http://www.cmdlabs.com/services/services/services-4.html|Training and Education|moc.sbaldmc.www.|1|0|0||100

Programs like Firefox that maintain usage records in these databases may leave remnants of deleted items that may be recoverable from unallocated disk space as detailed in Murilo Tito Pereira’s article “Forensic analysis of the Firefox 3 internet history and recovery of deleted SQLite records” (www.digitalinvestigation.net).

(1 Comment)

Wednesday, Jul 15th, 2009
Posted By admin

Eoghan Casey delivered the presentation “Expert Briefing: Mobile Device Forensics Essentials” on behalf of cmdLabs at the SANS WhatWorks in Forensics and Incident Response Summit on July 8. SANS has made this presentation available via webcast at the following URL:

https://www.sans.org/webcasts/show.php?webcastid=92648

If you have any comments or suggestions regarding the presentation or anything else, please shoot us an e-mail at contact@cmdlabs.com.

(No Comments)

Wednesday, May 27th, 2009
Posted By admin

Here are some examples of lesser known application metadata in Microsoft Office documents that we have encountered in casework, and that we presented at the annual meeting of the American Academy of Forensic Sciences in February.

Files created using Microsoft Office applications have more metadata than many forensic practitioners realize. Word documents, Excel spreadsheets, Powerpoint presentations, and Outlook e-mail messages are essentially a file system within a file. They are structured storage files that use OLE to create the equivalent of folders (called storages) and files (called streams).

For example, consider metadata embedded within Word 2003 documents. The Summary Information metadata extracted from a Word document using Harlan Carvey’s wmd.pl Perl script is shown here:

--------------------
Summary Information
--------------------
Title : cmdLabs
Subject :
Authress : LastName FirstName
LastAuth : LastName FirstName
RevNum : 39
AppName : Microsoft Word 11.4.2
Created : 01.28.2009, 12:12:00
Last Saved : 02.05.2009, 00:36:00
Last Printed : 02.03.2009, 15:08:00

Beyond the Summary Information metadata that most forensic practitioners are familiar with and many tools can extract, Word documents also have a FILETIME value in the ROOT ENTRY header that records the last time a document was altered. This value can provide the last modified time of a document even if the timestamps in the file system or Summary Information metadata have been maliciously altered (utilities are available that make such tampering simple).

An example of this date-time stamp in the ROOT ENTRY header is provided here (2/5/2009 12:36:04 AM):

Forensic examiners should also be aware that Microsoft Office documents have embedded metadata associated with individual objects within the file, as shown here using SSView (http://www.mitec.cz/).

Excel also contains an abundance of metadata stored within its Binary Interchange File Format (BIFF5 – 8). For instance, the cells that were selected the last time a spreadsheet was saved, and the registered name that most recently opened the document with write access. Much of this metadata is accessible using BIFFView (http://b2xtranslator.sourceforge.net). A portion of the BIFFView output with the WRITEACCESS field is show here:

Reading the documented file formats of Microsoft Office files (http://msdn.microsoft.com/en-us/library/cc313118.aspx) can help forensic practitioners delve deeper into metadata, but can also be misleading and inaccurate. Therefore, it is crucial to perform controlled experiments to locate and understand the meaning of specific metadata.

(1 Comment)

Sunday, May 17th, 2009
Posted By admin

In Mobile Device Forensics, it is often necessary to use multiple methods and tools to obtain the most useful information from the device. For example, let us look at acquisition challenges associated with Windows Mobile.

Security configuration is one of the first barriers to acquiring digital evidence from a device running Windows Mobile, even when there is no password protection. The reason is simple: Windows Mobile is often configured to prevent unsigned applications from running. Many forensic tools need to transfer and execute a customized application on the mobile device in order to acquire data. So, if the software agent for a particular forensic tools is not signed, it will not run and you will not get any data.

Even when this security protection is disabled, files that are routinely used by the operating system cannot be copied using certain tools, including some forensic acquisition tools. For instance, an attempt to copy the pim.vol file using Microsoft’s Remote File Viewer generates an error as shown.

In the case of pim.vol, this file can be copied logically when a Windows Mobile device is mounted via ActiveSync. However, you will have no such luck copying files like cemail.vol and the registry (mxip_system.vol) in this way. Although some mobile device forensic tools can extract limited information from these locked files, it is important to also have a copy of the original file for forensic examination.

Warning: some forensic tools will appear to copy files that are locked by the Windows Mobile operating system, but do not actually acquire the contents, resulting in an empty file container in the case file. The tool may tag the file as locked, but there is not log/error generated so you would have to be looking closely at the specific file to see this. An unsuspecting forensic examiner might perform a keyword search of acquired data with no results, not realizing that relevant data had not been acquired.

To gain access to more digital evidence on Windows Mobile devices, including some deleted data, it is necessary to get physical. For example, using a forensic tool like XACT, which is designed to acquire and analyze physical memory of mobile devices, it is possible to extract significant amounts of data from Windows Mobile devices, including files like cemail.vol, pim.vol, and the registry. Data in an acquired cemail.vol file, which includes text message (SMS), are displayed here with some text readily viewable.

Acquiring these files is only the first challenge. It is then necessary to interpret the data they contain. Interpreting text message and other useful data structures found in files and raw memory on mobile devices can give additional interesting information, including associated metadata. One approach that can be effective in some cases is to view the acquired file in a Windows Mobile emulator using a utility like Pocket dbExplorer. Although it can be fruitful to examine acquired data in this way, it may not provide access to all of the information you might be interested in relating to an investigation. This is why it is important to also use forensic tools that can query the operating system for specific details about the data it contains (even if they cannot copy the entire container file). Acquiring the same Windows Mobile device using .XRY provides the following valuable metadata associated with the raw data displayed above, including the timestamp associated with the message and what folder it is stored in on the device.

Bottom line: to obtain the most information from an evidentiary device it is advisable to acquire data using multiple tools and, wheneve feasible, performing both a logical and physical acquisition. In the upcoming SANS Mobile Device Forensics course [http://www.sans.org/training/description.php?mid=1297] in Baltimore on July 27-31, we cover logical and physical acquisition and analysis of cell phones. We have plenty  of hands-on exercises employing a variety of tools to help practitioners develop the ability to acquire and  analyze data from various kinds of mobile devices.

(No Comments)

Friday, May 8th, 2009
Posted By admin

Despite the fact that FAT is one of the earliest file systems that forensic practitioners had to deal with, there are still gaps in knowledge that result in misinterpretation and misrepresentation. A prime example of this is the create time in FAT, which is not calculated correctly by some forensic tools. This issue came up in a recently discussion I had with Geoff Fellows (http://www.f3.org.uk/modules/smartclient/client.php?id=3). Although FAT last write timestamps only have a resolution of 2 seconds, whereas the create time has a resolution of 10 milliseconds that some forensic tools fail to take into account. A difference of milliseconds can be important in some cases, and any calculations based on an incorrect representation of creation timestamps will be incorrect.

The confusion arises from the fact that FAT file systems represent create and last write timestamps slightly differently. Last write timestamps are 32 bit little-endian values, interpreted as follows:

24                 16                8                0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Y|Y|Y|Y|Y|Y|Y|M| |M|M|M|D|D|D|D|D| |h|h|h|h|h|m|m|m| |m|m|m|s|s|s|s|s|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

\____________/\________/\_________/ \________/\____________/\_________/
year        month      day        hour       minute       second

Take as an example the following FAT folder entry with the last write date highlighted in bold:

$ icat /dev/sdb1 353884 | xxd
0000000: 2e20 2020 2020 2020 2020 2030 004f b079 . 0.O.y
0000010: 763a 763a 0000 b579 763a a502 0000 0000 v:v:…yv:……
0000020: 2e2e 2020 2020 2020 2020 2010 004f b079 .. ..O.y
0000030: 763a 763a 0000 b079 763a 6605 0000 0000 v:v:…yv:f…..
0000040: 4173 0061 006c 0076 0065 000f 009e 6e00 As.a.l.v.e….n.
0000050: 6500 7700 3400 2e00 6700 0000 6900 6600 e.w.4…g…i.f.
0000060: 5341 4c56 454e 7e31 4749 4620 0075 78b9 SALVEN~1GIF .ux.
0000070: 753a 763a 0000 78b9 753a 9212 c1d4 0000 u:v:..x.u:……
0000080: 4269 0066 0000 00ff ffff ff0f 0014 ffff Bi.f…………
0000090: ffff ffff ffff ffff ffff 0000 ffff ffff …………….

Converting to big-endian gives 3a 75 b9 78, which has the following binary representation:

00111010 01110101 10111001 01111000

This translates to a timestamp of 2009.03.21 23:11:48 as follows:

• 7 bits = 0011101 = 29 years since 1980
• 4 bits = 0011 = 3 months
• 5 bits = 10101 = 21 days
• 5 bits = 10111 = 23 hours
• 6 bits = 001011 = 11 minutes
• 5 bits = 11000 = 24 = 48 seconds

Note that 5 bits cannot store all 60 seconds, so last write timestamps must be incremented in 2 second intervals, and is always an even number of seconds.

Although the create time follows this same general calculation, it uses an additional 8 bits to represent one hundredths of a second. In the same directory listing above, the create timestamp is identical to the last modified timestamp except for an additional byte (75 78 b9 75 3a). The additional byte equates to 117 hundredths of a second, which brings the create time to 2009.03.21 23:11:49.17. Thus, the create time can have odd number of seconds, and has a resolution of 10 milliseconds.

Older versions of XWays Forensics had the option to display timestamps to tenths of a second, and newer versions can be configured with greater precision as shown here:

Note: Updated configuration screenshot showing increased precision in XWays 15.1 SR3 provided by Geoff Fellows.

The create timestamps for files copied onto a thumb drive are shown here in XWays Forensics with tenths of seconds displayed:

However, some other forensic tools like TSK only interpret the first four bytes of the create date-time stamp, limiting the resolution to 2 seconds. This is demonstrated in the following listing of the same files as those listed above using XWays (we have reported this bug and it will be fixed in the next release of TSK).

$ fls -l /dev/sdb1 353884 | awk {’print $3 “\t“ $10 “\t“ $11 “ “ $12′} | sort –key 2
snake_oil.jpg 2009.03.21 23:03:32 (EDT)
orange-Clark_Stanley_Snake_Oil.png 2009.03.21 23:04:32 (EDT)
orange-OilKingLrg.jpg 2009.03.21 23:04:48 (EDT)
orange-Drs_Mixer.jpg 2009.03.21 23:05:24 (EDT)
orange-Hostetters_Bitters.jpg 2009.03.21 23:05:42 (EDT)
orange-wine_of_tar.jpg 2009.03.21 23:05:54 (EDT)
orange-medsh17.jpg 2009.03.21 23:06:04 (EDT)
orange-miraclecure.jpg 2009.03.21 23:06:14 (EDT)
snakeoil.jpg 2009.03.21 23:07:22 (EDT)
snake-oil2.jpg 2009.03.21 23:08:16 (EDT)
banjsalv.jpg 2009.03.21 23:11:30 (EDT)
salvenew4.gif 2009.03.21 23:11:48 (EDT)
yankdcornsalvelg.jpg 2009.03.21 23:12:36 (EDT)
liniment-for-man-and-beast.jpg 2009.03.21 23:12:50 (EDT)
Thumbs.db 2009.03.22 14:25:12 (EDT)

This issue was recently fixed in EnCase version 6.12, and is documented in the release note as “339: EnCase does not read FAT Create Date correctly (BUGID67).” EnCase version 6.12 now displays the create time to the correct second but not the hundredth of a second.

If a forensic examiner is not aware of this error, it can not only introduce inaccuracies into his/her findings, it can also reflect poorly on his/her expertise in this area.

The fact that this bug has existed in EnCase and other widely used forensic tools clearly demonstrates the need to validate important findings using more than one tool. Furthermore, this issue demonstrates that forensic practitioners cannot simply push buttons and unquestioningly rely on the results, but rather must understand the underlying technology sufficiently to double check what their tools are reporting.

Another area relating to FAT file systems where current literature is incorrect is in file allocation strategies but that discussion is for another time…

(No Comments)