StartupInfo: Autoruns served up on a plate

Hadar Yudovich
DFIR Dudes
Published in
4 min readJul 19, 2018

Two weeks ago I found a useful piece of forensic evidence on startup processes. The evidence is an XML formatted file called StartupInfo.xml, located under %WINDIR%\System32\WDI\LogFiles\StartupInfo.

As usual, before I started parsing the file or dig further into it, I thought it would be a good idea to first see if anyone has covered this before. Unfortunately I couldn’t find anything online.

It’s funny how these things are discovered sometimes. While I was going over the last SANS DFIR Summit’s slides, I saw @nicoleibrahim’s great work about Windows Events Trace Logs (ETLs). In her talk, she discussed different ETLs and one of them was the WdiContextLog.etl, which is also located in %WINDIR%\System32\WDI\LogFiles. As always, when I read about evidence, I compare the information to the data on my own system to see if maybe there’s new stuff to find out about. That’s when I saw the StartupInfo directory which seemed interesting and contained these XML files.

When I find new stuff, my go-to-guy is my friend Martin (@MartinKorman), so I asked him if he would like to write about it together. These are our findings.

What is this file?

The files are located under %WINDIR%\System32\WDI\LogFiles\StartupInfo, in the following format: <USER_SID>/StartupInfo<NUMBER>.xml. The SID part is derived from the user account that logged into the system and the NUMBER part is an incremental count of these files, where 5 is the maximum number. Once there are 5 StartupInfo files and a logon occurs, the log rotates and overwrites the least updated file.

The file is in XML format and contains useful information about a list of processes which were executed on the first 90 seconds since the user has logged in. The information includes the following attributes:

  • Process Information — Name, PID, Start Time, Command Line, Disk Usage, CPU Usage.
  • Parent Process Information — Parent PID, Parent Start Time, Parent Process Name.

The xml file is written by a svchost process (that has a loaded DLL of Microsoft Performance Diagnostics named diagperf.dll).

We confirmed this by taking a quick look of the DLL in IDA:

Here we see the code in diagperf.dll that creates the folder containing the files:

These are the some relevant strings inside the DLL:

Relevant Operating Systems

According to our tests, these files do not exist on Windows Server, and were only introduced starting Windows 8.

Is it a valuable forensic artifact ?

There are already many pieces of forensic evidence that include information about startup processes or process creation. Is this evidence of any value?

Here are a few ways in which this can be used during an incident response, forensic investigation or for detection in general:

  1. Like any artifact that is analyzed at scale, a statistical analysis on the process names and command lines can be performed to find the outliers.
  2. If a malware removes its persistence on boot (and writes it back during shutdown), for example like some variants of Dridex did, you would be able to find it in this artifact.
  3. Helps mapping user to process — determines under which user’s privileges the process was launched.
  4. Determines if the process wrote any files to disk (based on the Disk Usage attribute).
  5. Many more :)

Parsing

The evidence is an XML file, encoded in utf-16. It can be parsed easily with lxml. The most effective way to analyze this data in scale would be inside a pandas data frame, using jupyter lab (http://jupyterlab.readthedocs.io/en/stable/).

You can find the code here.

Below you can find an example of a parsed file:

Summary

This is a cool new piece of evidence that can be used in DFIR. Instead of going over process creation events or correlating different process startup locations, you can inspect this file and get a good grasp of which processes were executed upon the system’s boot.

There are additional things or paths to investigate about this evidence, so let us know if you find anything cool about it that we might have missed :)

Hadar & Martin

--

--