Even after you have restored the partition, if you go back and check, you will find that the partition table still contains all zeros. EnCase restores the partition virtually with pointers contained within the case file. Figure shows the correct directory structure after the partition was restored.
Figure After the partition is recovered, the directory structure is restored to normal. If you need to remove a partition, from the Disk view, go to the sector where you created the partition, and from the Partitions menu, choose Delete Partition. Alternatively, you could choose Remove User Defined Partitions, and any user-defined partition will be deleted.
If you have more than one partition to restore or you have the potential for other than the run-of-the-mill Windows partition types to exist, it then becomes advantageous to search for partitions. You could create a series of search strings and search for them manually; however, EnCase has a well-designed EnScript to do that work for you.
It is an option or module within the Case Processor EnScript. Figure In the first stage, you are prompted for a Bookmark Folder Name. Click Finish to run the EnScript, and when done, go to the Bookmarks tab and view the results under the folder, in this case Partition Finder. The bookmark will contain a comment for each hit that describes the partition parameters in the format Partition Type : Size in Sectors : Name if available , along with Bookmark Start and Bookmark Sector.
Figure shows the results of running the Partition Finder. You will note that five hits were reported, and the Comment column shows the information about the partition. Note that the columns have been arranged in an optimal manner for this task. Figure The Bookmark view shows the results of the Partition Finder. Note the columns and their arrangement. By arranging the columns as shown in Figure , you can see at a glance which bookmarks are most likely partitions and which are most likely not.
Now it is time to logically examine the results. While in another view, I examined the device before I started this process and determined it contained 4,, total sectors. The first bookmarked item starts at sector Because the device has 63 sectors per track, sectors 0—62 63 sectors appear on the first track.
Sector 63 marks the beginning of the second track and the normal location for the first partition. It makes sense, therefore, that this search hit is describing a valid partition. If you look at its size, which is 2,, sectors, you find that it covers about half the drive.
If you examine the other search hit, located at sector ,, you see that it is contained within the recovered partition. You might therefore conclude that it is a false hit, such as a backup VBR, or data within a file. With that conclusion, you could dismiss it and move on—or you could consider one more possibility. Suppose there were, at one time, two partitions on this drive and the user removed them and partitioned the device in a different partition sizing layout.
The first partition starting at sector 63 would have been overwritten immediately, but the partition starting somewhere out there in the middle of the drive might still exist and be recoverable. In our example, we want to proceed by restoring the first partition found, which is located at physical sector On the first search hit showing on the Bookmarks tab, right-click it and choose Go To File, as shown in Figure This will launch a separate tab within Bookmarks tab showing the containing file in this case Unused Disk Area with the cursor on the offset containing the search hit in the Text view, as shown in Figure With sector 63 selected, as shown in Figure , go to the Partitions menu, as shown in Figure , and choose Add Partition.
Accept the defaults, shown in the Add Partition menu, which are shown in Figure , and choose OK, which inserts the defined partition. As before, you need to reload the evidence entries on the Evidence tab to see the restored partition.
Figure Disk view that lands on sector containing selected search hit, which is also the volume boot record where the partition is to be inserted. As previously mentioned, this partition occupies about half of the device, which means either that the rest of the device is unpartitioned or that another partition exists and needs to also be restored. Thus, it seems clear that we have another partition to insert at sector 2,, the fourth search hit.
With our focus on that partition, simply choose Add Partition from the Partition menu, accept the defaults, and choose OK. Remember to reload the evidence item in the Evidence tab. Now both partitions should be available in the Tree pane, as shown in Figure As with most knowledge, it is enhanced by practical skills that make use of that knowledge.
In Exercise You should do this exercise now while the concepts are fresh in your mind. Create a new case, naming your case Partition Recovery. Place it in an evidence folder along with those created by EnCase 7 for your newly created case. Once you have located it, select it, and click Open. You will now be in the Evidence view with the one evidence item showing. Double-click this evidence item to have it parse and appear in the Entries view. When you do, you will immediately note that no partitions are present and that all data appears as Unused Disk Area.
If you closely examine the first physical sector, you will see that it contains data but that the partition table area byte offsets contains all zeros, indicating that the partition table has been zeroed out and any defined partitions deleted. Knowing that often the first partition can be found at sector 63, examine the contents of that sector, and you will note that it appears to contain the VBR for an NTFS partition. From within the Disk view, with your cursor on sector 63, choose the Partitions menu and choose Add Partition.
Accept the defaults and click OK. Return to the Evidence tab and the Entries view. You will note that view at this point remains unchanged by the addition of the partition. This is expected as we must return to the Evidence tab Table view and force our evidence item to be reparsed.
To do so, click the green left arrow to the left of the words Viewing Entry. Next, simply double-click the evidence item; you will be returned to the Entries view, and your added partition will be fully viewable.
One might consider the work done at this point, but one should always account for all drive geometry because there could be yet another deleted partition. In fact, if you force the device to appear in the Table view and look at the Report view for that device in the View pane, you will note that the device contains 4,, sectors and that the recovered partition accounts for only 2,, sectors or about half of the total drive space.
There are essentially two approaches to handling this situation. You could use the Partition Finder contained within the EnCase Evidence Processor to locate partition signatures and work through the results, adding the partition when found. Alternatively, and often much more quickly, you could go to the end of the recovered partition and examine the sectors in the area for the presence of another partition.
From the Disk view, right-click any sector and choose Go To. In the Go To window, type in 2,, and click OK, which should take you to the last sector in the recovered partition. If you step over to the next sector 2,, , you will see the backup VBR for the recovered partition. If this is a valid FAT32 partition, you would expect to see a backup VBR located six sectors from here at sector 2,, When we examine this, we confirm the presence of the backup VBR and realize that we need to add a partition at the primary VBR located at sector 2,, Place your cursor on that sector and, from the Partition menu, choose Add Partition.
As before, return to the Evidence tab Table view and double-click the evidence item to force it to reparse. The result will be displayed on the Evidence tab Entries view, and both user-added partitions will now be visible. Be sure to save your work at this point! Many files are compound in nature. A compound file contains data that may be hierarchical, compressed, encrypted, or a combination of these methods. Its raw data is often illogical, difficult, or even impossible to view in its native state.
EnCase can decode and mount these files so they are displayed in a logical or hierarchical format. In this manner, the examiner can see the data in the file in a more meaningful and logical format.
Also, it is important to understand that certain files are mounted as part of other processing. The process is the same for mounting any compound file. You simply right-click the file, under the Entries option select the View File Structure option, and then click OK in the resulting dialog box.
Figure shows the right-click menu with the option View File Structure selected. Figure To mount a compound file, right-click it and choose View File Structure under the Entries option. EnCase mounts the compound file, and the mounted file will be visible in blue to indicate that it is a hyperlinked object.
If you hold your cursor over the hyperlink, the cursor will change to a hand, which is depicted in Figure In past versions of EnCase, a mounted file was stored in RAM and consumed significant resources, especially when many large compound files were mounted.
EnCase 7, by contrast, mounts compound files by creating logical evidence files for each mounted file and stores them in the EvidenceCache folder. This is a far more efficient method of mounting compound files and negates the need to dismount them. Currently, as of EnCase 7. Figure A mounted compound file is shown in blue indicating its hyperlinked status. The cursor changes to a hand when placed over a mounted compound file. To view a mounted compound file, simply click the blue hyperlink, and the mounted file will launch in its own window within the Evidence tab, as shown in Figure From this view, you can navigate its structure from within the Tree pane beginning at the special icon denoting the root of the mounted compound file, which is also shown in Figure Any object within the mounted structure can be bookmarked and subsequently included in your final report.
Figure Mounted files are viewable in their own separate window on the Evidence tab. Often there are temp files that are compound files. These files are good candidates to mount and examine. The list of files that can be mounted seems to grow with each release of EnCase. Table describes the most common files that can be mounted within the EnCase environment. There is a brief description of the file and what data can be seen upon mounting.
Table Listing of common compound files that can be mounted in EnCase. Mounting places various objects in a folder structure so that you can view the document properties, including the data, document summary information, and so on. Mounting places various objects in a folder structure so that you can view the various document properties such as the data, document summary information, and so on. Mounting places various objects in a folder structure so you can view the various document properties such as the data, document summary information, and so on.
Mounting places emails in a hierarchical structure instead of viewing in a flat file. Mounted file shows thumbnails of images in folder on the last occasion the user viewed thumbnails. Can show thumbnail images of files that were deleted.
It also shows that user saw images and was aware of contents, which is useful in cases where inappropriate or unlawful images are at issue. Mounting these files parses the specific registry hive and allows the examiner to navigate that branch of the registry in a hierarchical view. Some compound files can be searched without mounting them; others require mounting before they can be searched. For the most part, the determining factor is whether the data is compressed, encrypted, or both. If you mount them, however, the compressed text is uncompressed during mounting, and they can then be searched.
Thus, it is compressed and encrypted. If you mount this file, the data is uncompressed, decrypted, and displayed in a hierarchical structure. In this format, it can be easily searched. Once you have them mounted, you can effectively search them. Microsoft Office documents can be searched without mounting.
The EnCase Evidence Processor contains an option to mount certain compound files, as shown in Figure Thus, when using the File Mounter, you will want to search for compound files by both extension and signature if you are working on a non-Windows system. In fact, you may want to use it almost always because compound files created on other than Windows machines often find their way onto Windows systems from downloads, email attachments, and the like. Also, some browsers store Internet cache files in renamed files with no file extensions.
Thus, if you want to be thorough and find and mount all compound files, search by both file extension and file signature on both Windows and non-Windows systems. Outlook leaves fragments of its data throughout the hard drive in slack space, in unallocated space, in the swap file, and in the hibernation file. The first step is to create a keyword to search. When you create the keyword, you need to select a Unicode search and uncheck the current active code page.
Next, go to the Code page tab. Go down the list of available code pages until you reach the Outlook Compressible Encryption code page, which is code Place a check mark next to this code page, and then click OK to create your keyword. Go to the Results view and review your search hits in the View pane, using the Text tab.
Any search hits that appear immediately in clear text are not ones that are in Outlook Compressible Encryption. Now your results will appear in gibberish, except for those in clear text, which are decoded from Outlook Compressible Encryption.
Bookmark any hits of import and then view the results in the Bookmark view. The Windows registry is a central repository or database of the configuration data for the operating system and most of its programs. Although the registry creates a convenient central location for this data, it also creates the potential for a single point of failure that can bring the system to a halt.
To understand the registry as seen in EnCase, you need to understand the live registry as seen in Windows. As you go through this chapter, you will explore and in some cases make changes to your system registry.
No discussion of registry changes would be complete without the customary warning: changing your system registry could harm your operating system. If you want to make changes, back up your registry first, or create a restore point before proceeding.
To be certain, the registry is a gold mine of forensic evidence. Since Microsoft discourages users, administrators included, from accessing or modifying the registry, it is doing its part in helping us preserve evidence, for which we are most grateful. As an examiner, you need to be very comfortable navigating within and working with the data in the registry. Comfort comes with knowledge, understanding, and experience, which are the precise goals of this section.
When you are done with this chapter, you will join a relatively elite group of examiners who understand and properly interpret the function and values contained in this key. Its forensic usefulness will unfold before your eyes! If you are going to testify about what a particular value in the registry means, you need to be able to demonstrate and explain those values.
After completing this section, you should have the tools and techniques to do so. MS-DOS received its configuration settings from two modest little files: config. The config. This first version of Windows introduced INI files as containers for configuration information. These were flat text files with no hierarchical structure, and related configuration data was stored in sections. Text files made it difficult to store binary data, and the INI files were numerous and lacking in organization.
Windows 3. Windows 95 and NT 3. The Windows registry is stored in files called hives at a physical level. The interface for the user and applications takes on a logical scheme or format that resembles the directory structure used by Windows Explorer to store data in files and folders.
Instead of using folders, the registry uses keys. Instead of using files, the registry uses values. If you think of it using that analogy, you are well along your way to understanding the hierarchy and terminology.
The user primarily views or modifies the registry with the registry editor tool. With Windows , you had to choose between two registry editors regedit. Either would allow you to view and navigate the registry, but each had capabilities and limitations that the other did not have, forcing a choice at times. Microsoft does not provide a shortcut to the registry editor in any known dialog box. In fact, Microsoft keeps the registry well below the radar screen, making only brief mention of the registry in the Windows help feature.
At every stage Microsoft recommends against editing the registry, even to the point of recommending that administrators edit the registry as a last resort.
To open the Run command, hold down the Windows key, and press R for run. In the resulting window, type regedit , and press Enter. Figure shows the Windows 7 registry editor when you open it. The left pane is known as the key pane , and the right pane is known as the value pane. The Windows registry consists of five root-level keys, shown in Figure Table describes these root keys.
Of those five root keys, only two are master keys, while the remaining three are derived keys that are linked to keys within the two master keys.
Used to associate file types with programs that open them and also used to register classes for Component Object Model COM objects. It is the largest of the root keys in terms of the registry space it occupies. This merger effectively blends default settings with per-user settings. Used to configure the environment for the console user. Used to establish the current hardware configuration profile. Used to establish the per-computer settings. This key is a master key and is not, therefore, derived from any link as are the previous three keys.
Used for environment settings for the console user as well as other users who have logged onto the system. There will be at least three subkeys—. Any other SIDs found here will belong to other users who have logged on to the machine.
This key is a master key and is not, therefore, derived from any link. At a physical level, each of the logical master keys has its source data stored in a file that is called a hive. Table shows the hive keys and the associated hive files from which they originate. This hive file is located in the first partition, which is a hidden system partition. This file replaces the legacy boot.
This file previously existed as a text file and was an easy target for malware. Part of the rationale for placing the boot data in the registry hive file was to make it more difficult for malware to utilize for start-up purposes. While it remains to be seen whether that rationale was valid, clearly the registry hive file format allows binary data storage and considerable extensibility for boot configuration data storage. It is created as a dynamic key in RAM when Windows boots.
When the system shuts down, the data in this key is gone. The master key HKU has its share of hive files as well. In fact, each subkey under HKU is a hive key with a corresponding hive file. The hive files for HKU are found in several locations. Table shows the various hive keys in HKU and their source hive files. When the system loads these hives into the registry, there is one key that lists or maps the loaded hive files with their corresponding registry hive keys.
This key is an excellent one to visit because it shows the relationships between hive files and hive keys that are loaded on the system see Figure When the system is shut down, none of the hives is loaded. As I mentioned earlier, the registry keys are displayed in the left, or key, pane of the registry editor.
It is from this pane that you can navigate among the various registry keys. The right, or value, pane is the pane in which you view or access the registry values. A value has three components: its name, its data type, and its data. Figure shows the registry editor in which a series of values is shown in the right, or value, pane.
In the value pane there is a column for each of the three value attributes Name, Type, and Data. Figure Registry editor showing registry values in the right, or value, pane. A value name can be up to ANSI characters in length Unicode characters , except for the special characters: question mark? Furthermore, Windows reserves all value names that begin with a period.
Just as no folder can contain two files with the same name, no key can contain two values with the same name. Each value contains data of a specified data type. That type is specified by a number, which is interpreted by the registry API so that the user sees the data type in plain text.
Table shows each of the data types, their corresponding number, and a brief description of what the data type means. When you see a registry value in EnCase versions older than version 5, only the data type number will be shown, not the plain-text version rendered by the registry API. EnCase 5 and 6 interpret the numeric value and return the plain-text data type, as shown in Table In all versions, the data type appears in the file type column.
With EnCase 7, the file type column does not appear, and there is no information provided regarding the value data type. Multiple-string field in which each string is separated by a null 00h and with two nulls 00 00 marking the end of the list of strings.
You can view but not edit these lists. It is the logical interface by which the registry hive files are addressed, viewed, and edited. The live registry, as thus far depicted, and the registry as seen in EnCase will have noticeable differences. When you view the registry in EnCase, you are looking at only the hive files, and the view will differ from a live registry view in many ways.
This key is a dynamic key, created at boot, and exists only in RAM while the system is loaded and running. There is no hive file for this dynamic key. You have seen that certain keys exist only virtually as links to keys on the master keys. You should not expect to see the virtual keys, but you can certainly view their data by going to the key to which they are linked. As with any other mountable file, to mount a registry hive file, you need only to right-click one of the hive files and choose to view its file structure from the Entries option.
The ones in the repair folder are basic configurations for repair purposes if things go wrong. Here you want the active registry hive files in the config folder.
To mount any of the hive files, simply right-click the desired file and choose to view its file structure from the Entries option. When the file mounts, you can navigate through the various keys as you would any hierarchical file structure. When a value is displayed in the Table view pane, you will see its name in the Name column and its data in the View pane in either the Text or Hex view.
Figure shows the system hive file mounted. The Select key contains four values. Although the others are important, you want to know which control set is current, and the value named Current contains the data that makes that determination. In this case, the data for the value named Current is a Dword data type and the data reads 01 00 00 This value translates to 1, and the current control set is 1. With Vista, registry virtualization was born, by which applications that do not follow the rules principle of least privilege and attempt to write to read-only areas of the registry HKLM, for example have their writes redirected to a special area dedicated for this purpose.
The application is unaware that its data is stored in a new location as the calls are redirected to the virtualized area, and everyone is happy. For the examiner, however, the virtualized registry key is yet another area to examine so as to conduct a complete examination. Figure The system hive file is mounted. Additionally, restore points are created before Windows updates, when software is installed, when an unsigned drive is installed, and when a user decides to restore to another restore point.
They are also turned on by default, so you should usually expect to see them unless they have been disabled by the user or the hard drive is nearing its capacity. Although the date the restore point was created is stored in the last eight bytes of the rp. As part of the restore point data gathering, Windows makes copies of the registry files and places them in the Snapshot folder, renaming them in the process.
The Snapshot folder appears under each of the RP folders. Table shows the names of the more forensically significant registry hive files and their new filenames as stored in the restore points.
Instead of just capturing snapshots of critical operating system and program files and settings, VSS contains snapshots of all data from a volume that has changed and does so from a block perspective, with each block being a 16 KB unit.
Extracting data from the VSS copies is a somewhat onerous process but can be done. The result is a gold mine of forensic data, often containing copies of files long ago deleted and forgotten. The ability to go back and view registry data at various points in time is a tremendous investigative tool with endless forensic possibilities. You can examine for changed settings before and after intrusions, old search histories, old most recently used MRU lists, and so on. Steve Anson and I teamed up to write the book Mastering Windows Network Forensics and Investigation , in which restore points are covered extensively.
The books are available here:. You should, by now, have a good understanding of the registry and how it is logically organized. You should be familiar with the registry editor and navigating the registry keys. You should also grasp the differences between the live registry in Windows and the offline registry as viewed in EnCase.
There will be times when you will want to know where a particular setting is located in the registry. Most certainly it would. In this manner, you can speak more authoritatively and confidently about your findings. To conduct research into the live registry, there is no better tool than the free tools from Microsoft designed specifically for this purpose.
By default, at launch, you are monitoring almost everything, and the result is simply too much data. To begin with, turn off File System, Network, and Process activity by clicking their icon buttons on the toolbar, as shown in Figure This will leave only Registry Monitoring active.
To apply this filter, click Filter on the toolbar and choose Filter again. With those settings in place, click Add to place the filter in the list, as shown in Figure When you click OK, the filter is applied. Figure Filter is set to exclude anything except operations that set registry values. You are almost ready to go to work. Figure shows the Capture button under the cursor. Two buttons to the right you will find the Clear button. Toggle off Data Capture and clear out any existing data.
You are now set to investigate the registry. Figure The button to toggle data capture on and off is under the cursor. The Clear button is circled. If Remote Desktop is enabled, naturally this adds a new dimension to any case because the computer can be accessed remotely. Therefore, this should be a setting that we usually inspect on a routine basis.
We must, however, first know where it is. Leave Process Monitor off for now. You want to capture data only for the brief instant that you apply a setting to minimize data and to zoom in on your finding. To enable or disable Remote Desktop, right-click Computer and click Properties. On the screen that follows, you will see Remote Settings on the left side of the screen. In the bottom half of this menu are three settings pertaining to Remote Desktop. Click the middle button, which enables Remote Desktop from any version, as shown in Figure Do not click OK or Apply just yet!
Figure System Properties dialog box open to Remote tab from which Remote Desktop is enabled or disabled. The next step is to get your Process Monitor window and your System Properties menu side by side and visible at the same time. When ready, you toggle on Data Capture, click Apply to apply the Remote Desktop settings, and immediately thereafter turn off the data capture. Encase forensics 8 is very rich in forensics functionality.
Encase v8 provides functionality to execute powerful analytic methods against evidence in a single automated session. While running this multi-threaded process, the Encase v8 optimizes the order and combinations of processing operations, ensuring the most efficient execution path is taken. The output of the Encase v8 is stored, per device, on disk, instead of memory, so that multiple devices can be processed simultaneously across several computers, and compiled into a case.
This action is mainly useful when a drive has been reformatted or the MFT is corrupted. A commonly used technique for data masking is to rename a file and change the extension. Image files can be renamed so that they look like Windows DLL files. Signature analysis component verifies file type by comparing the file headers, or signature, with the file extension. The signature analysis process flags all files with signature-extension mismatches according to its File Types tables.
Signature analysis is always enabled so that it can support other Encase v8 operations. When you select the Thumbnail creation option, the Encase v8 creates thumbnail records for all image files in the selected evidence. This facilitates image browsing. A hash is basically a digital fingerprint of a file, commonly represented as a string data written in a hexadecimal format. The most common use for hashes are to:.
For archive files, Expand Compound Files extracts compressed or archived files, and processes them according to the selected Encase v8 settings. This includes nested archive files or zip files or.
Select this setting to extract individual messages and attachments from email archives. Find Email supports the following email types:. This can Identify the internet related artifacts, such as browser histories, cookie and cached Web pages. You can examine the unallocated space for artifacts. Encase v8 creates an index which allows you to quickly search for the string.
The advantage of having these items indexed is that you will later be able to search across all types of information and the view results in email, files, smartphones, and any other processed data in a one search results view. With the Encase v8, you can quickly and easily search for all kinds of information and data, any kind of wireless or mobile device. When creating an index of case data, select Personal Information to additionally identify and include the following personal information types.
As you select options for indexing evidence such as files and emails, you can choose to include text identified in the RAM slack, file slack, disk slack, and the unallocated space. The EnCase Encase v8 has the ability to run add-in modules during evidence processing. Some modules ship as part of EnCase, and you can also add your own EnScript packages. The Encase v8 supports the following EnScript Modules.
The System Information Parser module identifies hardware, software, and user information from Windows and Linux computers. This module detects the operating of devices. These artifacts include messages and buddy list contents. The File Carver module of Encase searches evidence for file fragments based on a specific set of parameters, such as known file size and file signature.
Understand how the digital forensic landscape is changing and discover the key platform issues the law enforcement community should consider as they develop and optimize their cybersecurity needs. EnCase Forensic helps investigators quickly search, identify and prioritize potential evidence across computers, laptops and mobile devices to determine whether further investigation is warranted, decreasing case backlogs and closing cases faster.
EnCase Forensic acquires evidence from a variety of sources in the least obvious places, ensuring no evidence is hidden and investigators complete cases no matter where the potential evidence resides.
EnCase Forensic is built with investigators in mind, providing a range of capabilities that enable fast triage and deep forensic analysis, locating evidence quickly and closing cases faster. With comprehensive reporting options built in, EnCase Forensic offers a flexible framework to create and share reports with a wide range of audiences. Read the customer story.
Thorough evidence collection Acquire evidence from a variety of sources and dig deep into each source to uncover, collect and preserve potentially relevant information. Customizable workflows Improve investigation efficiency with optimized investigator workflows with predefined or customized conditions and filters to quickly locate evidence.
Comprehensive reporting Provide the detailed evidence results other law enforcement personnel, attorneys and judges need to close cases faster. Catch the truth Understand how the digital forensic landscape is changing and discover the key platform issues the law enforcement community should consider as they develop and optimize their cybersecurity needs.
0コメント