Windows forensics: open research topics

Here is a list of open research topics in Windows forensics. All topics in this list are relevant to my research. Feel free to pick one for your research. Originally, I wrote this list for myself, but it’s better to make it public.

More topics and ideas (in other areas too) can be found here and here.


The “Syscache.hve” file can be found in the “System Volume Information” directory of a system volume (Windows 7 and Windows Server 2008 R2).

Currently, there are many unanswered questions, for example:

  • Was the Syscache hive the actual predecessor of the Amcache hive? Was it used to store telemetry data about applications long before the Windows 10 release (known for its privacy issues)? If yes, what component was responsible for sending this data to Microsoft?
  • It was observed that many up-to-date Windows 7 installations don’t update the Syscache hive with new entries. Perhaps, the Syscache hive is “disabled” (or its updates are delayed) after the Amcache has been backported. Is this true?
  • What applications aren’t recorded in the Syscache hive?

Additional information:


This database can be found in the following registry key: “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\CIT\System” (Windows 7 and Windows 8.1). (Note that this key can’t be opened on a live system due to an extremely restrictive access control configuration.)

The CIT database is used to record file system paths to executables and other data.

Currently, there are many unanswered questions, for example:

  • What is the format of entries found in the CIT database? Unicode file system paths can be seen there (after LZNT1-compressed data is extracted), but there is unknown data as well. Is there any data about user input?
  • Is this database really gone in Windows 10? Some CIT-related code is still there.
  • What file system paths aren’t recorded in the CIT database?

Additional information:


Although the on-disk format was fully reverse engineered, there is one unanswered question:

  • What is the purpose of access bits? It seems that access bits are only set for a key, but never read. (Update: the answer is in Windows Internals, 7th Edition, Part 2.)

Additional information:

Other research topics include:

  • Can we fool EDR/IR/AV tools by moving “usual” registry hives (like SYSTEM and SOFTWARE) to files outside of the “Windows\System32\config” directory (until a reboot)? See the RegReplaceKey function.
  • Can we use access bits to get more information from high-level artifacts (like Amcache entries)?


  • The NTFS driver can store two different last access timestamps for a single file: one in the $STANDARD_INFORMATION attribute of a file record and another one in the $FILE_NAME attribute of an index record (not to be confused with the $FILE_NAME attribute of a file record). These two timestamps are synchronized (update: not always, but other changes are still introduced) when a volume is opened directly (for example, when reading a file directly from a volume using a third-party NTFS parser like The Sleuth Kit). Is there a way (the BitLocker-friendly one) to read a volume directly without touching its timestamps?
  • Are there any other files which contain unallocated data marked as allocated? Currently, only one file is known (to me): “$Extend\$RmMetadata\$Repair” (see the “$Corrupt” and “$Verify” streams).
  • What is the format of the NTFS corruption log ($Repair:$Corrupt” and “$Repair:$Verify”)? Why does it store call stacks in corruption entries? Are call stacks used as telemetry data?

Additional information:

Other research topics include:

  • It seems that the NTFS driver (starting from Windows 2000) includes additional protection against subsector torn writes (see the 0x11477982 magic value). How common are such torn writes? Do DFIR tools tolerate corrupt $MFT data after common types of torn writes? It seems that at least The Sleuth Kit throws data away if there is a mismatch between update sequence numbers for the unallocated (free) part of a file record segment (while the allocated part is valid: for example, the allocated part fits the first sector and it’s valid, while the second sector is corrupt).
  • Extending file system timelines with timestamps from hibernation files. Note that there are two in-memory last access timestamps (for the $STANDARD_INFORMATION attribute); and no debug symbols for a related structure (in the “ntfs.sys” file).


  • Sometimes files in volume shadow copies contain invalid data. Can we reproduce this issue during an experiment (without exploiting the dual-boot scenario involving an operating system without the VSC support)? Why does this happen to volume shadow copies? (Update.)

Additional information:

Programming topics

  • Write a set of tools to find new artifacts of execution and artifacts of executables present in a system (Windows): run an executable (in multiple ways), then search for its file system path (or its SHA-1 hash, NTFS reference number, etc.) in all files and registry hives.
  • Write a tool to detect uninitialized kernel memory leaks to a disk: patch the ExAllocatePoolWithTag function to initialize memory with a specific pattern, then search for that pattern on a disk. Repeat with various third-party kernel drivers loaded.
  • Write a tool to process a crash dump and extract: a call stack specific to a failed MS17-010 exploitation attempt (when an unsupported vulnerable operating system is crashing or when a PatchGuard check failure is triggered) and network packets which contain signs (and a source IP address) of that exploitation attempt (network packets carving). Later, this tool can be extended to support new exploits.

One thought on “Windows forensics: open research topics

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s