Digital Detective Group

NetAnalysis Date and Time Fields

July 13th, 2010 Posted in NetAnalysis, Web Browser Forensics

Jul, 13 2010

Some of you will have noticed that from NetAnalysis v1.50 there have been numerous new date and time columns added. These new timestamps were identified during months of research and development and are now included with the latest release. Figure 1 shows some of the new fields from Internet Explorer. This article will look at each of the new columns and explain what they mean.

Figure 1

Last Visited [UTC]

This column should be self explanatory. It is the timestamp which reflects the last known recorded visit to a webpage (or object) in Coordinated Universal Time (UTC). Normally, this timestamp is extracted directly from the source record and not changed in any way by the time zone information set in NetAnalysis. With the exception of Internet Explorer Weekly INDEX.DAT records, all other records have their timestamps saved as UTC values. Weekly records are stored as local times and therefore have to be converted to UTC to fill this column.

Last Visited [Local]

This column contains the timestamp which reflects the last known recorded visit to a webpage (or object) in Local time. This timestamp is calculated by using the data from the Last Visited [UTC] column and converting it to Local time using the time zone information set in NetAnalysis prior to extraction (with the exception of Daily INDEX.DAT records which is already stored in Local time).

Date Expiration [UTC]

This column contains a timestamp (in UTC) which reflects the date and time when the object or record is no longer regarded as valid by the browser. For example, in History records, you will see that the expiration time is set according to the amount of days the browser is set to keep history records, whilst the cache expiration time can be set by the web developer and is delivered to the browser during the HTTP response. This column reflects the ExpireTime field in the INTERNET_CACHE_ENTRY_INFO Structure.

Date Last Modified [UTC]

This column contains a timestamp (in UTC) which reflects the date and time the webpage (or object) was last modified (last written). This information is passed back to the browser as part of the HTTP response. Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time.

Date Index Created [UTC]

This column contains a timestamp (in UTC) which reflects the date and time the Weekly INDEX.DAT file from Internet Explorer was created.

Date Last Synch [UTC

This column contains a timestamp (in UTC) which reflects the last date and time at which an object was checked for freshness with the origin server. LastSyncTime is initially set as the time at which an object is added to the cache, and is updated every time the browser verifies freshness of the object with the server.

Date First Visited [UTC]

This column contains a timestamp (in UTC) which is available during the extracting of Netscape and Firefox v1-2 History. It reflects the first date and time at which a web page (or object) was visited.

Date Added [UTC]

This column contains a timestamp (in UTC) which is available during the extracting of Netscape, Firefox and Mozilla bookmark files. It reflects the date and time at which an entry was added to the bookmark file.

References

· KB80013 Internet Explorer INTERNET_CACHE_ENTRY_INFO Structure

· KB80072 Microsoft Internet Explorer Daily INDEX.DAT Entries

· KB80073 Microsoft Internet Explorer Weekly INDEX.DAT Entries

· KB80004 Identification of Suspect Computer Time Zone

· Caching in HTTP

10% Discount for SANS European Digital Forensics & Incident Response Summit

July 9th, 2010 Posted in Not Categorised

Jul, 09 2010

No Comments »

SANS 2010 European Digital Forensics & Incident Response Summit

Join your peers in London, September 8 – 9, 2010 for the first SANS European Digital Forensics and Incident Response Summit, and hear forensics experts help you get the most out of your Forensics and Incident Response strategies operations.

In the commercial sector, TJ Maxx, Hannaford, and TD Ameritrade are victims of large-scale data breaches and intrusions. From these attacks, personal or account information of more than 100 million individuals has been compromised.

In the government sector, cyber attacks on government agencies and contractors, originating from China, have proved difficult to suppress. In both situations, incident response and mitigation, class action lawsuits, and fines place remediation costs in the billions of dollars.

Why is this event special?

The speakers. There is a lot of talent in the EU which is often not sufficiently exposed because they don’t have the chance to travel all the way to the US. Similarly the vast majority of the Forensics Community cannot afford to travel there. With this Summit we want to create an opportunity for the EU forensic community to meet the local experts and learn from their invaluable knowledge and experience.

You, the Community. We want to create an opportunity to share experiences with your colleagues and with others from Law Enforcement, Military Agencies, Corporations, Financial Companies, Telecommunication Companies, etc. You can exchange ideas on how to approach and solve some of the most excruciating problems today: short budgets, transnational investigations, legislation, malware, fraud, etc.

Localisation. Even when there are similar problems or solutions, tools and techniques are used all around the world, in the SANS European Incident Response and Forensics Summit we want to define EU-specific problems and together find solutions to them.

We don’t want to forget that the EU receives multiple visitors from all over Africa, Middle East and Asia. We also want to welcome them to this Summit, as they all have similar problems to the ones we have.

We want the SANS Forensics Summit to be your favourite event of the year, the forum in which the top experts in the EU and nearby regions, the Vendors and the Community will have the chance to meet and share knowledge, experience and solutions, and we will work hard to make that happen.

We’ve teamed up with SANS to bring Digital Detective Customers and Forum Members the chance to attend these events and receive a 10% Discount.

use the Digital Detective discount code: DFIRSTNDD10

Please join us for this innovative meeting on Forensics & Incident Response. There is simply no other place where you can learn – from those who have done it – what works to protect your organisation’s crown jewels – its data.

Understanding Microsoft Internet Explorer Cache

June 16th, 2010 Posted in Forensic Examinations, NetAnalysis, Web Browser Forensics

Jun, 16 2010

No Comments »

The Internet Explorer disk cache is a storage folder for temporary Internet files that are written to the hard disk when a user views page from the Internet.

Internet Explorer uses a persistent cache and therefore has to download all of the content of a page (such as graphics, sound files or video) before it can be rendered and displayed to the user.

Even when the cache is set to zero percent, Internet Explorer requires a persistent cache for the current session. The persistent cache requires 4 MB or 1 percent of the logical drive size, whichever is greater.

Disk Cache Storage Location

The disk cache location varies across operating systems and can usually be found in the following default locations:

Figure 1

Figure 2

Figure 3

To identify the correct location of the cache for each user, the registry hive for the particular user must be examined. You cannot rely upon the live cache folder being in the default location. Figure 4 shows the registry key containing the cache folder location. Users have been known to move their cache location in an attempt to hide browsing activity.

Figure 4

The “User Shell Folders” subkey stores the paths to Windows Explorer folders for each user of the computer. The entries in this subkey can appear in both the “Shell Folders” subkey and the “User Shell Folders” and in both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. The entries that appear in user “User Shell Folders” take precedence over those in “Shell Folders”. The entries that appear in HKEY_CURRENT_USER take precedence over those in HKEY_LOCAL_MACHINE.

Temporary Internet Files Folder Structure

Within the Temporary Internet Files folder, you will find a Content.IE5 folder. This folder is the main disk cache for Internet Explorer. Outlook Express also writes data to this location as is explained later in this article.

Inside the Content.IE5 folder, you will find a minimum of 4 cache folders. The file names for these cache folders comprise of 8 random characters. When further cache space is required, Internet Explorer will add additional folders in multiples of 4. Figure 5 shows the layout of a typical Internet Explorer disk cache.

Figure 5

Content.IE5 INDEX.DAT File

The cache INDEX.DAT file is a database of cache entries. It holds information relating to individual cached items so that the browser can check whether the resource needs to be updated (eTag) and information relating to the location of the cached item. It also stores the HTTP (Hypertext Transfer Protocol) response header for the resource.

At the start of the INDEX.DAT file, you will find a zero based array holding the names of the cache folders. Each individual URL record contains an index value which refers to a specific folder in the array. This allows Internet Explorer to correctly identify the location of a cached item. This can be seen in Figure 6 below.

Figure 6

Cache File Naming Convention

As files are saved to the cache, Internet Explorer uses a specific naming convention as shown in Figure 7. The only exception to this rule is when data is written to this location by Outlook Express.

Figure 7

As pages and resources are cached, they can easily end up in different folders. Internet Explorer attempts to keep the volume of data and number of cached items across each cache folder as level as possible.�

As Internet Explorer writes files to the cache folders, it checks to see if a file with the same name already exists. This is frequently the case when web developers do not use imaginative or descriptive names for their files. If the file already exists within the folder, Internet Explorer will increment the counter. If no file exists, the counter portion of the file name is set to 1.�

Files with the same naming structure within a cache folder do not necessarily belong to the same web site. Also, multiple visits to the same web site can easily result in files with similar naming conventions being spread across all the cache folders. Cached resources can also become orphaned when the INDEX.DAT entry is not written to disk (such as when Internet Explorer crashes before the entries are written). Figure 8 shows a typical cache folder. There are two files within this folder which would have had the original name “images.jpg”. Internet Explorer has renamed them “images[1].jpg” and “images[2].jpg”.

Figure 8

Outlook Express Email Client

Microsoft Outlook Express also uses the Content.IE5 folder as a temporary cache. When a user selects an email message within the client, Outlook Express reads the data from the corresponding DBX file and caches the components of the email so that it can be rendered on screen for the user as an email message.�

The structure of the DBX files is such that the email message is broken down into blocks and has to be rebuilt before it can be rendered. If the message contains any attachments, they are stored in Base64 format and stored within the file. The attachments also have to be extracted, decoded and cached prior to rendering on screen.

As the message is rebuilt, Outlook Express saves the different elements of the message to the disk cache as a temporary file. The naming convention is different to Internet Explorer. In the past, some forensic examiners have not been aware of this and have incorrectly attributed data in the cache to a visit to a web page when it in fact was there as the result of viewing an email message.�

The file structure is shown in Figure 9. The asterisk values represent hexadecimal digits. Figure 9 also contains some example file names.

Figure 9

Useful Links

Browser Forensics, Cache, DBX, IE, INDEX.DAT, Internet Explorer, Outlook Express, TIF

Microsoft Internet Explorer Daily/Weekly INDEX.DAT Files

June 15th, 2010 Posted in Forensic Examinations, NetAnalysis, Web Browser Forensics

Jun, 15 2010

No Comments »

Microsoft Internet Explorer maintains a number of INDEX.DAT files to record visits to web sites as well as to maintain cache and cookie data. In this article, we will look at the Daily and Weekly files.

Daily INDEX.DAT Entries

The Daily INDEX.DAT file maintains a Daily record of visited pages. This INDEX.DAT file has an unusual HOST record entry which helps the investigator analyse the pattern of visits to a particular web site.

The HOST record entry is used by Internet Explorer to display the hierarchical history structure when showing the user which web sites have been visited. Each record contains a number of timestamps with the important data being stored in a FILETIME structure. This timestamp structure contains a 64-bit value representing the number of 100-nanosecond intervals since 1st January 1601 (UTC). The Digital Detective DCode utility can be used to convert these and other timestamp formats.

On the first daily visit to a particular web site, Internet Explorer creates a HOST entry in the INDEX.DAT record. In effect, this entry represents the first visit to a particular HOST on specific day. With further visits to the same web site, the HOST entry remains unchanged. Examining the entries for the Daily INDEX.DAT will show when a web site was first and last visited during the period. Figure 1 below shows an example of this when using the HOST filter view in NetAnalysis to look for visits to the Digital Detective web site.

Figure 1

Daily INDEX.DAT Timestamps

The Last Visited timestamp information is stored as two 64-bit FILETIMES located at offset 0×08 and 0×10 (Decimal 8,16). They are stored as UTC and Local time values. As there is no requirement to alter these timestamps, they are presented in an unaltered state in NetAnalysis as the “Last Visited [UTC]” and “Last Visited [Local]” columns. Figure 2 and 3 summarise these timestamp values.

Figure 2

Figure 3

Establishing the Time Zone ActiveBias

As the URL records contain UTC and Local timestamps, it is possible to establish the Time Zone ActiveBias by establishing the time difference between both timestamps. We discussed in a previous article on manually establish the system Time Zone settings. The calculated ActiveBias information is represented in NetAnalysis by the ActiveBias column as shown in Figure 4.

Figure 4

NetAnalysis further uses this information to confirm the selected Time Zone is correct. If the Time Zone ActiveBias is in conflict with the Time Zone setting in NetAnalysis, the resulting timestamps may not be represented accurately. The calculated ActiveBias is logged to the Audit Log as shown in Figure 5.

Figure 5

If NetAnalysis detects that the Time Zone settings for the current forensic investigation are not correct, a warning dialogue will be shown immediately after the data has been imported. Figure 4 shows the warning dialogue.

Figure 4

Examination of the ActiveBias column will show which entries are in conflict with the Time Zone Settings.

Weekly INDEX.DAT Entries

At the commencement of a new browsing week, the content from the Daily INDEX.DAT files is archived into a single Weekly INDEX.DAT file. The actual timestamp information within the binary file changes for this file type when compared to the other files.

When the Weekly INDEX.DAT file is generated, the file created timestamp is saved at offset 0×10 of every URL record. This is different to the other INDEX.DAT records as this location usually represents the Last Visited UTC Timestamp. Many applications (including some software which claim to be for forensic purposes) get this wrong and misrepresent this timestamp as the “Last Visited Date”.

This timestamp is in FILETIME format and is saved as a UTC value. This timestamp is presented within NetAnalysis in the “Date Index Created [UTC]” column.

The last visited timestamp is saved at offset 0×08 within the record as a LOCAL timestamp. This is unusual, as FILETIME timestamps are normally saved as UTC values and the other INDEX.DAT files all contain a Last Visited timestamp with a UTC value. With this timestamp, NetAnalysis takes the unaltered LOCAL time and saves it to the “Last Visited [Local]” column. Unfortunately, the Last Visited UTC FILETIME value which was present in the Daily INDEX.DAT is not saved within the record and therefore has to be converted from a Local timestamp.

To calculate the UTC timestamp for the “Last Visited [UTC]” column, NetAnalysis takes the LOCAL timestamp at record offset 0×08 and converts it to UTC. This conversion is calculated using the Time Zone value set in NetAnalysis prior to importing any data. In doing so, dynamic daylight settings are also taken into account (as well as any year on year differences).

If a Weekly record is imported with the “No Time Zone Date/Time Adjustment” setting activated, NetAnalysis will show the LOCAL Last Visited timestamp but will not attempt to calculate the UTC timestamp. In this case, the “Last Visited [UTC]” column will remain empty. The “Last Visited [Local]” timestamp for Weekly entries is not changed or affected by NetAnalysis Time Zone settings. It is left in an unaltered state.

Weekly INDEX.DAT Timestamps

The timestamp representation in NetAnalysis is shown in Figure 5 and 6 below.

Figure 5

Figure 6

Useful Links

Browser Forensics, IE, INDEX.DAT, Internet Explorer, NetAnalysis

How to Bookmark Records with NetAnalysis

June 12th, 2010 Posted in Forensic Examinations, NetAnalysis

Jun, 12 2010

No Comments »

Once you have loaded your browser history and cache data into NetAnalysis, you will begin the reviewing process looking for items of evidence which either support or undermine your current investigation. During your review, you will identify URL records of interest which you may wish to produce in an evidential form.

This article looks at the bookmarking process and explains how to print a summary report. To demonstrate this, we shall use an example investigation involving the purchase of illegal firearms over the Internet.

Bookmarking

The first method we will look at is bookmarking. NetAnalysis has a facility to allow individual records to be bookmarked. Bookmarking allows the forensic investigator to add a text description to a specific record which can be later printed in a report.

In this first example, we will look at the Google searches conducted by our suspect. To filter the searches, press F8 to open the filter form and enter “Google” as a filter keyword. Figure 1 shows the resulting search.

Figure 1

We can see that the first record returned contains a Google search for the phrase “sig sauer auto”. As this URL shows our suspect searching for firearms, we will bookmark this search. There are three possible ways to bookmark a search:

• Press the “enter” or “return” key
• Select “Add / Edit Bookmark” from the Bookmark menu; or
• Right click on the record and select “Add / Edit Bookmark”

This will then open the bookmarking window which can be seen in Figure 2. As you can see, the form is split into two text areas. The top text box contains a decoded version of the URL record. The examiner will see a representation of the URL record with any encoded characters removed. Any Name|Value pair data is also split to make the record easier to understand.

Figure 2

The text box in the lower half of the form is where you can add the bookmark information for this record (as shown in Figure 3).

Figure 3

Click OK to save this bookmark. Now that this record has a bookmark entry associated with it, the bookmark icon will appear at the start of the URL record, as shown in Figure 4.

Figure 4

Advanced Evidence Report

The Advanced Evidence Report is a summary report which will show the current filtered list. To filter only records containing bookmarks, select CTRL + F9 or select “Filter Records with Bookmarks” from the Filter menu.

The report can be run by selecting Reports >> Advanced Evidence Report >> Preview Report or pressing CTRL + R. The report will provide a summary of the important fields within the record and show the bookmark text (as highlighted in Figure 5).

Figure 5

References

KB80070 How to Bookmark URL Records
NetAnalysis Information Page
KB80037 What’s New in NetAnalysis v1.50

Browser Forensics, NetAnalysis

Manual Identification of Suspect Computer Time Zone

June 4th, 2010 Posted in Forensic Data Recovery, Windows Analysis

Jun, 04 2010

No Comments »

In a digital forensic examination, establishing which Time Zone the system had been set to should one of the first examination tasks. If this information is not established at an early stage and taken into account, the validity of Date/Time evidence may be brought into question. Not only is this true for the examination of Browser History and related artefacts, it is also important when examining file system metadata.

I also believe this is something every examiner should be able to do manually, as opposed to relying on point and click or script forensics. Whilst point and click certainly has a place and software tools can greatly increase the efficiency of the examination process, digital forensic practitioners need to possess the skills and ability to verify the results.

Some Date/Time values stored in binary files are affected by the Time Zone setting of the original suspect computer and many digital forensic applications can alter the representation of these dates by the Time Zone setting of the forensic workstation.

This becomes particularly complicated when the suspect computer was set to an incorrect Time Zone and the computer clock was set to correspond to the Local Time Zone. Many of the Date/Time stamps store the data as UTC values. In such circumstances, the Operating System (or application) has to convert the value from Local time to UTC.

Case Example

This was demonstrated in a case I was asked to review a number of years ago. A computer had been seized as part of an investigation into abusive images of children. The police had examined the computer correctly and the individual involved had been charged with offences under the Protection of Children Act 1978.

A defence expert examined the forensic image from the computer had declared in his report that the police had tampered with the evidence and alleged that they were responsible for the illegal material as the Date/Time stamps show the material was created on the disk some four hours after it had been seized by police.

My initial examination revealed that the defence expert had not established the Time Zone settings for the system nor had he taken them into account during his examination and subsequent report. If he had, he would have seen that the system was incorrectly set to Pacific Time and not GMT. As far as the Operating System was concerned, the system was in Pacific Time and added 8 hours to the Local times to convert them to UTC. This resulted in the Date/Time stamps being 8 hours in advance of the correct time.

When the defence expert stated the computer had illegal material written to the disk after the system was seized, it was in fact that this had happened some 4 hours prior to the warrant being executed at the home of the suspect.

Establishing the Current Time Zone

To establish the Time Zone setting for a Microsoft Windows system, the forensic examiner can examine the SYSTEM registry hive. To do this, you need to establish which ControlSet was active when the computer was seized.

Time_Zone_Registry_Key

Figure 1

There you will find 4 keys detailing the Current, Default, Failed and LastKnownGood control sets. The current control set in the screen below is set to 3. You can also see the there are three ControlSets numbered 001 to 003.

Figure 2

Now that this current control set has been identified, we can navigate to that location in the registry and calculate the different values as stored. In this case, the Time Zone settings are stored here:

ControlSet003

Figure 3

The Time Zone Information for this Control Set is shown in Figure 4.

Figure 4

The keys are explained below. Please note that the bias settings are stored in minutes as a signed integer. The bias is the difference, in minutes, between UTC and local time. All translations between UTC and local time are based on the following formula:

TimeZone_Formula

Figure 5

ActiveTimeBias

This value is the current time difference from UTC in minutes, regardless of whether daylight saving is in effect or not. It is this value that helps establish the current Time Zone settings. Using the formula above, take this value and add it to local time to get the UTC value.

Bias

This value is the normal Time difference from UTC in minutes. This value is the number of minutes that would need to be added to a local time to return it to a UTC value. This value will identify the Master Time Zone (Standard Time).

StandardBias

This value is added to the value of the Bias member to form the bias used during standard time. In most time zones the value of this member is zero.

DaylightBias

This value specifies a bias value to be used during local time translations that occur during daylight time. This value is added to the value of the Bias member to form the bias used during daylight time. In most time zones the value of this member is –60.

DaylightName

The Operating System uses this name during daylight saving months to display the current time Zone setting.

DaylightStart

Binary data in SYSTEMTIME structure used to identify the date/time that Daylight Saving will commence in this time zone.

StandardName

The Operating System uses this name during daylight saving months to display the current time zone setting.

StandardStart

Binary data in SYSTEMTIME format used to identify the date/time that Standard Time will commence in this time zone.

DisableAutoDaylightTimeSet

This will only be visible if the setting to automatically adjust clock for daylight saving has been switched OFF.

Calculating Signed Integer Bias Values

Within digital systems, all data, whether they be numbers or characters are represented by strings of binary digits. A problem arises when you want to store negative numbers.

Over the years, hardware designers have developed three different schemes for representing negative numbers: sign and magnitude, ones complement, and twos complement. The most common method for storing negative numbers is twos complement. With this method, the Most Significant Bit (MSB) is used to store the sign.

If the MSB is set, then this represents a NEGATIVE number. This method affords natural arithmetic with no special rules. To represent a negative number in twos complement notation the process is simple:

• Decide upon the number of bits (n)
• Find the binary representation of the +ve value in n-bits
• Flip all the bits (change 1 to 0 and vice versa)
• Add 1

Figure 5 below shows the binary representation of the positive number 5.

Positive_Binary_Number

Figure 5

To represent this as a negative number (using 8 bits) then the procedure above is followed. Flip the bits as shown above and add one as shown in Figure 6.

Negative_Binary_Number

Figure 6

This method makes it extremely easy to add positive and negative numbers together. For example:

Binary_Addition

Figure 7

It also makes it extremely easy to convert between positive and negative numbers:

Converting_Binary_Numbers

Figure 8

ActiveTimeBias

If we look once again at the ActiveTimeBias in Figure 9, you will see a signed hexadecimal value. This can be calculated using twos complement.

Singed_Value

Figure 9

This value is stored in hexadecimal as a 32 bit value, so to work out the value it will need to be converted to binary. Ignore the fact that on this occasion, the registry editor is showing the decimal value (4294967236) next to it; this is purely because the registry editor does not realise the value has been stored as a signed integer.

The twos complement calculation is as follows:

Singed_Integer

Convert this to binary:

Calc2

The MSB is set so we know that the above value will be negative. The next stage is to flip all the bits. This involves changing 1 to 0 and vice versa. This can be achieved quickly using the logical NOT function on a scientific calculator. You must ensure that it is set to deal with the correct number of bits.

Calc3

Add 1 bit to the value above

Calc4

And then convert that value back to decimal, remembering that we are dealing with a negative number:

Calc5

Daylight Saving / Standard Time Start Dates

Looking at Figure 10 below, you can see two keys entitled DaylightStart and StandardStart. They hold encoded data showing the exact commencement date/time of Daylight Saving and Standard Time. To establish when daylight saving starts and ends, both keys will need to be decoded.

Figure 10

SYSTEMTIME Structure

This data is stored in a common structure called SYTEMTIME. This structure specifies a date and time, using individual members for the month, day, year, weekday, hour, minute, second, and millisecond.

Figure 11

The data in DalylightStart is as follows:

Daylight_Start

Figure 12

Bytes 0 & 1 (0×0000 ) refer to the year from a 1900 time base. This is only required if the change is year specific and will normally be zero.

Bytes 2 & 3 (0×0003 ) refer to the month, in this case March.

Bytes 4 & 5 (0×0005) refer to the week (starts at 1 and 5 means last). In this case the last week.

Bytes 6 & 7 (0×0001) refer to the Hour. In this case it is 0100 Hours.

Bytes 8 & 9 (0×0000) refer to the Minutes. In this case it is Zero minutes.

Bytes 10 & 11 (0×0000) refer to the Seconds; in this case it is Zero seconds.

Bytes 12 & 13 (0×0000) refer to the Milliseconds, in this case it is Zero milliseconds.

Bytes 14 & 15 (0×0000) refer to the actual Day of the Week (Sunday = 0). In this case it is Sunday

For our example in Figure 12, Daylight Saving Time (DST) will start on Sunday of the Last Week in March at 0100 Hours. If we had decoded StandardStart, we would see that DST would end on Sunday of the last week of October at 0200 hours.

Links and References

Registry, Time Zone, Timestamps, Windows

Understanding and Creating Blade Data Recovery Profiles

June 3rd, 2010 Posted in Blade, Forensic Data Recovery

Jun, 03 2010

No Comments »

To recover data with Blade, you can either use the built-in recovery profiles stored in the global profiles database or create your own bespoke recovery profile. You do not have to possess programming knowledge to do this as with other tools. Blade was designed so that complicated data recovery profiles could be designed quickly for effective data recovery.

Blade has access to two separate recovery profile databases. The global database cannot be altered by the user and contains profiles created and distributed as part of the software. From time to time, we will update and add to these profiles as a result of research and development. It also allows us to create additional validation routines for specific profiles in the database.

For example, the JPEG image recovery profile in the global database invokes a comprehensive validation routine to assist with accurate recovery.

The personal recovery profile database can hold profiles created by the user, recovery profiles copied from the global database and imported recovery profiles from colleagues and other practitioners.

Elements of a Recovery Profile

As you can see from the screen below, there are a number of elements which make up a recovery profile. Blade has the ability to use more than just header/footer recovery and employs a powerful regular expression engine.

Figure 1

Wikipedia defines them as: “Regular expressions, also referred to as REGEX or REGEXP, provide a concise and flexible means for matching strings of text, such as particular characters, words, or patterns of characters.”

Regular expressions allow you to create powerful recovery profiles which are capable of looking for patterns rather than specific bytes. Some of the patterns can be extremely complicated. Blade comes with its own Regular Expression testing utility so that signatures can be tested prior to use.

Creating a New Recovery Profile

With the personal recovery profile database open, click on the Add New button located on the main toolbar. This will create a new empty profile. We will go through each section individually so we can explain each field and create an example profile to recover Bitmap images.

The first pane contains the summary information for this profile. It also contains information to allow this profile to store version information for profile version management.

Figure 2

The first field is the description field. This is the string data which will be displayed in the list of recovery profiles. This string should be unique. If you do happen to accidently enter a description which has already been entered, Blade will append a counter to the end of the description to ensure it remains unique. In this field, enter the text “Example Bitmap”.

The File Extension field holds the extension used by Blade when it writes out any identified data. In this field enter the text “BMP”. There is no need to enter the dot character.

The category field is used to group similar types of recovery profiles. Blade automatically generates a number of common file types and also allows you to create your own group names. In this field, select “Graphic File Types”.

The author field contains a string which identifies the original author. When you add a new profile, this field automatically defaults to the name of the licensed user or agency which is stored in the USB licence dongle. This field can be altered at this point if you wish.

The date field is read only and will be automatically updated to reflect the last modified date/time for this recovery profile. The date is in ISO format.

The version stamp is also automatically generated. The version numbering format is:

MajorVersion.MinorVersion.BuildNumber

The build number is generated automatically and is read only. The numbers represent the year in 2 digit format and the day of the year. In the case above, the build number refers to the 154^th day of 2010. When the profile is modified, this build number will be automatically updated.

The Minor Build number will also increase by one on subsequent modifications, although the Major/Minor numbers can be modified by the author at any time.

Version numbers are logged in the recovery audit log (along with a breakdown of the profile) so that specific recovery versions can be recreated at any time. In the case above, the recovery profile version is v1.0.10154.

File Header Section

This section stores the information which can usually be found at the start of a file.

Figure 3

The signature field holds the string regular expression which identifies that pattern of bytes at the start of a file (or segment of data). This is sometimes referred to as the “file signature” or “magic number”. For our Bitmap image, enter the following text:

BM….\x00\x00\x00\x00….\x28

Bitmaps have a file signature containing two upper case characters “BM”. The next four bytes hold a UInt32 which relates to a file length marker. This becomes important later as we create this profile. The dot character in the case relates to any possible value. This is why regular expressions are particularly powerful. For further information on creating regular expressions, see the external links at the end of this article.

The sector boundaries only check box allows you to select whether to ignore data which is not aligned to a sector boundary. This will depend entirely upon which type of data you are trying to recovery. As we wish to recover all possible Bitmap images, we are going to leave this option un-ticked. By selecting this option, we may not recover images embedded within other file types.

The ignore case option will change the way the regular expression engine interprets our signature. In our Bitmap example, selecting this option will force the engine to look for data which starts with any combination of the upper and lower case characters “BM”. For example, it would identify “Bm”, “bM”, “BM” and “bm”. Leaving it un-ticked means the engine will only identify the upper case characters “BM” at the start of the signature.

File Landmark Section

The file landmark section allows you to improve the recovery capability even further. If you think of the file header and footers as bookends, the file landmark section refers to any data which can be found within the two boundaries. The landmark can be found at a specific offset, or at any position within the file. The landmark also uses regular expression patterns, and you can also select Unicode data.

By ticking the Use File Landmark option, you will unlock the fields in this section. The location drop down box allows you to select whether the landmark is floating or at a specific byte offset. If it is at a specific byte offset, this field accepts an integer value which is relative to the file header. For example, if you were aware of 2 static bytes (FF 0A) contained within your file at decimal offset 90, you would create the landmark as follows:

Figure 4

As another example, you may find the following Unicode string contained within a Microsoft Word document:

Figure 5

To create a landmark for this data, you would create a landmark as follows:

Figure 6

In our Bitmap example, we will leave this section blank disabled.

File Footer Section

The file footer section contains information to allow the end of the file to be found. Not all file types contain footer data. For example, JPEG images contain 2 bytes to represent the footer FF D9.

Figure 7

By selecting the Use File Footer check box, the file footer fields will be activated. As with the other signature sections, you have the ability to use a regular expression pattern for this field.

The Bytes to EOF field contains a signed integer value which relates to the location of end of the file in relation to the start of the footer. In our JPEG example above, as the footer contains two bytes FF D9, the Bytes to EOF file would be set to 2. This indicates that the location of the start of this footer is 2 bytes prior to the end of the file.

The following footer example is for HTML data and contains a regular expression designed to stop if it encounters binary (non-textual) data or the normal end of an HTML document. This allows more accurate HTML recovery and can be used when attempting to recover text based files.

Figure 8

For our Bitmap example, leave the footer section un-ticked as there is no recognisable footer with this file format.

Data Length and Boundary Sections

This section controls the length and boundary of our recovered data. In our Bitmap example, we identified that at decimal offset 2 there was a UInt32 value which related to the length of the original file. If we select Use Length Marker, Blade will read a length marker at the offset provided.

Figure 9

If the length marker had been of a different type, this can be selected in the Length Marker Size drop down box. You also have the option to select little or big endian values. For an explanation of little and big endian values, please see the link at the bottom of this article.

The Length Marker Relative Offset field indicates the relative location from the start of the file to the field containing the length marker.

If the data is corrupt and/or the length marker contains an unreasonable value, Blade will not recover data beyond the maximum length value set in the Data Boundary pane. In this case, the recovery log will indicate that data has been truncated and will only be recovered up to the maximum length value. If the data length marker is smaller than the Minimum Length value, Blade will log the fact that the data is shorter than the set value and the data will not be recovered.

If there is no Data Length marker, Blade will recover data based on the Data Boundary settings. The Minimum Length value prevents data which is smaller than this value from being recovered.

With the Maximum Length, Blade will recover data up to this value. If Use Next File Signature as EOF is selected, it will check where the next file is located on the disk (or image) and use this as the end of the file. In our Bitmap case, we have selected this value and set the maximum length to 25 MB.

When Use Next File Signature as EOF (End of File) is selected, Blade will only look for the EOF marker in the data from the start of the file to the start of the next file.

Helpful Links

Original Digital Detective Knowledge Base Article

Blade Forensic Data Recovery Web Site

Understanding Regular Expressions

Understanding Endiannes

Data Recovery

Exporting and Importing Blade Recovery Profiles

June 3rd, 2010 Posted in Blade, Forensic Data Recovery

Jun, 03 2010

No Comments »

One of the nice features of Blade is the ability to exchange Recovery Profiles with colleagues and other digital forensic practitioners. The processing of Exporting and Importing profiles is relatively simple.

Global Recovery Profile Database

For example, the JPEG image recovery profile in the global database invokes a comprehensive validation routine to assist with accurate recovery.

It is also possible to copy recovery profiles from the global database to your personal database so that it can be modified or exported. To copy a global recovery profile, right click on the profile of interest in the list pane on the left hand side of the global profile database window, or click the Copy Profile button on the main toolbar (as shown below).

Exporting a Recovery Profile

To export a personal recovery profile, first open the personal recovery profile database. This can be done by selecting the keyboard shortcut CTRL + S, or selecting Personal Profile Database from the Tools menu.

Select the recovery profile from the left hand list pane and right click. Selecting Export Profile to File will prompt you for a file name and export location. The will create a Blade Recovery Profile File (BRPX) which can then be shared and imported into another copy of Blade.

Importing a Recovery Profile

Once you have obtained a new Recovery Profile, the import process is conducted from within the personal profile database. Simply select Import Profile from the main toolbar. This will prompt you to select the Blade Recovery Profile File (BRPX).

Once the profile has been imported, you can close the personal profile database screen, and access the new profile from the main profile list.

Links

Original Blade Knowledge Base Article

Blade Forensic Data Recovery

Blade Professional recovery Modules

Data Recovery

Recovery of AOL PFC (Personal Filing Cabinet) Email Messages

May 28th, 2010 Posted in Blade, Forensic Data Recovery

May, 28 2010

No Comments »

The use of electronic mail (email) as a mode of communications for both formal and informal purposes has increased considerably over the past decade. As such, the opportunities for the criminal element of society to make use of this facility have also widened making it commonplace within a digital forensics examination to review email content.

Not so long ago, one email client which increased in popularity (particularly amongst paedophiles) in the United Kingdom was that provided with America Online (AOL).

Email extraction and analysis causes significant problems for digital forensic examiners. Almost all of the forensic software designed for extracting email is tailored for dealing with mail-store files which are intact. This means that they have not been designed to extract email data from the other areas of a suspect hard drive such as, unallocated clusters, cluster slack, page files, hibernation files and other binary source files. They have also not been designed to extract data fragments when the mail-store index has been overwritten.

From an evidential point of view, it is likely that a large quantity of email evidence is not being extracted. In addition, as there is limited documentation available regarding the proprietary binary file structures, there is wide variance in the output from many of the commercial forensic tools currently available.

AOL Email Client

In complete contrast to the wealth of software resources available for Microsoft Outlook Express, there are limited resources available for the file format of the AOL Personal Filing Cabinet (mail-store file) and email client.

There are numerous commercial companies offering a service to convert AOL Personal Filing Cabinet files into other mail-store formats, however, this is not a forensic service. A recent search revealed one company offering to convert a single PFC mail-store file for $200 US.

The AOL Email client stores data from individual email messages in a binary file generally known as the PFC (Personal Filing Cabinet). This file has no extension. In a typical Microsoft Windows XP system, the folder structure and mail-store files are stored within the user profile as shown below. The organize folder holds the mail-store data and has a structure which is in a similar format through various versions of the client. In this example, you can see a single screen name (this is an AOL term for a user) in use.

Figure 1

The data for this version is stored within an organize folder within the “All Users” Windows profile. The organize folder can support and store multiple screen names. The individual files for a screen name are shown below:

Figure 2

With regards to email messages, the main file of interest is the Personal Filing Cabinet (PFC). This is a binary file which contains a number of different AOL objects such as Favourite Places, Away Messages, Stored Email Messages, Newsgroup Postings and Download Manager information.

With AOL version 7.00 and above, the body of the email is compressed using ZLib. This causes a problem for the forensic examiner as traditional keyword searching will not be successful without decompressing the data first.

Recovery of AOL (Personal Filing Cabinet) Email Messages

Digital Detective’s forensic data recovery software Blade contains a Professional Recovery module which has been designed to recover AOL email messages from a number of sources.

The Professional Recovery Module has the ability of recovering live and deleted email messages (including attachments) whether directly from a Forensic image (such as an Encase® e01 compressed image) or a physical disk / volume. The output from the software allows the forensic investigator to identify the exact location the data was recovered from.

The carving engine for this Module is the result of numerous years research and development. It was originally released in the Digital Detective product EMLXtract. When this software was released to law enforcement in 2004, it was the first software product to recover AOL email messages from an image or physical/logical device (as opposed to a single PFC File). When compared against other tools, this software recovered more email messages than any other. It works particularly well against corrupted data when many other tools fail to recover anything at all.

The research and development that went into recovering AOL email messages from a forensic image took a considerable amount of time. AOL email messages contain many different elements such as compressed and non-contiguous data blocks. Embedded attachments can be split and have to be stitched back together. When this module was originally designed, the goal was not to recover live and deleted email messages from a Personal Filing Cabinet, but to be able to recover emails from a disk image. This functionality was originally released to Police Forces all around the world as a tool called EMLXtract.

Through research and development, the recovery engine has been enhanced further and is now part of Blade. The following video shows the extraction and examination of AOL email messages from a segmented disk image.

Blade Video showing AOL Email recovery

Figure 3 shows a recovered email message from Blade Professional.

Figure 3

As Blade process the source image, it recovers individual messages and converts them into an HTML representation of the original message. This includes decompressing the Zlib content and rebuilding the original attachments. The physical location of the original email is identified by Physical Sector and Sector Offset. The easiest way to use Blade in a forensic examination is to simply point it at a forensic image of the original device.

Further Reading

Further information regarding Blade Professional and the currently available professional modules can be found from the following links.

Blade Forensic Web Site

Blade Professional Recovery Modules

Blade Example Data Recovery Video Library

Tags: AOL, PFC, Email

AOL, Data Recovery, Email, Personal Filing Cabinet, PFC

Microsoft Internet Explorer PrivacIE Entries

April 29th, 2010 Posted in NetAnalysis, Web Browser Forensics

Apr, 29 2010

Comments Off

Internet Explorer introduced a number of new security and privacy features in version 8. One of these new features was InPrivate Filtering. InPrivate Filtering helps prevent the web sites a user visits from automatically sending details about the visit to other content providers.

When a user visits a web site, it automatically shares standard computer information with that web site. If the web site contains content provided by a third-party web site (for example a map, advertisement, or web measurement tools such as a web bug or scripts) some information about the user may be automatically sent to the content provider.

This type of arrangement can have several benefits. It lets the user conveniently access third-party content. The presence of advertising on a web site may let the web site provide access to premium content at no charge. However, there can be an impact on user privacy as a result because it is possible for the content providers to track the user across multiple web sites.

When InPrivate Filtering is used, some web sites might be prevented from automatically sharing details about the visit with the providers whose content is displayed. As a result, some content might be automatically blocked (such as weather information or advertisements). The user can manually allow blocked content by adjusting the InPrivate Filtering settings.

PrivacIE INDEX.DAT Entries

When performing a forensic examination of INDEX entries from Internet Explorer, you may come across numerous PrivacIE Type entries. These entries are URL records for third-party content providers.

If the user has InPrivate filtering on, the PrivacIE INDEX.DAT stores the URLs to third party content. They are not InPrivate browsing records. InPrivate Filtering helps prevent website content providers from collecting information about sites the user has visited.

For example, the Digital Detective web sites use Google Analytics to track information about visitors to our sites. Google tracks the data and provides webmasters with analytical tools to review the results.

If you switch InPrivate filtering on and visit the Digital Detective Website, you will find two entries in the PrivacIE INDEX which get generated from the visit.

The first entry is a web bug which takes the Google Analytic information as a command line paramter. The second entry is a Google Analytic script.

Removing InPrivate Filter Entries

The user can remove the (PrivacIE) entries relating to InPrivate Filtering in the same way as clearing the History or Cache. In the Delete Browsing History dialogue, there is an entry for InPrivate Filtering as shown below.

Internet Explorer can also be configured not to record this information, even if the functionality is active.

Recovering Evidence of InPrivate Browsing

I will post an article at a later date regarding InPrivate browsing and the recovery of InPrivate history.

The original KB Article is here: KB80054 What are Internet Explorer PrivacIE Entries

Browser, IE, InPrivate, PrivacIE, Security

Digital Forensic Data Recovery & Analysis

NetAnalysis Date and Time Fields

10% Discount for SANS European Digital Forensics & Incident Response Summit

Understanding Microsoft Internet Explorer Cache

Microsoft Internet Explorer Daily/Weekly INDEX.DAT Files

How to Bookmark Records with NetAnalysis

Manual Identification of Suspect Computer Time Zone

Understanding and Creating Blade Data Recovery Profiles

Exporting and Importing Blade Recovery Profiles

Recovery of AOL PFC (Personal Filing Cabinet) Email Messages

Microsoft Internet Explorer PrivacIE Entries

Recent Posts

Archives

Categories

Links

Forensics from the sausage factory

Windows IR

Digital Detective News

SANS Forensics