1234n6

A little play with the Syscache hive

Adam Harrison -

UPDATED 2019-01-04

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:

What processes update the Syscache.hve file on Windows Server 2008 R2?
There are some significant caveats to this post:

  1. I started looking on Thursday evening so the research is rushed and unverified.
  2. December was a manic month, followed by family focused down time during the holidays. Screen time was minimised and therefore, despite Maxim Suhanov writing up what appears to be a great post, and David dealing with Syscache.hve in a number of test kitchens and posts, I haven't actually read up on the prior work.
  3. I'm also about 90% sure I misinterpreted the question...

What process(es) update the Syscache.hve file?

In my initial read of David's question I thought he was asking for the specific mechanism/processes which are responsible for updating the Syscache.hve file directly.

In search of this answer I installed a fresh copy of Windows Server 2008 R2 into a VM and attempted to use Process Explorer, Hacker and Monitor to see what was touching Syscache.hve. I proceeded to run a few executables in an effort to identify what was updating the Syscache.hve. This spelunking didn't immediately provide the answers I hoped for however and I'm not sure why.

I then proceeded to pull a copy of the hive and review it's content with a view to finding relevant key paths and names to search within the above tools. This still didn't provide the answers I was looking for.

<2019-01-04 EDIT>

Following my later research and an awesome additional post from Maxim here. I realised the reason I wasn't seeing what I expected in Process Monitor was that I was running executables which were not causing the the syscache.hve to be updated.

Furthermore I didn't have an understanding of how the hive was mounted so what I needed to look for in the path. Per Maxim's post the filter string of '\REGISTRY\A' would be what is required, but I'm not sure I actually had any events as other search strings I used should have been fruitful.

In any even the screenshot below shows the result of running .bat and .cmd files from the desktop in subsequent testing:

This evidences the fact that the svchost.exe process is responsible for the actions performed against the syscache.hve.

However this approach initially failed me for the reasons outlined above and as such I moved on to some alternative testing methods, evidently too hastily but the results are documented below.

</2019-01-04 EDIT>

I proceeded to grab a RAM dump and to see where references to the paths and 'Syscache.hve' appear, to try and tie this to the address space of specific processes. The process followed was to take the memory dump, run strings across it with the -o and -nobanner switches to output the offset of each hit and prevent a banner from being printed and output this to a file, as below:

strings64.exe -nobanner -o C:\Users\[removed]\Desktop\memdump.mem >> stringsout.txt

The output of this could then be fed into volatility's 'strings' module to produce a listing of all strings and paired with their associated corresponding process and virtual addresses. An alternative approach would be to reduce your list of relevant strings before having volatility do the leg work but in this case I wasn't sure what I was looking for so I went the long way round.

I then proceeded to grep the resultant file for terms associated with the hive in question, one notable example being as below:

grep -i syscache stringsout.txt

This resulted with plenty of false positives due to my previous spelunking however it notably identified the presence of multiple relevant strings within a discache.sys.

At this point I had also asked some fellow forensicator friends for suggestions and the venerable Charlotte Hammond (@gh0stp0p) had an active case indexed and was able to run a quick search for some hints. She identified that the string 'syscache' appeared within discache.sys and aeevts.dll.mui on the system she was looking at. She then proceeded to analyse the discache.sys binary and confirmed it was littered with references to the structures associated with the hive in question.

It was about now that I got around to reading Maxim Suhanov's post and found that this wasn't news at all, he had already identified the same. In his words:

This library is pushing collected data to the “discache.sys” driver using the NtSetInformationFile() routine (the FileInformationClass argument is set to 52, which means “FileAttributeCacheInformation” in Windows 7).

The driver receives a file handle and two strings (named “AeFileID” and “AeProgramID”). The “AeFileID” string contains an SHA-1 hash value for a file in question. Then, this data (along with some additional metadata populated by the driver) is written to the “Syscache.hve” hive located in the “System Volume Information” directory.

By now I was pretty confident I had misread the question but thought that it would be worth documenting the approach I used and similar results as those of Maxim.

Execution of what types of processes cause the Syscache.hve file to be updated?

In an effort to identify what processes did or did not cause the Syscache.hve file to be updated I used Dave's summary associated with each of his relevant Test Kitchen episodes as a starting point, specifically these were:

Win 7

  • Programs executed from the Desktop whether from the command line or GUI were not being inserted into the Syscache.hve
  • Programs executed from a temp directory made on the Desktop were being recorded in the Syscache.hve
  • The syscache hive seems to record atleast exe, dll, bat and cmd files executed
  • There are some sysinternals programs that are not being captured at all, these may not need any shiming

Server 2008 R2

  • The syscache hive on server 2008 r2 includes executions from the Desktop, unlike Windows 7
  • The syscache hive on server 2008 r2 does not appear to be catching bat files like Windows 7 but does catch and executables the bat file calls

Based upon this I set about to test whether GUI and CLi execution of .exe, .bat, .cmd and dlls located in the root of C:, the desktop or within a sub directory of the desktop would cause the Syscache hive to be updated.

By my maths this was 24 distinct tests and noting that I am lazy efficient, I chose to rely upon whether the modified time of the hive changed between tests and whether that change was consistent with the time of actions which had been performed. This is hardly the most scientific proof however in my testing on a fresh install where I avoided making any unnecessary process execution I did not see the hive change outside of my tests.

The procedure was inspired by David's common approach of using TSK on a local system during testing. First I navigated to the directory where I had the TSK binaries:

cd C:\Users\[removed]\Desktop\sleuthkit-4.6.4-win32\bin

I then used a series of fls commands to identify the ID of the Syscache.hve:

fls \\.\c:

This provides me a file listing of the root of c:, where we can see the SVI folder is 59600.

fls \\.\c: 59600

This provides me a file listing of the SVI folder:

This confirmed that the ID I was interested in was 59649 and I could use the following command to provide the output as below:

istat \\.\c: 59649

I would then perform each of the tests and use this same istat command to check whether the File Modified timestamp had changed. The results of this testing were more than a little surpirsing as compared to the Test Kitchen results and are outlined in the following table:

High level observations:

  • At no point in my testing did my deliberate running of an executable (either from the command line or GUI) cause the syscache.hve to be modified. This was clearly contrary to the behavior evidenced in the Test Kitchen videos but exporting the syscache.hve and reviewing the data inside appeared to corroborate this observation (which was initially based upon modified time of the hive).
  • GUI execution of a batch file from the desktop causes the syscache.hve to be modified
  • GUI execution of the same batch file from the desktop does not cause the syscache.hve to be modified
  • GUI execution of the same batch file from the desktop but modified causes the syscache.hve to be modified
  • GUI execution of the same batch file from the desktop but with a modified name causes the syscache.hve to be modified
  • CLi execution of another batch file from the desktop did not cause the syscache.hve to be modified.
  • My approach for running dlls wasn't suitable so I need to rethink this...

These are certainly not definitive results and the majority of tests were only performed once and will need corroboration. It certainly indicates that there may be more variables at play, either an error in testing (on my part) or my precise version of Windows being different and this being significant.

For information the version used was the Windows Server 2008 R2 Evaluation with no further updates installed and the version specifics were as follows: