The CIT database and the Syscache hive

The purpose of this post is to record the recent findings related to artifacts of execution and artifacts of executables present in a system. No major details beyond what was posted on Twitter.

David Cowen began his public testing of Amcache artifacts found in Windows 10 operating systems in Forensic Lunch Test Kitchen 11/16/18 (be sure to watch newer videos on this topic).

During these tests, it was found that the Amcache hive may have artifacts for executables that weren’t executed at all. There were other interesting findings outlined in the videos, but I will not focus on them now.

Also, David posted a Sunday Funday challenge about the Amcache hive in Windows 7. The challenge is:

On a Windows 7 system how long does it take for a new gui executable to appear in the Amcache. What can you do if anything to force the executable to appear in the amcache hive.

So, I decided to participate. The following results apply to Windows 7 only.

I found that executed programs don’t immediately appear in the Amcache hive. In my first test, I had to wait for several hours before the Amcache hive was updated. Finally, I confirmed that executables are recorded in the Amcache hive when the “Microsoft Compatibility Appraiser” task gets executed, which is scheduled to start at 03:00 AM every day (this time is approximate, the task can also start after the boot if the scheduled execution was missed because the computer was powered off).

Some executables that weren’t executed are recorded in the Amcache hive by that task too, while executables that were executed and then deleted aren’t recorded.

It was found that the telemetry collection process, which is responsible for populating Amcache entries, is scanning common folders for standalone executables, including those pointed by LNK files. These folders include: a public Desktop folder and a Desktop folder for a user, a common Start Menu folder and a Start Menu folder for a user, Program Files folders.

Also, the telemetry collection process targets programs listed in “Uninstall” keys (HKLM and HKU), Store and App-V packages installed, Steam applications installed, as well as applications listed in the CIT database.

An executable file placed in an uncommon folder (e.g., “C:\1\2\”) isn’t recorded in the Amcache hive. However, if that executable is executed, it will be recorded in the Amcache hive by the task mentioned above.

It was observed that placing two executables in an uncommon folder and then executing one of them will not record another executable in the Amcache hive (after the task is launched manually).

So, there should be something that records executed executables. And this is the CIT database (probably, “CIT” stands for “Customer Interaction Tracker”)!

This database is stored as values of this registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\CIT\System

(In a live registry, values of this key can’t be accessed even by an administrator.)

Value data (of each value in the key) starts with two 32-bit integers. These integers contain the size of compressed CIT data plus 8 bytes and the size of uncompressed CIT data respectively. The compressed data starts at the offset 8 bytes. The compression algorithm is LZNT1.

The structure of uncompressed CIT data is unknown. But this data contains UTF-16LE strings pointing to executable files.

Here are some strings extracted using the “strings -e l <file>” command:

\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\NOTEPAD++\NOTEPAD++.EXE
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\MMC.EXE
"C:\WINDOWS\SYSTEM32\MMC.EXE" "C:\WINDOWS\SYSTEM32\TASKSCHD.MSC" /S
\DEVICE\HARDDISKVOLUME2\1\2\11124.EXE
\DEVICE\HARDDISKVOLUME2\1\2\11125.EXE
\DEVICE\HARDDISKVOLUME2\1\2\H22.EXE
\DEVICE\HARDDISKVOLUME2\1\2\H11.EXE
\DEVICE\HARDDISKVOLUME2\USERS\USER\DESKTOP\111AA.EXE
\DEVICE\HARDDISKVOLUME2\1\2\222BB.EXE
\DEVICE\HARDDISKVOLUME2\USERS\USER\DESKTOP\909090.EXE
\DEVICE\HARDDISKVOLUME2\USERS\USER\DESKTOP\909091.EXE
\DEVICE\HARDDISKVOLUME2\1\2\23232323232.EXE
\DEVICE\HARDDISKVOLUME2\WINDOWS\REGEDIT.EXE
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\DLLHOST.EXE
C:\WINDOWS\SYSTEM32\DLLHOST.EXE /PROCESSID:{3AD05575-8857-4850-9277-11B85BDB8E09}
\DEVICE\HARDDISKVOLUME2\1\2\33334.EXE
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\MMC.EXE
"C:\WINDOWS\SYSTEM32\MMC.EXE" "C:\WINDOWS\SYSTEM32\PERFMON.MSC" /S

Thus, we have another source of artifacts related to execution of files. Here is a script to extract CIT data from a registry hive.

Next, I decided to take a look at the “RecentFileCache.bcf” file. This file is written by the “aelupsvc.dll” library (“Application Experience Service”). Also, 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.

An example of an entry written to the “Syscache.hve” hive is below:

Such an entry contains the “AeFileID” string stored as a binary value with the same name. Data of this value contains an SHA-1 hash value (stored as a UTF-16LE string) for a file recorded.

A recorded file is referenced by the “_FileId_” integer stored as a value with this name. This integer points to a file record in the Master File Table (MFT), see the screenshot below.