1234n6

Some testing of SRUM on Windows Server 2019

Adam Harrison -

This post is a response to David Cowen’s ‘Sunday Funday' challenge as detailed over at ‘Hacking Exposed - Computer Forensics Blog’.

The question posed by David was as follows:

Server 2019 got SRUM, what if any differences are there between SRUM on Windows 10 and SRUM on Server 2019?

To be up front, don't read this post looking for amazing details on the technical differences in the implementation of SRUM between Windows 10 and Server 2019, my conclusion is going to disappoint.

Methodology

My approach in answering this question was going to be to export the SRUMDB from a Windows 10 system and a Windows Server 2019 system and then to document the schema within the database and then to explore any differences.

The SRUM database (SRUDB.dat) is commonly located at 'C:\WINDOWS\system32\SRU\SRUDB.dat' within systems where SRUM is available. It is an Extensible Storage Engine (ESE) Database and as such can be parsed with various tools.

I chose to use NirSoft ESEDatabaseView as an easy way to parse out the contents of each table into a csv so the headings and contained data can be reviewed. There are various great tools designed to parse the SRUDB however in this case I was specifically looking for potential new tables or fields which these may miss.

The approach employed was to extract the SRUDB from the target system to another location then to use the below command:

ESEDatabaseView.exe /table C:\Users\[removed]\Desktop\SRUM\SRUDB.dat * /scomma "C:\Users\[removed]\Desktop\SRUM\*.csv"

This command would parse the content of every table (due to the specified name of *) and then parse the content into individual CSVs named after each table. The results are detailed in the sections that follow.

Windows 10 SRUDB Schema

The Windows 10 system analysed is a heavy use system which has been installed for some time, OS details as below:

When the SRUDB.dat file was reviewed in ESEDatabaseView, the table list looked as follows:

The tables were as follows:

  • {5C8CF1C7-7257-4F13-B223-970EF5939312}
  • {7ACBBAA3-D029-4BE4-9A7A-0885927F1D8F}
  • {973F5D5C-1D90-4944-BE8E-24B94231A174}
  • {D10CA2FE-6FCF-4F6D-848E-B2E99266FA86}
  • {D10CA2FE-6FCF-4F6D-848E-B2E99266FA89}
  • {DD6636C4-8929-4683-974E-22C046A43763}
  • {FEE4E14F-02A9-4550-B5CE-5FA2DA202E37}
  • {FEE4E14F-02A9-4550-B5CE-5FA2DA202E37}LT
  • MSysLocales
  • MSysObjects
  • MSysObjectsShadow
  • MSysObjids
  • SruDbCheckpointTable
  • SruDbIdMapTable

I then proceeded to make a really pretty table which contains the field names associated with each of the fields in each table. It looked a little something like this:

Which I think we can all agree presents very well as a table within a blog. Ultimately the content isn't that interesting, but any difference to what we find in Server 2019 will be.

Windows Server 2019 SRUDB Schema

The Windows Server 2019 system analysed is a fresh install of a virtual machine using the evaluation ISO. Following the issues during the rollout of 2019 and associated versions of Windows 10, as detailed here, Microsoft pulled the download links so I had to hunt and locate this one.

OS details as below:

This system was allowed to run for a short while, various applications were executed and it was rebooted/shutdown and powered on a number of times.

Despite all this, when I went to go and extract the SRUDB.dat I had an interesting finding...

So at this moment in time, the answer I submit to David's question is that there are some significant differences between SRUM on Windows 10 and SRUM on Server 2019, most notably that in my testing there is no SRUM in Windows Server 2019.

Unfortunately, having watched David's recent Forensic Lunch Test Kitchen I know full well that in his testing, and recorded on video for all to see is a Windows Server 2019 install with SRUM, all that remains now is to try and figure out what if any differences there are between our test environments and whether they cause this anomalous behavior.

UPDATED 2019-01-11

This behavious has now been confirmed by a colleague who was also looking into it, the ISO name and MD5 we were using:

17763.1.180914-1434.rs5_release_SERVER_EVAL_X64FRE_EN-US.
ISO - E62A59B24BD6534BBE0C516F0731E634

17763.1.180914-1434.rs5_release_SERVERESSENTIALS_OEM_X64F
RE_en-us.iso - B0F033EA706D1606404FF43DAD13D398

Notably, looking to the registry in these same systems we find the normal SRUM keys however they are not populated with RecordSets:

Above we see that the SRUM key exists but where we would expect to see RecordSets with the temporary data, there are none. This location normally contains temporary data before it is pushed to the SRUDB.dat.