Forensic Artifacts — Symantec EDR “localdatastore” Folder

Recently one of my colleagues 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 analyze a set of log files from Symantec Endpoint Protection (SEP for short) and uncovers a lot of interesting information stored in 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

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

  • “.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

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.

Example of SEDR Log

The log above has the event ID of “8006: Registry Value Event” which is an event generated when an application write or modify a windows registry value.

Unfortunately since this is a temporary file the information doesn’t stay long. As its 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 on 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 greater 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 which contains valid JSON data with some garbage. A parser could be written to extract the data required.

Conclusion

If you have any questions or suggestions hit me up on twitter @nas_bench.

I write about #ThreatHunting #WindowsInternals #Malware #DFIR and occasionally #Python.