Prepopulated artifacts

Have you ever encountered on-disk artifacts originating from another system?

Typically, this is something you see when a custom operating system image had been deployed to multiple computers by IT staff (on-disk artifacts appeared before the image is captured become a part of that image).

But there are some minor artifacts existing in installation images coming from Microsoft!

It’s known that during the Windows installation process, many files (including executables and data files) are extracted from an installation image (which is the “\sources\install.wim” file within an ISO image) to a target volume. Some registry hives with prepopulated keys and values are among those files.

During the reverse engineering of the Windows registry file format, I found that many standard registry hives (like SYSTEM and SOFTWARE) include misleading key node flags.

For example, in Windows XP and Windows Server 2003, all keys created by 32-bit programs running under the Wow64 subsystem receive the 32-bit flag (which isn’t exposed by many DFIR tools). This flag was moved to another location within a structure describing a registry key (it’s called a key node) in Windows Vista. And in Windows 7, this flag became unused (thus, deprecated).

However, many key nodes found in registry hives from a Windows 7 installation have this flag set! Moreover, the flag is set in its old location (like in Windows XP, but not in Windows Vista).

Here is my explanation from the format specification (which was linked above):

A possible explanation for this oddity is that initial primary files were generated on Windows XP or Windows Server 2003 using the Wow64 subsystem […]

While this explanation sounds obvious, it took me more than a month to exclude other explanations possible (like the same bit being reused for another purpose, for a different flag).

Okay, this is Windows 7. What about Windows 10?

Take a look at these bytes:

This is a base block (or a file header) from a registry hive. Do you see anything suspicious?

Here is the same hive from a Windows 8.1 installation:

Note the “OfRg” string at the offset 0xB0, which is absent in the Windows 8.1 hive. This is a toolmark coming from the offreg library and it’s present in the original hive file from the Windows 10 installation image. So, someone used that library to edit the hive before putting it into the WIM image! Since the hive from the WIM image contains deleted data and transaction log files with valid log entries and matching sequence numbers, the offreg library wasn’t the last tool used against the hive before packing it into the WIM image.

Let’s take an installation image (“Win10_1909_English_x64.iso“), extract the prepopulated SYSTEM and SOFTWARE hives from it, install the operating system from that image into a virtual machine, and extract the installed instances of the same hives (right after the installation is finished). Then extract possible timestamps stored in key names & value names & value data using the registry-miner tool. Finally, let’s focus on timestamps that have the same “key + value” path and the same value data in the prepopulated and fresh-installed instances of the hives.

This gives us a bunch of timestamps, some of them are stored in keys which were modified during or right after the installation process (according to the last written timestamps of those keys) but have the same value (e.g., the same integer in value data) as in the WIM image.

For example, a key from the WIM image:

Key path: Microsoft\Windows\CurrentVersion\SideBySide
Last written timestamp (UTC): 2019-10-07 03:04:11.848690
Access bits: 1
Owner SID: S-1-5-32-544

Value name: MaintenanceFlags
Value type: REG_DWORD
Data size: 4
Data (decoded):
2147483655

Value name: PublisherPolicyChangeTime
Value type: REG_QWORD
Data size: 8
Data (decoded):
132148908626149594

Value name: LastSuccessfullScavenge
Value type: REG_QWORD
Data size: 8
Data (decoded):
132148910518486891

Value name: LastScavengeCookie
Value type: REG_QWORD
Data size: 8
Data (decoded):
132148908626149594

Value name: LastScavengeFlags
Value type: REG_DWORD
Data size: 4
Data (decoded):
103

---

The same key from the fresh installation:

Key path: Microsoft\Windows\CurrentVersion\SideBySide
Last written timestamp (UTC): 2020-05-03 13:02:00.403844
Access bits: 3
Owner SID: S-1-5-32-544

Value name: MaintenanceFlags
Value type: REG_DWORD
Data size: 4
Data (decoded):
0

Value name: PublisherPolicyChangeTime
Value type: REG_QWORD
Data size: 8
Data (decoded):
132329845199047741

Value name: LastSuccessfullScavenge
Value type: REG_QWORD
Data size: 8
Data (decoded):
132148910518486891

Value name: LastScavengingStarvationReport
Value type: REG_QWORD
Data size: 8
Data (decoded):
132330201815801878

---

As you can see, the key got modified, but the “LastSuccessfullScavenge” value contains the same FILETIME timestamp as before (132148910518486891 = 2019-10-07 03:04:12 UTC, this is long before the installation). Without comparing each timestamp to the installation date, this could lead to a wrong conclusion about activity which didn’t really happen on this machine.

A similar test with the NTUSER.DAT hive shows that there is one “TypedURLs” entry from the WIM image: “http://go.microsoft.com/fwlink/p/?LinkId=255141“. After the installation, this entry is stored in the same key but with an updated last written timestamp and with a corresponding “TypedURLsTime” entry set to zero.

This issue is also documented here:

Upon review of the NTUSER.DAT hive immediately after the first login (before Internet Explorer was ever opened), I observed a single value named “url1” in the TypedURLs subkey with the data being “http://go.microsoft.com/fwlink/?LinkId=69157”. This existence of this value appears to be consistent with the behavior in older versions of Windows.

Furthermore, in previous versions of Windows, prepopulated registry hives could contain uninitialized memory in unused/unfilled portions of a base block. Here is an example of the SOFTWARE hive from a WIM image of Windows Vista:

Based on how uninitialized data is written to such areas, I suppose these are random memory chunks from a machine involved in the development process.

---

Usually, such prepopulated artifacts don’t cause any trouble during forensic investigations. But they can mislead us during reverse engineering.