Event Lists
Available only with a forensic license, when working with a case, for evidence objects with a volume snapshot.
When extracting metadata (part of volume snapshot refinements), X-Ways Forensics can compile a list of events from timestamps that can be found at the file system level as well as internally in files and in main memory. Conceivable sources are browser histories, Windows event logs, Windows registry hives, e-mails, etc. An event list works exactly like a search hit list and can be displayed by clicking a button which is located next to the search hit list button, with a clock icon on it. Just like a search hit list, an event list comes with additional columns: the event timestamp, event type, event category, and some events have an individual description/additional text, for example events recorded in the Windows registry and in Internet Explorer index.dat files.
If an event list is sorted chronologically, by timestamps, it works like a timeline, which may allow you to figure out a sequence of events of different kinds stored in different places (e.g. e-mail received, attachment saved, application started, document printed, file deleted) that otherwise could not be seen together in context. You may see events from different evidence objects at the same time as usually from the case root window, explore recursively or by path, sort by event type or event category, see all the usual file properties, view files, navigate to the definition of an event within a file (if a relative offset is available) and filter for certain date ranges.
You may mark events as notable just like search hits and filter for notable events via the Timestamp column.
Event-based analysis instead of file-based analysis is a progressive new approach with a totally different perspective that may lead to knowledge about activities recorded on computers that otherwise could hardly be gained. You may see connections (related activity) that otherwise could be overlooked, and may be able to better explain the logic behind what has happened.
The sources of events that are exploited by the metadata extraction in this version include all the supported file systems (i.e. all the timestamps listed in the timestamp columns of the directory browser; modification, record update and last access are omitted if identical to the corresponding creation timestamp), processes in supported memory dumps, extracted or processed e-mail, as well as files of these types:
index.dat
Internet browser SQLite databases
.firefox (~55) fragments
_CACHE_001_ and _CACHE_002_
.lnk shortcuts
.automaticDestination-ms
.chrome Chromium cache data_1, data_2
.usnjrnl fragments
Registry hives*
Windows .evt event logs
Windows .evtx event logs (Most extracted events come with a description that includes the event source, the event ID and the record number. The record number allows you to quickly search for the record in the HTML preview if you need further details about that particular event.)
DataStore.edb (MS Windows operating system update events)
.hbin Registry hive fragments
.doc (last printed)
.msg
rp.log XP restore point
INFO2 XP recycle bin
.recycler Vista recyle bin
.snapprop Vista volume shadow copy properties
.cookie
.gthr;.gthr2 Gatherer and Gatherer fragments
.pf prefetch
attach timestamps from EDB
signing date from EXE/DLL/SYS/...
boot time from ETL (event trace log) files
OLE2 last modification
last saved in Office documents and RTF
Skype main.db (chats, calls, file transfers, account creation, ... - you can read entire chats if sorted chronologically)
Skype Chat Sync
internal creation from miscellaneous file types, including Exif timestamps from photos
JPEG GPS
Unix/Linux/Macintosh system logs (These events are practically of significance especially for USB device history examinations.)
* More specialized events than just standard registry timestamps are output optionally when you create a registry report, depending on the report definitions used!
The event type is displayed in gray if the timestamp is a previously valid timestamp, for example such as those found in NTFS in 0x30 attributes or index records of INDX buffer slack or in $LogFile.
Timestamps from 0x30 attributes in NTFS file systems are output as events only if actually different from their 0x10 counterparts and not identical to the 0x30 creation timestamp. They are marked as "0x30" in the Event Type column. Malware might give itself harmless looking timestamps after deployment, so that it does not seem to be related to the time of intrusion/infection. The 0x30 attribute timestamps, however, remain unaltered (except if the file is renamed or moved later), and that is the reason why some examiners are interested in them. If the time frame of intrusion/infection is known, related files would be found in the event list thanks to the original 0x30 attribute timestamps.
0x30 timestamps are marked in the event list with a "greater than" symbol if they are later than the corresponding 0x10 timestamps, which seems unnatural and in some rare cases might be the result of backdating by the rightful users of the computers themselves. Under certain circumstances, backdating documents is seen as fraudulent and illegal. However, much more commonly 0x10 timestamps predating 0x30 timestamps is just the work of installation programs or the result of copying a file or moving a file from one volume to another or extracting a file from a zip archive, where Windows or other programs artificially apply the original creation time of the source file to the destination once copying turns out to be successful (internal programmatic backdating).
The selections in the event type filter are not remembered by the program from one session to the next.
Please see the description of the timestamp columns for more information.