Forensic Artifacts — Symantec EDR “localdatastore” Folder
Recently one of my colleagues (@elromaissa2) shared with me an interesting set of blog posts called “Your AV is Trying to Tell You Something” by @bmmaloney97. Where the author explores and analyzes a set of log files from Symantec Endpoint Protection (SEP for short) and uncovers a lot of interesting information stored there. Similarly, I thought I’ll take a look at Symantec EDR and try to look for interesting artifacts. In this quick blog post i describe my findings so far.
Quick Overview
For anyone not familiar with Symantec EDR here is a quick overview of the product (at least the on-premises version).
Symantec EDR as every other EDR collects data (process creation, file read, registry modification…etc) from endpoints. If you have SEP installed already it integrates seamlessly without the need of an agent, otherwise, a dissolvable agent is required. Data collected from an endpoint is stored in the following folder
\ProgramData\Symantec\Symantec Endpoint Protection\[Version]\Data\EDR\localdatastore
The size of the folder (i.e the maximum amount of data collected and stored on an endpoint) is configured from the EDR administration interface. The data can be sent in real time or in batches depending on the configuration.
A full dump/process dump can be performed on an endpoint to retrieve all the collected data at once or data on a specific process respectively.
Local Data Store
The “localdatastore” folder contains sub-folders each containing portions of the data collected. For example, data collected on the 16th of February 2021 will be stored inside a folder named “20210216XXX” where “XXX” is a number (not required) between “000” and “999”. Inside this folder, we find some interesting files.
- “.ldb” files. Which are “MySQL ISAM index file” according to the binwalk results.
- “LOG” file. That contains information about transactions made to the “.ldb” files
- “.log” file (I’ll talk about this below)
- Other files
“.log” File
Each time some data is collected from the endpoints it gets written to a “.log” file before it gets written to the “.ldb” files where it’ll be compressed.
If we execute the string command on the “.log” file we’ll get some interesting results showing all of the commands, network communication, processes executed. Below is an example output of the content of the file.
The log above has the event ID of “8006: Registry Value Event” which is an event generated when an application writes or modifies a windows registry value.
Unfortunately, since this is a temporary file the information doesn’t stay long. As it's written eventually to the “.ldb” file and replaced with newly generated data. If you’re investigating a live machine that could be infected with some malware or something in the like and let’s say for example only Symantec EDR is present (No additional logging is enabled). We can write a system file watcher in PowerShell to copy the “.log” files each time one is created to another location for further analysis. The code below is a simple example of how to achieve that.
$fileSysWatcher = New-Object System.IO.FileSystemWatcher$fileSysWatcher.IncludeSubdirectories = $true$fileSysWatcher.Path = [Path to the localdatastore folder]$fileSysWatcher.EnableRaisingEvents = $true$action ={$path = $event.SourceEventArgs.FullPath$changetype = $event.SourceEventArgs.ChangeType$ext = [IO.Path]::GetExtension($path)if ($ext -eq ".log"){Copy-Item -Path $path -Destination [Path to new location]}}Register-ObjectEvent $fileSysWatcher 'Created' -Action $action
The string command can also be executed on the “.ldb” but to a less great benefit. As the “.ldb” files don’t provide readable “strings” as the “.log” files. Nonetheless, it can be a good source to find evil or evidence when doing forensics on a machine.
Note: After executing the string command on the “.log” file you’ll get a file that contains valid JSON data with some garbage. A parser could be written to extract the data required.
Conclusion
This was a quick look at the “localdatastore” folder in the Symantec EDR product. I’ll keep analyzing the logs and files in the hope to find more interesting artifacts.
If you have any questions or suggestions hit me up on Twitter @nas_bench.