TZWorks LLC
System Analysis and Programming
www.tzworks.com
(Version 0.79)
TZWorks LLC software and related documentation ("Software") is governed by separate licenses issued from TZWorks LLC. The User Agreement, Disclaimer, and/or Software may change from time to time. By continuing to use the Software after those changes become effective, you agree to be bound by all such changes. Permission to use the Software is granted provided that (1) use of such Software is in accordance with the license issued to you and (2) the Software is not resold, transferred or distributed to any other person or entity. Refer to your specific EULA issued to for your specific the terms and conditions. There are 3 types of licenses available: (i) for educational purposes, (ii) for demonstration and testing purposes and (iii) business and/or commercial purposes. Contact TZWorks LLC (info@tzworks.com) for more information regarding licensing and/or to obtain a license. To redistribute the Software, prior approval in writing is required from TZWorks LLC. The terms in your specific EULA do not give the user any rights in intellectual property or technology, but only a limited right to use the Software in accordance with the license issued to you. TZWorks LLC retains all rights to ownership of this Software.
The Software is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations. The Export Control Classification Number (ECCN) for the Software is 5D002, subparagraph C.1. The user shall not, directly or indirectly, export, re-export or release the Software to, or make the Software accessible from, any jurisdiction or country to which export, re-export or release is prohibited by law, rule or regulation. The user shall comply with all applicable U.S. federal laws, regulations and rules, and complete all required undertakings (including obtaining any necessary export license or other governmental approval), prior to exporting, re-exporting, releasing, or otherwise making the Software available outside the U.S.
The user agrees that this Software made available by TZWorks LLC is experimental in nature and use of the Software is at user's sole risk. The Software could include technical inaccuracies or errors. Changes are periodically added to the information herein, and TZWorks LLC may make improvements and/or changes to Software and related documentation at any time. TZWorks LLC makes no representations about the accuracy or usability of the Software for any purpose.
ALL SOFTWARE ARE PROVIDED "AS IS" AND "WHERE IS" WITHOUT WARRANTY OF ANY KIND INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL TZWORKS LLC BE LIABLE FOR ANY KIND OF DAMAGE RESULTING FROM ANY CAUSE OR REASON, ARISING OUT OF IT IN CONNECTION WITH THE USE OR PERFORMANCE OF INFORMATION AVAILABLE FROM THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY DAMAGES FROM ANY INACCURACIES, ERRORS, OR VIRUSES, FROM OR DURING THE USE OF THE SOFTWARE.
The Software are the original works of TZWorks LLC. However, to be in compliance with the Digital Millennium Copyright Act of 1998 ("DMCA") we agree to investigate and disable any material for infringement of copyright. Contact TZWorks LLC at email address: info@tzworks.com, regarding any DMCA concerns.
Computer Account Forensic Artifact Extractor is a Windows registry parser which targets several specific registry keys that help identify user activity as it pertains to files and program execution. Chosen are a handful of registry entries that are specific to an account's registry hive(s). This includes both a user's ntuser.dat hive and the usrclass.dat hive for Vista and later operating systems. Collectively, these two registry hives contain artifacts useful in piecing together file/program activity that occurred on a specific account.
Why build another Windows registry parser when there are plenty of good registry parsers freely available on the Internet? The answer is simple. We listened to the feedback that was submitted to our shop by the forensics community; specifically to take some of the yaru functionality and make an easy to use command line tool. The desire was to use it in a batch processing mode while outputting the data into one of the more common formats so that it could be 'somewhat easily' fused together with varying artifacts from other sources. The initial versions of the tool focused on ntuser.dat and usrclass.dat hives. New versions were extended to include report generation to the other hives as well.
cafae consists of the same parsing engine that is in yaru but is packaged into a console application. Consequently, the reports that are generated will look similar to those of yaru's, but will have more output options. These options include several CSV variants, the ability to change the date format as well as, the ability to set the time precision up to the native Windows internal precision (100 ns)
Other useful aspects of cafae include the following:
To use this tool, an authentication file is required to be in the same directory as the binary in order for the tool to run.
cafae is a console application that primarily targets user registry hives (eg. ntuser.dat and usrclass.dat files), with some limited capability for other hives. To use this tool on a live system to access the raw hives, one will need to open the command prompt with administrator privileges first. The menu options can be displayed by typing in the executable name without any parameters. The menu groups the available artifacts by area of analysis, where each artifact can either be extracted independently or combined per command issued. Since each artifact comes from a specific type of user hive, each option identifies which hive (either ntuser.dat or usrclass.dat) it expects to receive as input for it to successfully extract data.
The registry artifacts are grouped into the following categories: (a) running a program, (b) opening files, (c) searching/browsing and (d) network/computer settings. The output options include: (a) the default output, where each record is on a separate line and each field is separated by the pipe character, (b) the SleuthKit body-file format and (c) the log2timeline CSV (comma separated value) format.
Below is the menu with the various options. Details of the main options can be found here. Individual artifact options are found here.
cafae64 -hive <path/hive> [reg artifacts] [format opts] [misc opts]Usage: cafae -hive <path> [reg artifacts] [format opts] [misc opts] cafae -livehives = list user hives available cafae -pull_hashes -sam <hive> -system <hive> = standalone option cafae -showkeys <option> = display keys for query cafae -showcmds <option> = display script cmd for query [user hive artifacts - associated with running a program] -openrun_mru -userassist -programs_cache -muicache = ntuser.dat (xp), usrclass.dat (win7) -otherapps_run [ntuser.dat hive artifacts - associated w/ opening files] -recent_docs -stream_mru -opensave_mru -office_docs -open_with [system hive artifacts] -timezone -devices = USB, USBSTOR, STORAGE, etc -shimcache = AppCompatCache artifacts -bam = Backgrd Activity Moderator artifacts [software hive artifacts] -clsids = (takes awhile to run) -inprocservers = Objects invoking DLLs (takes awhile to run) -codecs -explorer -installed_sw -emdmgmt -shell_spawn [Applies to multiple hives] -runkeys = software and user hives -computer = system, software and user hives -network = system, software and user hives -volumes = system, software and user hives -restore = system and software hives -web = software and user hives -services = system and software hives -persistence = system, software and user hives [collection of registry artifacts] -all_user = all ntuser and usrclass artifacts -all_software = all Software artifacts (minus clsid) -all_system = all System artifacts -all_security = all Security artifacts -all_amcache = all AmCache artifacts -all_sam = all Sam artifacts -all_syscache = all Syscache artifacts Basic options -csv = output in comma separated value format -csvl2t = log2timeline output -bodyfile = sleuthkit output Additional options -base10 = output number in base10 vice hex output -userstats = pull acct from hive [ntuser.dat only] -username <name> = output will contain this username -hostname <name> = output will contain this hostname -dateformat mm/dd/yyyy = "yyyy-mm-dd" is the default -timeformat hh:mm:ss = "hh:mm:ss.xxx" is the default -pair_datetime = combine date/time into 1 field for csv -no_whitespace = remove whitespace between csv delimiter -csv_separator "|" = use a pipe char for csv separator -pipe = pipe hives into cafae for processing -no_regkey_hdr = remove registry key header from output -quiet = no progress shown -filter <*partial*|*.ext> = filters stdin data from -pipe option -all_controlsets = process all ControlSets in System hive [misc data options] (experimental) -stats = registry statistics -scan_size <min size> = locate data at this size or larger -scan_entropy [80 - 90] = locate data w/ this value or larger -carve [-vals] = all keys, even deleted -carve_deleted [-vals] = dump deleted entries -merge "log1|log2" -hive <orig hive> -out <new_hive> -diff "hive1|hive2" = show diffs between hives Exposing the internal scripting options -key <path> [-enumvalues] [-level <#>] [-extract "val1|val2|.."] [-notruc] -cmdfile <filename> [-show_null_results] = file with list of cmds
To process a specified hive, one uses the -hive <location of hive to process> option with the specific artifact one is interested in. For example, assuming a user hive was extracted to the c:\dump directory, one could to review all the Microsoft Office documents accessed by this user by typing:
cafae -hive c:\dump\ntuser.dat -office_docs > office_docs.txt
Since the output that is generated is very wide, it is recommended that one redirect the output of the command into a file as show above. Then, it can be reviewed in any text editor by turning off the word wrap option to see each record on its own line.
For starters, to access Volume Shadow copies, one needs to be running with administrator privileges. Also, it is important to note that, Volume Shadow copies as is discussed here, only applies to Windows Vista, Win7, Win8, and beyond. It does not apply to Windows XP.
To make it easier with the syntax, we've built in a shortcut syntax in order to more easily access a specific file in a specified Volume Shadow copy, via the %vss% keyword. This internally gets expanded into \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy. Thus, to access index 1 of the volume shadow copy, one would combine the keyword and index, index, (eg. %vss%1) in front of the normal path of the file. For example, to access a file located in the testuser account from the HarddiskVolumeShadowCopy1, the following syntax can be used:
cafae -hive %vss%1\Users\testuser\ntuser.dat -office_docs > office_docs.txt
To determine which indexes are available from the various Volume Shadows, one can use the Windows built-in utility vssadmin, as follows:
vssadmin list shadows -- or to filter out extraneous detail -- vssadmin list shadows | find /i "volume"
While the amount of data can be voluminous from that above command, the keywords one needs to look for are names that look like this:
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
...
From the example above, notice the number after the word HarddiskvolumeShadowCopy. This would be the number that is appended to the %vss% keyword.
As a disclaimer, this version of cafae does not contain all the requisite registry keys that may be of interest to a computer forensic analyst, but it encompasses some of the more common ones. Furthermore, every attempt has been made to ensure that this tool parses data correctly; however, parsers are only as good as the sample datasets that were used during the development/testing process. Since we have a limited set of sample hives to test on, we cannot guarantee that the data in your registry hives will be parsed accurately.
Below are examples of the more interesting registry artifacts cafae can extract. Each subsection includes which registry keys are examined and the command line syntax that is used
These keys track the program that was last used to access files listed in the Open/Save dialog box MRU subkey. With Vista and later, most of these entries record the timestamp that the program was executed. The MRU (Most Recently Used) value will show the order of the entries, starting with the most recently used. cafae makes use of this MRU value to sort the output from most to least recently accessed.
Example: cafae -hive user.win7.hive -openrun_mru > out.txt
This key contains values that identify programs executed by a user account. Entries are a mix of executable files and an associated link entry. Many of the entries contain the last execution time along with the number of times the application was run. While the last execution time seems reliable, the run count data is still under evaluation and is based on empirical data. Therefore the results of this output should be considered experimental.
Example: cafae -hive user.win7.hive -userassist > out.txt
The ProgramsCache key records which application was launched as well as when it was launched. The size of the file refers to the link file and not the target file the link points to. Included are any parameters used with the link file.
Example: cafae cafae -hive user.winxp.hive -programs_cache > out.txt
The operating system records what applications are launched by a user account, by recording the name of the application as well as the "File Description" information. This is part of the version information stored in the portable executable of the binary that was launched. Unfortunately, there is no temporal information associated with each entry.
Example: cafae -hive user.winxp.hive -muicache > out.txt
The Run and RunOnce registry keys cause programs to run each time that a user logs on. The last one listed is the SysInternals keys. It identifies which tool was run from the SysInternals suite.
// to evaluate only the runkeys, use Example: cafae -hive user.win7.hive -runkeys > out.txt // to evaluate the list above, use Example: cafae -hive user.win7.hive -otherapps_run > out.txt
For the standard "Explorer\RecentDocs" item, this key contains the recent documents as identified in the Windows "My Recent Documents" menu. Within the key is a "MRUListEx" value that identifies the most recently viewed items. If one parses the MRUListEx, one can display the items in the order that they were accessed relative to each other. cafae will output this list of items in the proper order starting with the most recently viewed first. While there is no temporal information associated with each entry, one can use the registry last modification time associated with the subkey to determine when the most recent item was opened.
Example: cafae -hive user.win7.hive -recent_docs > out.txt
Per the MSDN article 235994, the Streams registry entries store the size and location information for closed windows. Per the article, Windows saves this information for up to 28 different windows. The association for the Streams subkey with a particular window is stored in the StreamMRU subkey.
Example: cafae -hive user.winxp.hive -stream_mru > out.txt
The operating system tracks files that have been opened or saved from an "Open/Save As" shell dialog box through this registry key. It contains values and a number of multiple subkeys. The subkeys group values by extension. With Vista and later, most of these entries record the timestamp that the action occurred. cafae sorts these entries primarily by folder subkey and subsequently by most recently used. The output includes an arrow to designate which item was the last one modified.
Example: cafae -hive user.win7.hive -opensave_mru > out.txt
Per the MSDN article 826208, many Microsoft Office programs maintain a list of the most recently used (MRU) files. Additionally, the various Office programs display this MRU list on the File menu and in several other locations. These locations include the Open dialog box, the Save As dialog box, and the Insert Hyperlink dialog box. The purpose of this feature is to provide quick access to files that a user is working on.
Example: cafae -hive user.win7.hive -office_docs > out.txt
This registry key has a separate subkey for each extension of the file that was opened. Within each extension subkey, the list associates which application is used to open a file with that specific extension.
Example: cafae -hive user.win7.hive -open_with > out.txt
For Windows XP there is the ACMru key, which stores search terms that have been typed into a Windows search dialog box. The following subkeys define where the search term was used:
Unfortunately, Vista did not include a registry key for user searches. Windows 7, however, defines the WordWheelQuery subkey to record information about user searches.
Deprecated: cafae -hive user.win7.hive -search_history > out.txt New way: cafae -hive user.win7.hive -web > out.txt
Data in this key is added when a user types (or adds via copy/paste) a URL directly into the browser. The list of URLs is sorted by number where the lowest number is the last, or most recently typed, URL.
Deprecated: cafae -hive user.win7.hive -typed_urls > out.txt New way: cafae -hive user.win7.hive -web > out.txt
This set of keys covers the shortcuts on the Windows Start Menu and the TaskBar, respectively. Shown below is an example of the parsed output of the TaskBar shortcuts.
Deprecated: cafae -hive user.win7.hive -favorites > out.txt New way: cafae -hive user.win7.hive -web > out.txt
Example: cafae -hive user.win7.hive -networks > out.txt
Example: cafae -hive user.win7.hive -volumes > out.txt
This last subsection is a catch all for other useful artifacts that pertain to the computer configuration as set by (or indirectly affected by) the user. Some of the registry keys include:
Example: cafae -hive user.win7.hive -computer > out.txt
This includes a combination of previous keys used for other options as well as some new ones collected in one place to pull persistence type data.
Example: cafae -hive user.win7.hive -persistence > out.txt
Example: cafae -hive system_hive -timezone > out.txt
Example: cafae -hive system_hive -devices > out.txt
Example: cafae -hive system_hive -shimcache > out.txt
Example: cafae -hive system_hive -computer > out.txt
Example: cafae -hive system_hive -networks > out.txt
Example: cafae -hive system_hive -volumes > out.txt
Example: cafae -hive system_hive -restore > out.txt
Example: cafae -hive system_hive -services > out.txt
Example: cafae -hive system_hive -bam > out.txt
This includes a combination of previous keys used for other options as well as some new ones collected in one place to pull persistence type data.
Example: cafae -hive system_hive -persistence > out.txt
Example: cafae -hive software_hive -clsid > out.txt
Example: cafae -hive software_hive -inprocservers > out.txt
Example: cafae -hive software_hive -codecs > out.txt
Example: cafae -hive software_hive -explorer > out.txt
Example: cafae -hive software_hive -installed_sw > out.txt
Example: cafae -hive software_hive -emdmgmt > out.txt
Example: cafae -hive software_hive -shell_spawn > out.txt
Example: cafae -hive software_hive -computer > out.txt
Example: cafae -hive software_hive -networks > out.txt
Example: cafae -hive software_hive -volumes > out.txt
Example: cafae -hive software_hive -restore > out.txt
Example: cafae -hive software_hive -services > out.txt
Example: cafae -hive software_hive -runkeys > out.txt
Example: cafae -hive software_hive -web > out.txt
This includes a combination of previous keys used for other options as well as some new ones collected in one place to pull persistence type data.
Example: cafae -hive software_hive -persistence > out.txt
Example: cafae -hive security_hive -all_security > out.txt
Example: cafae -hive sam_hive -all_sam > out.txt
Example: cafae -hive amcache_hive -all_amcache > out.txt
Transaction logs are used to enhance the reliability of the Windows operating system (OS) when updating the registry files. Basically, these log files are journals that records the registry data that is to be updated prior to the OS actually committing the final writes to the registry hive. These logs can have the following extensions: .LOG, .LOG1 and .LOG2. The LOG1 and LOG2 extensions are when the OS is in a dual logging mode (new OS's) and the .LOG is when the OS is In the single logging mode. Many times, when looking in the directory containing the hive, one will see all three extensions present.
The terminology "dirty" and "clean" can be used to designate when the hive is out of date or has been updated and is in sync with all the data, respectively.
To determine when a registry hive is 'dirty' and needs to be updated with its transaction log(s) information, one can look at either the associated hive's checksum as well as the primary and secondary sequence numbers. An incorrect checksum usually implies the hive is corrupted and a mismatch of the primary and secondary sequence numbers implies the registry hive needs to be updated with the transaction log data.
When analyzing the transaction log data, one can see there are multiple sequence numbers associated with the records. This is because, the log is constantly updated with new information and uses a wrap technique to overwrite older records. The sequence number is the indicator to the order the information is applied. Therefore, when updating a registry hive, one looks at the hive's sequence number and tries to find updated data associated with that sequence number to ensure the hive is in sequence with the updates that were applied to the log file. Therefore, when using the merge option with cafae, the tool may determine that no updates are required for a number of reasons: (a) the hive is clean (not dirty) or (b) the hive is dirty, but the appropriate sequence number for updates were not found in one or more of the log files.
To use the merge option, it is advisable to include all log files in the command line. In this way, cafae will be able to parse each of the log files, order all the data extracted by sequence number and only act on those records that are appropriate for the update. Below is an example of doing this:
cafae -merge "amcache.hve.log|amcache.hve.log1|amcache.hve.log2" -hive amcache.hve -out amcache.hve.merged.bin
If the target hive is already up to date, the following message is displayed.
Hive seq#'s match, thus already up to date, no merge required
If the target hive is dirty and can be updated, then the following message will be displayed if the merge is successful.
Updates merged successfully
One of the newer options is the ability to difference two hives. This option is useful when trying to determine the changes over time between an older hive snapshot with that of a newer one. The output will only show the changes, whether they are deleted, added or modified entries. The algorithm only looks at changes of subkeys, value names and value data. It does not look at changes in registry subkey timestamp changes nor does it look at entries in slack space.
Each change is shown on a separate CSV type delimited line, identifying the type of change and what was changed. This is particularly useful when trying to determine the changes made to a hive prior to an installation of some software and after the installation.
The syntax for comparing the same hive during two different timeframes.
cafae -diff "snap1_amcache.hve|snap2_amcache.hve" -csv -out amcache.hve.diffs.csv
If desiring to view the output in the Log2Timeline format use the -csvl2t option.
As new registry artifacts are discovered, or as certain artifacts become more important to some clients over others, it would be nice to use cafae to parse those new artifacts without the need for any coding experience.
cafae has always had an internal quasi-scripting interface that can translate specially formatted strings to tell the engine which registry subkeys to analyze and/or which values to extract. Up until now, it just has not been available as an option for the outside user.
The two main options include: (a) quick parse using the -key option and (b) parsing using a user defined template via the -cmdfile option. The first is useful when exploring the registry, while the second is useful for repeatable analysis by running a script that has been vetted by an experienced security team.
These options are labeled as experimental for the following reasons. (a) When exposing the internals of a parsing engine, one can combine conflicting options that can cause a tool to be unstable, or provide seemingly stable results for one version of the tool and not the next version, (b) as the internal engine improves (or bugs removed) over time, an unintended nuance that the scripting engine made available with some combination of commands, may or may not be changed. Therefore, trying to maintain backward compatibility to some specific quirk the engine had at one time is very difficult. Consequently, aside from the most basic capabilities, the scripting engine will most likely be in the beta mode for a long time.
What we can offer the user, however, is if one develops a script that they would like retained (as far as functionality) for future releases, then send us a copy of the script and we will put it into our regression testing to ensure the functionality is retained.
Aside from the experimental nature of scripting, the benefit of using the template option is that once you create a script that extracts the data you want, in the desired format, then it is very easy to give that to a less experienced person to pull the desired data in a repeatable manner.
For those cases where one would like to extract a certain group of artifacts, templates can be useful. Once a template is defined, it can be used to ensure repeatable parsing of the same artifacts for each session run.
The templates are just text files, so they can be generated with any text editor. Care must be taken to ensure that extra control characters are not inserted into the text files. Having extra control characters will negatively affect the template parsing engine. For this reason, it is recommended that a simple text editor (like notepad) be used.
The parsing rules for these templates are as follows:
-enumreg, -key, <registry key path of parent key to operate on>, -level, <number of levels to evaluate from parent key > [either 0 or 1], -enumvalues, [or -enumkeys], -sort_by_name, [or -sort_by_date], -name, <name of this artifact>
// 1. Create a text file with this line called c:\dump\test.txt !cmd, -enumreg, -key, HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation, -level, 0, -sort_by_name, -enumvalues, -comment, TimeZone data // 2. While in an cmd prompt with admin privs, invoke the file in cafae via: cafae -hive c:\windows\system32\config\system -cmdfile c:\dump\test.txt > out.txt // 3. Open the out.txt file, which should yield similar data such as this: ... --------------------------------------------------------------------------------------------------------- Artifact: TimeZone data Registry key: SYSTEM\CurrentControlSet\Control\TimeZoneInformation --------------------------------------------------------------------------------------------------------- reg date | reg-UTC | value name | value data 01/13/2009 | 16:37:51.540 | ActiveTimeBias | 300 01/13/2009 | 16:37:51.540 | Bias | 300 01/13/2009 | 16:37:51.540 | DaylightBias | 4294967236 01/13/2009 | 16:37:51.540 | DaylightName | Eastern Standard Time 01/13/2009 | 16:37:51.540 | DaylightStart | 00 00 04 00 01 00 02 00 00 00 00 00 00 00 00 00 01/13/2009 | 16:37:51.540 | StandardBias | 0 01/13/2009 | 16:37:51.540 | StandardName | Eastern Standard Time 01/13/2009 | 16:37:51.540 | StandardStart | 00 00 0a 00 05 00 02 00 00 00 00 00 00 00 00 00
In step 1 above, you create a template file. You can put as many !cmd's as you like. Each command should be on one line. After saving your file, you can invoke it in cafae using the -cmdfile switch passing the path/file of the template file you created. Notice that you need to also specify which hive you wish to operate on, as well as the -hive switch. In step 3, you can view the results that were created.
For more examples on templates to see the various options one can use, each of the automatic reports in cafae can be generate with a separate template file. Contact, info@tzworks.com to get a copy of these template files.
When running cafae to pull many artifacts from a hive into one results file, the CSV output will vary depending on artifact that is processed. While the -bodyfile and -csvl2t formats will preserve the CSV structure, the default CSV output will show the results as segmented CSV sections. Each CSV section will represent a different artifact type. This can create problems when trying to import the cafae results into other databases for analysis.
To solve this problem, one can use the csvdx tool to take the segmented CSV results (or any CSV results) and convert the artifact output it into either JSON or SQLite. See the csvdx webpage here and/or user guide.
Option | Description |
---|---|
-hive | Use this specified target hive to process artifacts from. Syntax is -hive <hive file> |
-livehives | List the local user hives available on the target machine. |
-pull_hashes | Given a SAM and SYSTEM hive via the options -sam <hive> and -system <hive> will extract the encrypted hashes and decrypt them. Doesn't try to compute the text password, but only shows the unencrypted hashes of the password. Syntax is -pull_hashes -sam <hive> -system <hive> |
-showkeys | Display the registry keys extracted using the specified option. Syntax is -showkeys [artifact option] |
-showcmds | Display the internal script used for the specified option. This can assist users in developing their own custom scripts by see how we have used the internal scripting engine. Syntax is -showcmds [artifact option] |
-all_user | Extract all user unique artifacts. Applies to the ntuser.dat and usrclass.dat hives. |
-all_software | Extract all software unique artifacts. Applies to the software hive. |
-all_system | Extract all system unique artifacts. Applies to the system hive. |
-all_securty | Extract all security unique artifacts. Applies to the security hive. |
-all_sam | Extract all account details from SAM hive. |
-all_amcache | Extract all AmCache unique artifacts. Applies to the AmCache.hve hive. Only applies to Windows 8 and above; this hive replaced the RecentFileCache.bcf file. |
-carve | Experimental option. Given any hive or partial hive, this option will try to extract keys. Useful option if the hive is corrupted. If desiring to extract values as well as the keys, use the -vals switch in conjunction with the option. |
-carve_deleted | Experimental option. Given any hive or partial hive, this option will try to extract deleted keys. If desiring to extract values as well as the keys, use the -vals switch in conjunction with the option. |
-stats | Experimental option. Displays header information from the hive and shows the frequency of keys modified in a day for the range of the hive. |
-scan_size | Scans registry entries locating those that are at or above a specified threshold size. The syntax is -scan_size <minimum size>. |
-scan_entropy | Scans registry entries locating those have sufficient randomness to warrant an entropy percentage that is specified or that is larger. Values of 80 through 90 are good values to search for. The syntax is -scan_entropy <percent entropy>. |
-merge | Experimental. Takes one or more log files and merges them into associated base hive. The syntax is -merge "log1|log2" -hive <orig hive> -out <new_hive> . Algorithm checks to ensure log files have the proper sequence number entries available prior to merging. |
-diff | Experimental. Takes 2 or more hives and diffs them outputting the delta changes. The syntax is -diff "hive1|hive2". Internally, this option will try to compare the oldest hive to the latest hive. If that is not desired, one can force the order of comparison by using the sub-option -retain_order. Sub-options allowed for formatting the output include: -csv and -csvl2t. If wishing to see which files are being compared along with their sequence numbers, use the sub-option: -diff_metadata. |
-key | Experimental option that allows the user to parse a specified registry subkey path from a specified hive quickly. Since this option has a number of nested options, and consequently allows one to specify many options at once, cafae may become unstable depending if various options are inputted into it that are in conflict. The default behavior will enumerate values. To enumerate keys, use the option [-enumkeys]. The -level switch allows one to go zero or more levels deep. The default is 0 levels (which means, just the first level). The [-extract "val1|val2|..|valN"] option allows one to specify which value names to extract to the output. The syntax is -hive <reg hive> [-enumkeys] [-level <#>] [-extract "field1 | field2 | ... | fieldN"] . |
-cmdfile | Experimental option. This is similar to the -key option, however, it allows one to put many commands into one file and have cafae process the commands in that file in one session. The syntax is -cmdfile <filename>. The command syntax is discussed in the "User Defined Templates" section above. |
-csv | Outputs the data fields delimited by commas. Since filenames can have commas, to ensure the fields are uniquely separated, any commas in the filenames get converted to spaces. |
-csvl2t | Outputs the data fields in accordance with the log2timeline format. |
-bodyfile | Outputs the data fields in accordance with the 'body-file' version3 specified in the SleuthKit. The date/timestamp outputted to the body-file is in terms of UTC. So if using the body-file in conjunction with the mactime.pl utility, one needs to set the environment variable TZ=UTC. |
-base10 | Ensure all size/address output is displayed in base-10 format versus hexadecimal format. Default is hexadecimal format. |
-username | Option is used to populate the output records with a specified username. The syntax is -username <name to use> . |
-hostname | Option is used to populate the output records with a specified hostname. The syntax is -hostname <name to use>. |
-userstats | Pulls username account information from hive [ntuser.dat only] and populates output with the extracted username. |
-pipe | Used to pipe files into the tool via STDIN (standard input). Each file passed in is parsed in sequence. |
-enumdir | Experimental. Used to process files within a folder and/or subfolders. Each file is parsed in sequence. The syntax is -enumdir <"folder"> -num_subdirs <#>. |
-filter | Filters data passed in via stdin via the -pipe option. The syntax is -filter <"*.ext | *partialname* | ...">. The wildcard character '*' is restricted to either before the name or after the name. An example of using the filter to screen out just user hives would be the following: dir C:\Users /b /s /a | cafae -pipe -filter "ntuser.dat|usrclass.dat" |
-notruc | The default behavior is to truncate large datasets and only show the first part of the data (applies to binary data). If you want change the default behavior then use this option to not use any truncation. Doing this, however, may not render your data in a usable format. |
-no_whitespace | Used in conjunction with -csv option to remove any whitespace between the field value and the CSV separator. |
-csv_separator | Used in conjunction with the -csv option to change the CSV separator from the default comma to something else. Syntax is -csv_separator "|" to change the CSV separator to the pipe character. To use the tab as a separator, one can use the -csv_separator "tab" OR -csv_separator "\t" options. |
-dateformat | Output the date using the specified format. Default behavior is -dateformat "yyyy-mm-dd". Using this option allows one to adjust the format to mm/dd/yy, dd/mm/yy, etc. The restriction with this option is the forward slash (/) or dash (-) symbol needs to separate month, day and year and the month is in digit (1-12) form versus abbreviated name form. |
-timeformat | Output the time using the specified format. Default behavior is -timeformat "hh:mm:ss.xxx" One can adjust the format to microseconds, via "hh:mm:ss.xxxxxx" or nanoseconds, via "hh:mm:ss.xxxxxxxxx", or no fractional seconds, via "hh:mm:ss". The restrictions with this option is that a colon (:) symbol needs to separate hours, minutes and seconds, a period (.) symbol needs to separate the seconds and fractional seconds, and the repeating symbol 'x' is used to represent number of fractional seconds. (Note: the fractional seconds applies only to those time formats that have the appropriate precision available. The Windows internal filetime has, for example, 100 nsec unit precision available. The DOS time format and the UNIX 'time_t' format, however, have no fractional seconds). Some of the times represented by this tool may use a time format without fractional seconds and therefore will not show a greater precision beyond seconds when using this option. |
-pair_datetime | Output the date/time as 1 field vice 2 for csv option |
-quiet | Don't show the progress. |
-all_controlsets | Experimental. If processing a system hive, this option will tell cafae to look at all the ControlSets versus just the default ControlSet (called the CurrentControlSet). |
-utf8_bom | All output is in Unicode UTF-8 format. If desired, one can prefix an UTF-8 byte order mark to the CSV output using this option. |
This tool has authentication built into the binary. The primary authentication mechanism is the digital X509 code signing certificate embedded into the binary (Windows and macOS).
The other mechanism is the runtime authentication, which applies to all the versions of the tools (Windows, Linux and macOS). The runtime authentication ensures that the tool has a valid license. The license needs to be in the same directory of the tool for it to authenticate. Furthermore, any modification to the license, either to its name or contents, will invalidate the license.
The tools from TZWorks will output header information about the tool's version and whether it is running in limited, demo or full mode. This is directly related to what version of a license the tool authenticates with. The limited and demo keywords indicates some functionality of the tool is not available, and the full keyword indicates all the functionality is available. The lacking functionality in the limited or demo versions may mean one or all of the following: (a) certain options may not be available, (b) certain data may not be outputted in the parsed results, and (c) the license has a finite lifetime before expiring.