Based on Kroll’s ongoing examination, EventTranscript.db appears to serve as the local storage for the Windows Diagnostics and Telemetry subsystem whose contents can be displayed with the Diagnostic Data Viewer application within Windows 10. This data can be used by Windows for both diagnostics and telemetry. To an extent, the content of the database is customizable by the end user based on certain settings that reside within Windows Settings.1 Regardless of how the data recorded is customized by the user, presently two known sources exist for the data: Windows and Microsoft Edge.
When viewing the database natively within an SQLite database viewer, our digital forensics and incident response experts began inventorying and tracking table structures within EventTranscript.db. Our testing identified seven tables on a virtual machine (VM) with Windows 10 Pro 21H1 (Table 1).
|
Table Name |
|
Categories |
|
event_categories |
|
event_tags |
|
events_persisted |
|
Producers |
|
provider_groups |
|
tag_descriptions |
Table 1: Tables Identified within EventTranscript.db
Importing the database into a SQLite database tool such as Navicat for SQLite helps visualize the tables and values stored within (Figure 1).
Figure 1: EventTranscript.db SQLite Schema Table
We took a particular interest in the tag_descriptions table, which had content that appeared to describe the types of data one could expect to be recorded within EventTranscript.db (formatting adjusted here for the purpose of this blog post) (Table 2).
|
Tag Category |
Type of Data Recorded |
|
Web browsing history when using the capabilities of the application or cloud service, stored in either the service or the application |
|
|
Connections and configuration of the devices connected to the service and the network, including device identifiers’ (e.g., IP addresses) configuration, setting and performance |
|
|
Input data provided by the end user through an interaction method or action such as inking, typing, speech utterance or gesture |
|
|
Measurement, performance and operation of the capabilities of the product or service; represents information about the capability and its use, with a focus on providing the capabilities of the product or service |
|
|
End user’s interaction with the service or products by the cloud service provider; includes end user’s preferences and settings for capabilities, the capabilities used and commands provided to the capabilities |
|
|
Installation, setup and update of software |
Table 2: tag_descriptions Table Contents
Within each of these six Tag categories, event names are recorded within a column titled FullEventName. These Event names offer a more granular look at what is going on by providing a more detailed label to the diagnostic activity being recorded by the Windows operating system (Table 3).
|
Event Name |
|
LSM.LogonTime |
|
Microsoft.Windows.FileSystem.NTFS.VolumeInfo |
|
Microsoft.Windows.Inventory.Core.InventoryApplicationAdd |
|
Microsoft.Windows.Inventory.Core.InventoryDevicePnpAdd |
|
Microsoft.Windows.Kernel.Power.OSStateChange |
|
Microsoft.Windows.Taskmgr.TabViewed |
|
RDP.Transport.RDPTransportStats |
|
Win32kTraceLogging.AppInteractivitySummary |
Table 3: Representative Event Names within EventTranscript.db
As of this writing, our examiners have identified over 2,200 Event names, which (along with other items) are located within the events_persisted table. Each row within the events_persisted table contains the contents of an event’s data related to diagnostics and telemetry. For example, we located a column titled payload that contained a significant amount of potentially interesting data stored in JSON format. This data can be viewed natively within EventTranscript.db using a SQLite database tool or within the Diagnostic Data Viewer application in Windows 10.
We observed that within these events, there appears to be an amalgamation of information normally found within Event Logs and the Windows Registry. EventTranscript.db stores data relating to telemetry and diagnostics. The information stored within an event may provide additional context than the same high-level information stored within the Registry or within an Event Log. An example of this would be screen resolutions for when an application is in focus on a user’s screen. An examiner could correlate the screen resolution recorded within a diagnostic event entry with the screen resolution of the monitor used by the suspect.
In our testing environment, nearly 500,000 events were logged within Kroll’s instance of EventTranscript.db covering the range of tag descriptions (Figures 2 and 3).
Figure 2: Visual Representation of Events by Tag Description within EventTranscript.db
Figure 3: Count of Events by Tag Description within EventTranscript.db
Our experts are currently investigating a component to the Diagnostic Data Viewer and Windows 10 telemetry, i.e., diagnostic data sampling, that, when active, allows for much more detailed logging than the default settings (Figure 4). As of this writing, we have successfully enabled diagnostic data sampling in our testing environment and are working to recreate it in other environments. Without diagnostic data sampling, some of the events discussed in the Forensic Quick Wins may not be visible, but we will continue to research and document these events should they become the norm in a future iteration of Windows, such as Windows 11 and beyond.
Figure 4: Diagnostic Data Sampling Disclosure
Our experts observed that the events_persisted table will provide useful information that resides within EventTranscript.db. Within this table, each entry is categorized into one of the six Tag descriptions previously mentioned.
However, our analysis identified a seventh Tag description called Incorrect Category. This Tag description can be viewed in Diagnostic Data Viewer. At the time of this writing, the purpose of this Tag description is unknown.
During our teardown of EventTranscript.db, we observed the following columns that existed within the events_persisted table (Table 4).
|
Column Name |
Description |
|
SID |
SID of the Windows account (user/system/otherwise) associated with the activity |
|
Timestamp |
To convert this value “X”, follow this formula:
|
|
Payload |
JSON Payload of details relating to the event logged |
|
Full Event Name |
Name of the event being logged |
|
Full Event Name Hash |
Presumably the hash value of the full event name |
|
Event Keywords |
Unknown |
|
Is Core |
Boolean value which indicates whether the binary associated with the event is core to Windows
|
|
Provider Group ID |
This value will correlate with values listed in the Provider_Groups table under the Group ID column which is associated with a Group GUID |
|
Logging Binary Name |
File name of the binary associated with the event
|
|
Friendly Logging Binary Name |
Friendly name of the binary associated with the event
|
|
Compressed Payload Size |
Unknown, guessing file size in bytes of compressed JSON Payload contents |
|
Producer ID |
This value will correlate with values listed in the Producers table:
|
|
Extra1 |
Unknown |
|
Extra2 |
Unknown |
|
Extra3 |
Unknown |
Table 4
To further our understanding of this database and its integration with Windows, our experts conducted directory monitoring on C:\ProgramData\Windows\Diagnosis\EventTranscript using Directory Monitor Pro. Kroll observed a five- to 15-minute cadence of file modifications and accesses to EventTranscript.db and its associated shared memory and write ahead logs (Figure 5).
Figure 5: Cadence of File Modifications and Accesses to EventTranscript.db
Lastly, our examiners observed that the contents within EventTranscript.db persisted through traditional Event Log clearing methods that threat actors commonly employ during ransomware incidents. We foresee EventTranscript.db as a redundant source of data commonly found in the Windows Registry, Event Logs and Amcache.
Source
1Windows Settings > Privacy > Diagnostics & feedback
