Chapter 6: Windows Artifact Analysis

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome to the Deep Dive, where we take the information you want to understand and really extract the insights that matter.

For you, the learner, who's keen on getting knowledge quickly and thoroughly,

you know, those aha moments without feeling totally buried, we've got a really revealing exploration today.

We definitely do.

Today, we're diving deep into, well, the methods of digital forensics specifically on a Windows computer, our source.

It's a chapter just packed with essential techniques from learned computer forensics seconded.

Exactly.

So our mission here is to basically distill the core knowledge from this chapter, giving you a clear path through how digital investigators uncover the story hidden inside a computer.

We'll look at everything from how Windows organizes, you know, your personal world to the digital footprints it leaves behind.

Think of it as your crash course into the world of digital evidence.

Perfect.

Okay, let's unpack this.

Starting with the foundation, how Windows structures your individual data.

Right, we're talking about user profiles.

So when you log into a Windows machine, the system creates this unique kind of personalized area for you.

It stores your specific files, your settings.

Now, where these live is shifted a bit over time.

Yeah, I remember that older systems like XP, WinNT, 2000, where were those again?

You'd find them tucked away in C.

Documents and settings, percents or name percent.

That was the standard path back then.

And then for the more recent ones, Vista, 7, 8, 10, it moved, right?

Correct.

It shifted over to C, users, percent, user name, percent.

So yeah, just seeing that folder structure could be like an early clue about the OS version you're dealing with.

Interesting.

Now, the chapter talks about different types of user profiles too.

It does.

What's really interesting are the different kinds.

You've got your basic local profiles.

They get created the first time you log on to a specific machine and they just live right there on that hard drive.

So any changes you make are just for you on that one computer.

Exactly.

Then you've got roaming profiles.

Sometimes you see these more in like big organizations, enterprise environment.

Ah, the ones that follow you around.

Precisely.

They're stored on a central network server.

So you log into different computers on the network and boom, they're your settings.

Any changes get synced back to the server when you log off.

Makes sense.

Then there are mandatory ones.

Mandatory profiles, yeah.

Yeah.

Administrators set these up for a really controlled, consistent experience.

Users can't actually save any changes they make.

Everything just snaps back to the admin settings on log off.

Kind of strict.

And the last type.

Temporary profiles.

These are basically a fallback.

If something goes wrong when loading your regular profile, maybe it's corrupted or unavailable, the system creates a temporary one just for that session.

It gets deleted as soon as you log off.

Okay.

Got it.

Now, inside each profile, you mentioned a really critical file, NTUSR .dat.

What's the deal with that one?

Ah, NTUSR .dat.

Okay.

So that file is what's called a registry hive.

Think of the whole Windows registry as this massive, hierarchical database for the entire system's configuration.

Right.

The heart and soul, as they say.

Pretty much.

And NTUSR .dat is like your personal slice of that database.

It stores all your individual preferences, your settings, everything from your desktop wallpaper to how your apps are set up.

So when you log in?

When you log in, Windows loads up that NTUSR .dat file and maps it, essentially connects it, to a specific part of the main system registry called HKE current user.

It's your personal configuration blueprint, basically active whenever you're logged in.

Your personal blueprint loaded up each time.

Makes sense.

Now, besides this registry file, what other kinds of data do we usually find in a user profile?

Well, you've got the standard folders, everyone knows, documents, music, pictures, videos.

But forensically speaking, there's a hidden folder called app data that's particularly important.

App data.

Hidden, you say.

Why is that significant?

It holds application -specific data and your profile configurations that, well, aren't really meant for users to mess with directly.

It's where programs store their working files, settings, caches, that kind of thing.

And this app data folder, it's broken down further, isn't it?

It is.

You'll find three subfolders inside.

Local, local silo, and roaming.

Okay.

Roaming first.

What goes in there?

The roaming folder is designed for data that needs to follow you around in a network setting.

Kind of like the roaming profile itself.

Think about stuff like your saved browser favorites, maybe some application settings you want consistent across machines.

Right.

So if my bookmarks sync between work and home PCs, that data might be in roaming.

Make sense?

What about local?

Local holds data that's specific to that particular computer you're using right now.

It includes things like installed program data, temporary files, application caches, stuff that doesn't need to sync.

Temporary internet files often land here.

Gotcha.

And local -o sounds even more specialized.

It is.

Local -o is typically used for data that needs, well, lower level access rights or it's linked to applications running with reduced privileges.

Often for security reasons, like sandbox browser processes might write temporary files there.

It just shows how granular Windows gets in managing user data.

Okay.

That gives us a solid handle on user profiles and where to find stuff.

Now, the chapter shifts gears to what you called the heart and soul, the Windows registry.

That sounds like a really critical area.

Well, it absolutely is.

The Windows registry is this central hierarchical database.

It stores configuration settings for pretty much everything.

Users, hardware, applications, system settings.

So for an investigator, it's gold.

It's an invaluable resource, yeah, for reconstructing what happened on a system, who did what, how things were set up.

It's like the computer's detailed memory, recording configurations and changes over time.

So where do we actually find the main parts of this registry?

Are they just one big file?

Not quite one big file.

The core parts are stored in files called hives.

Most of the critical system wide hives are located in the percent system root percent system 32 config folder.

And what are some of those key hive names?

You'll find crucial ones like SAM that manages user login info,

security, which holds security policies and potentially password data, though often encrypted,

software, which has details about installed applications and default Windows settings, and system, containing hardware and system configuration info.

Each one holds vital pieces of the puzzle.

And we already talked about NTU sir dot debt, the user specific hive within each profile.

Any other important hives we should know?

Yeah, there's also USR class dot dad.

Usually find this one inside the user's app data folder, specifically under app data, local Microsoft Windows.

This hive stores information related to user account control, UAC settings, and also GUI preferences for that user.

Another piece of that personalized experience.

It really is all interconnected then.

System settings, user settings, all in the registry.

You mentioned these hives have a structure.

They do.

A hive is organized into sub keys, which are like folders within folders.

Each sub key can contain values and each value has a specific type like text or a number and the actual data, the setting itself.

It's a tree structure, basically, keeping all that config info organized.

Looking at the raw registry, though, like in this chapter screenshot, it looks incredibly complex, like it's just a wall of text and numbers.

It can be, yeah.

Trying to read the raw registry data directly is really daunting.

That's why specialized forensic tools are absolutely essential.

Tools to parse it, make sense of it.

Exactly.

Tools like Registry Explorer let you browse through the hives and keys in a much more user friendly way.

They decode the data and present it logically.

And the chapter mentions some good open source options too.

Definitely.

Harlan Carvey's RegRipper is a classic, fantastic tool.

It runs plugins to automatically pull out specific known artifacts from registry hives.

Super efficient.

And Eric Zimmerman has developed a whole suite of amazing open source utilities for analyzing all sorts of windows artifacts, including really detailed registry parsing.

These tools are just invaluable.

Okay, great.

So with that understanding of profiles and the registry, the chapter moves into using them to figure out who is actually using the computer and what they were up to.

It starts with determining account usage.

Sounds pretty foundational.

It's absolutely fundamental,

yeah.

Pinpointing which user account did what is often one of the trickiest, but most critical, parts of an investigation.

You usually need to piece together evidence from multiple spots.

So where does the chapter start looking for this account usage info?

It begins by looking at where details about the last login time and the last password change are stored.

This helps establish activity timelines for different users.

And where do we find that specific info?

Deep in the registry again.

Deep in the registry again, yes.

Specifically within the SAMhive, the path is C window system 32 config SAMdomain's account users.

If you use a tool like Registry Explorer to browse there, you'll see folders with these long hexadecimal names.

Hex names, right.

But how do you connect those to actual user names?

Within that user's key, there's another subkey called names.

That's where you see the actual human readable user names listed.

Okay, so the names key links the user name to one of those hex folders.

Exactly.

It maps the user name, say, Che Cloudy, like in the books example, to its corresponding hex name subkey, like buys3e9 in that case.

And inside that hex key is where the detailed account data lives.

And inside that hex key, the chapter mentions F and V values.

What are those?

Those values contain a lot of the raw account data.

But again, trying to decode them manually is tough.

This is where a tool like Regripper shines.

Right.

Regripper can just pull out the useful bits.

Precisely.

It interprets that raw F and V data and spits out clear information like the account creation date, any password hint, the last successful login time, last failed login, even the total login count for that user, a really useful snapshot.

The chapter also brings up the security identifier or SID, another unique ID.

Yes.

The SID is a unique identifier.

Windows uses internally for all security principles, users, groups, computers.

It's like a digital fingerprint for security objects.

And the important part for distinguishing accounts is the last bit, the RID.

The relative identifier or RID, yeah.

That last number in the SID is often very informative.

For instance, an RID of 500 almost always means the built -in administrator account.

501 is usually the guest account.

And user -created account.

User -created accounts typically start with RIDs like 1 ,000 or 1 ,001 and increment from there.

So seeing an RID like 1 ,001 linked to jcloudy tells you it was likely an account created by an admin, not one built into Windows itself.

Okay, that's helpful.

Now, beyond the registry, the chapter points to Windows event logs as another huge source of info for account usage.

Oh, absolutely critical.

Windows keeps detailed logs of all sorts of system events that can be incredibly revealing about user logins, account changes, security issues, you name it.

And the main types are system, application, and security.

System logs track OS -level events.

Application logs track events from installed software.

And the security log is vital for monitoring things like login attempts, successful and failed account lockouts, privilege use, object access, all that security -relevant stuff.

And where do we find these logs on modern Windows systems?

Since Windows Vista, so Vista 7, 8, 10, 11, you'll find them in C, Windows System 32, wine of tea.

The log files themselves usually end with a .EVTX extension.

The chapter specifically flags Remote Desktop Protocol, RDP, access being logged in the security log.

Why is RDP so important?

Well, RDP lets someone connect and control a computer remotely.

So in cases where someone's physical location is disputed, RDP logs can be crucial evidence.

What are the key event IDs for RDP?

In the security log, you're mainly looking for event ID 4778, which indicates a session was connected or reconnected, and event ID 4779, which means an RDP section was disconnected.

The timestamps on these are key.

And for local logins, someone actually at the keyboard?

Event ID 4624 in the security log is the main one for a successful logon.

It records the date, time, the username, and importantly, the logon type.

Logon type.

What does that tell us?

It tells you how they logged in.

For example, type 2 usually means an interactive logon, someone physically present.

Type 10 is typically RDP.

There's a whole list Microsoft provides.

You can use the built -in event viewer tool in Windows to look through these logs and filter them.

Super useful.

Are there other event IDs that might signal something suspicious, like a compromise?

Definitely.

Besides successful logins, 4674, you look for failed logins.

Event ID 4625.

Lots of failures could mean a brute force attempt.

Logos are 4634 and 4647.

Event 4648 shows a logon with different credentials.

Event 4672 is important.

It signals a logon with administrative privileges.

And 4th event 20 means a new user account was created.

Any of these happening unexpectedly could be a red flag.

The chapter links to a full list, which is handy.

Okay, great.

We've covered identifying who is using the system.

The next big section dives into determining file knowledge.

This seems vital for cases involving, say, illegal images or stolen company data.

How do we figure out if a user knew about certain files?

Right.

This is about finding digital traces that suggest a user saw opened or somehow interacted with specific files.

The chapter kicks this off by talking about the thumb cache.

Thumb cache.

Like thumbnail cache.

Exactly.

It's a set of hidden database files where Windows Explorer stores thumbnail images of files, especially pictures and videos, when you browse folders in Thumbnail View.

It speeds things up so it doesn't have to regenerate them constantly.

Where does this cache live?

It's within the user's profile, typically at AppData Local Microsoft Windows Explorer.

So if we find a thumbnail of, say, a sensitive document in there, does that prove the user opened it?

Not definitively, no.

It's strong evidence the system processed the file to create the thumbnail, but it doesn't absolutely guarantee the user consciously viewed it.

Background processes can sometimes trigger thumbnail generation.

But it indicates the file was there and seen by the OS, at least.

Precisely.

And there are tools, like Thumbcache Viewer, which is open source, that let you easily look inside these thumb cache databases and see the images.

But the thumbnail files themselves have weird names, right?

Not the original file name.

How do you link them back?

Good point.

That requires another step, usually involving the Windows Search Indexing Database.

This is a file called Windows .edb, typically found in C Program Data Microsoft Search Data Applications Windows.

OK, so you need another tool for that.

Yeah, something like Ease a Database View can examine the Windows .edb file.

The process involves taking the hex name of the thumbnail, sometimes you have to reverse the byte order,

and searching for that value within specific tables inside Windows .edd tables like System Index 0A or System Index Property Store, depending on the Windows version.

And if you find a match?

If you find a match, it should give you the original file path and name associated with that thumbnail.

It's definitely a bit of digital detective work piecing those clues together.

Sounds like it.

OK, the chapter then looks at Microsoft browsers, i .e.

Edge, even File Explorer History.

How do they help with file knowledge?

Well, these browsers keep records not just of websites visited, but sometimes also of local files or network files accessed through the browser interface or File Explorer.

So browser history isn't just web history?

Not always, no, especially with older IE versions and how they integrated with the file system.

For modern IE 1011 and Edge, a key file is webcachev01 .dat.

It's another ESE database.

Like the Windows .edb search index?

Similar database format, yeah.

You can export webcachev01 .dat and use ESE Database View again.

Looking inside, particularly in the containers table, you can find records of file paths, local or remote that were viewed, along with timestamps.

Gives you a timeline of file interactions through those Microsoft tools.

Got it.

The next thing mentioned is MRUs, most recently used lists.

We see those in application menus all the time, like recent files.

Exactly.

MRUs are lists of files a user has recently opened or saved within specific applications.

They're designed for convenience, but they're also a great forensic artifact.

And where are these MRU lists usually stored?

Often within the user's NTSE or .dat registry hive.

For example, there's a key called opensavedpilledmru that tracks the last 20 or so files opened or saved using the standard Windows opensaved dialog boxes.

So it remembers what you opened even if it wasn't in a specific app's recent list.

Potentially, yeah, if the standard dialog was used.

There's also another key, nteac .software -microsoft -windows -current -version -explorer -recent -docs.

This one logs files executed open via Windows Explorer itself up to maybe 150 entries, kept chronologically.

And it breaks it down further.

Often, yes.

It can have subkeys for specific file extensions, .doc, .pds, .jpg, etc., showing recent files of that type.

And there's usually a folder subkey tracking recently opened folders, too.

And this chapter notes something about OneDrive.

Right.

Seeing entries related to OneDrive or CloudLog within these MRUs can be a strong indicator that the user was interacting with cloud storage.

Even if the original file is gone, the MRU entry might persist for a while.

So even deleting a file doesn't necessarily wipe the MRU record immediately.

Okay, what about actually deleting files?

The recycle bin?

Ah, yes.

The recycle bin.

Windows' little safety net for deleted files.

When you delete a file normally, it usually goes into this hidden folder called recycle bin at the root of each fixed drive.

Hidden, right.

And inside that.

Inside, you often find subfolders named with the SID of each user who's used that computer.

So each user has their own bin within the main bin?

Effectively, yes.

And when a file lands there, it gets renamed.

Usually starts with $3, followed by six random characters, but keeps the original extension.

At the same time, a companion file is created, starting with $1 and the same six random characters.

The die file.

What's in that?

That's the crucial metadata file.

It stores the original path and file name of the deleted file, and the exact date and time it was deleted.

Super important info.

Does this apply to folders, too?

Yep.

Deleted directories also get corresponding dollar and dollar files.

The dollar file for a directory might even retain the names of the files and subfolders who are inside it.

But what happens if the user empties the recycle bin?

Is the data gone forever?

Well, when you empty the bin, the operating system marks the space those files occupy on the disk as available for new data.

The raw file data might still be there for a while, recoverable with data carving tools, until it gets overwritten.

But the metadata, the y -file info?

That can be harder to recover, especially the link between the other file's info and the dollar file's data on NTFS volumes.

The master file table, MFT entries for those Tarta files, tend to get reused fairly quickly.

But like we said, other artifacts like MRUs might still point to the deleted file.

Right, multiple angles.

Okay, next up, shortcut files, the .nk files.

We use these all the time.

What forensic value do they hold?

LNK files are pointers, shortcuts to other files, apps, or network locations.

What's great for investigators is that even if the target file, the thing the shortcut points to, is deleted or moved, the LNK file itself often hangs around.

And it keeps info about the original.

It often does.

It can store the original files, MAC times,

modified, accessed, created, its size, the original path,

and even details about the disk volume it was on, like the volume serial number.

Wow.

And where are these typically created and stored?

They usually get created automatically when you double -click a file, or sometimes when using the file open dialog.

A common place to find them is in the user's percent, certain neighbor's percent, app data -roaming Microsoft Windows recent folder.

And there are tools for reading these.

Absolutely.

Eric Zimmerman's LECMD is a great open source tool specifically for parsing LNK files.

Commercial suites do it too, of course.

They can pull out all that embedded metadata, which can be incredibly useful evidence of file access, even for files that no longer exist.

Very powerful.

Now, something related sounding, jump lists, introduced in Windows 7.

How are they different from LNK files or the recent folder?

Jump lists are similar in purpose, providing quick access to recent or frequent items.

But they're tied to specific applications on the taskbar.

You right -click an icon, you see the jump list.

Ah, okay.

And they stick around.

Yes.

A key difference is that jump list data often persists even if a user clears their standard recent folder history, so it can be a more durable artifact.

Where do these jump lists live?

Primarily in two locations within the user's profile.

Percent ESSER profile, percent app data -roaming Microsoft Windows recent automatic destinations, and a similar path ending in custom destinations.

From automatic and custom.

Automatic ones are generated by Windows based on your usage patterns with an app.

Custom ones can be created by the application itself, maybe for specific tasks or pinned items.

And the file names look weird, like GUIDs.

They do, yeah.

They're named with these long, globally unique identifiers.

But there are known lists online that map these GODs to the applications they belong to.

So you can figure out, say, which file is the jump list for Chrome or Word.

And tools to read them.

Zimmerman again.

Yep.

Eric Zimmerman has Jump List Explorer.

It parses these files and shows you what files or items were listed, often with timestamps, and sometimes even the path they were opened from, like the desktop, or even in a cloud drive, like OneDrive.

Okay, moving on to another intriguing term.

Shellbags.

What on earth are shellbags?

Yeah, it's a funny name.

Shellbags are basically a collection of registry keys.

They primarily live in the USR class D8 Hive, which is in the user's app data local Microsoft Windows folder.

And what do they store?

They essentially remember your view settings for folders you've browsed using the Windows GUI, the shell.

Things like icon size, window position, column widths for specific folders.

View settings?

How is that useful?

Well, because they record which folders were browsed and sometimes when.

And importantly, this includes folders on network drives,

removable media like USBs, and even encrypted containers if they were mounted and browsed.

Ah, so it tracks navigation history, essentially.

Exactly.

It shows the user navigated to a particular location.

Again, Shellbag Explorer from Eric Zimmerman is a great tool here, often showing a tree view of accessed folders.

Commercial tools parse them too.

Does it show if files inside the folder were opened?

Generally no.

It's more about folder access.

But it can be crucial for refuting claims like, I never knew that folder existed, or I never accessed that network drive.

The chapter shows examples revealing access to cloud storage folders like Dropbox or Google Drive too.

And Regripper can pull this out too.

Yes, Regripper has plugins for Shellbags.

The chapter shows output displaying access dates and times, even the first time a folder like the Google Drive sync folder was accessed by that user.

Powerful for showing awareness of a location.

Ok, last one in this file knowledge section.

Prefetch files.

We hear about these speeding up app launches.

How do they help forensics?

Prefetch is a Windows performance feature.

When you run an application, Windows often creates a prefetch file with a .pf extension in the %windows % prefetch directory.

This file helps Windows load that app faster next time.

And what information is inside that .pfo?

Quite a bit, actually.

It contains the path to the application executable itself, a list of other files and DLLs the application used when it loaded, a count of how many times that application has been run, and crucially, the timestamp of the last time it was run.

So a direct record of program execution and frequency?

Exactly.

Tools like NIRSOF's Win Prefetch View, another good open source option, can part these files.

Analyzing prefetch data shows which apps were used, how often, and when last run.

This can uncover the use of portable apps, tools for accessing hidden volumes, encryption software, cloud sync clients, things that might not leave traces elsewhere.

Good point.

And you mentioned locations can change with OS updates.

Yeah, that's a constant challenge in forensics.

Microsoft might change where an artifact is stored or how it's formatted in a new Windows version or even a major update.

So continuous learning is key.

Absolutely.

OK, that was a really thorough look at file knowledge artifacts.

The chapter then shifts to identifying physical locations.

This feels really important for verifying alibis or tracking a device's movements?

It really can be.

Knowing where a computer was physically located at certain times can be critical.

The chapter mentions that case study, the employee claiming to be out of state,

but their laptop's Wi -Fi history showed local connections.

So how do we start figuring out location, time zones?

Time zones are a good starting point, yeah.

The system's configured time zone gives you a baseline for interpreting all the other time stamps you find.

And that's in the registry?

Yep, in the system hive, under current control, set control time zone information.

Tools like Regripper can pull this out easily, showing the offset from GMT, bias values, and the common name, like Pacific Standard Time.

But users can change their time zone, right?

They absolutely can.

So it's a piece of the puzzle, but you usually need more corroborating evidence for physical location.

It's not definitive proof on its own.

OK, so what else?

Network history.

Exactly.

Knowing which networks a computer connected to, especially Wi -Fi networks, can provide strong location clues.

This info lives in a few places.

Some info is in the software registry hive.

But for Wi -Fi specifically, Windows stores detailed profiles as XML documents.

You usually find these in C program data Microsoft Wens VC profiles interfaces.

Inside there are folders named with GADs, and the XML files detail the SSID, the network name, like coffee shop Wi -Fi, and the authentication type used.

So you can see the names of networks it's connected to.

Yes.

And there's more network info in the registry too, under software Microsoft Windows NT current version network list profiles.

Regripper can parse this to show MEC addresses of access points and the time stamp of the And you mentioned logs earlier.

Is there a specific log for Wi -Fi?

There is.

Windows keeps a dedicated event log for wireless activity.

What kind of events are logged there?

Really useful stuff.

Event ID 8001 shows a successful connection to a specific SSID.

8 .0 .3 shows a disconnection, 11 ,000 shows the association process, 8 ,002 logs failed connection attempts.

There are others too, like 6100 in the system log for diagnostics.

And if you know where that SSID, that Wi -Fi network, is physically located.

Then you can potentially place the computer at that location during the times it was connected based on the time stamps in the log.

Very powerful for location tracking.

Makes total sense.

Okay, moving on from location, the chapter discusses exploring program execution.

We touched on this with Prefesh and MRUs, but what other artifacts specifically track Right, there's definitely overlap, but two key artifacts highlighted specifically for program execution are UserAssist and the ShimCache.

We won't rehash Prefetch or Jumplists here.

Okay, UserAssist first.

Where is it and what does it track?

UserAssist is a set of registry keys found in the user's NTUSE or .d8 Hive under software Microsoft Windows Current Version Explorer UserAssist.

It mainly tracks applications launched via the GUI things you clicked on.

And the data is encoded somehow.

Yeah, it uses ROT13 encoding, a simple substitution cipher.

But tools like ReGripper decode it automatically.

It shows the path of the executable, the last time it was run, and usually a count of how many times it's been launched.

Another good record of user activity.

Okay.

And the ShimCache, also called AppCompatCache.

Exactly.

The ShimCache, or Application Compatibility Cache, is located in the system registry Hive.

System Current Control Session Manager AppCompatCache.

Its main job is actually related to application compatibility, helping older programs run.

But it logs execution info, too.

It logs information that implies execution.

It records the file path of executables, the file's last modification time from its standard information attribute, and the time the ShimCache entry itself was last updated.

So not a direct execution timestamp like UserAssist.

Not usually a precise execution time, no.

But it provides supporting evidence that a particular program existed on the system and was recognized by the compatibility layer, likely because it was executed or considered for execution.

ReGripper parses this, too.

It's another piece that helps build the overall picture.

Got it.

Okay.

The final category the chapter covers is understanding USB -atch devices.

USB drives are everywhere, used for everything, and sometimes nefarious things.

Absolutely.

Data theft via USB, malware delivery, identifying USB device usage is often critical in investigations.

So where does Windows track USB connections?

Registry again?

Primarily the registry, yes.

Several keys are important here.

First, system current control set, you know, use D.

This key essentially lists USB devices the system has detected or enumerated.

It can show vendor and product IDs, vidP ID, maybe a serial number, and the last right time to that device's registry key.

But maybe not the real serial number.

Sometimes the serial number there isn't the physical one etched on the device.

For potentially more reliable serial numbers, especially for storage devices, you look at system current control set, you know, USB store.

This key often provides the commercial name, like SanDiskCruiser, and a more accurate device serial number.

USB, a store for storage devices.

Yeah.

Okay.

And how does Windows know what drive letter was assigned?

That mapping happens in the system -mounted device's key.

It links the device's serial numbers, often the ones found in USB store, to the drive letters, like E, F, etc., that were assigned when the device was plugged in.

So SystemHive tells us what devices were connected and when, but how do we know which user plugged them in?

Ah, that's the crucial link back to the user.

You often need to correlate the device information from the SystemHive with the specific user's NTU sear dot dot hive.

How does that work?

Forentic tools like RigRipper can analyze the user's NTU sear dot deadat dot, specifically looking under the Software Microsoft Windows current version explorer mount points 2 key.

This key often contains entries that correspond to the GI deeds, or serial numbers, of mounted devices, including USB drives.

And it shows when that user used the device.

Exactly.

It typically records when devices were last mounted or accessed by that specific user account.

So it directly links the user profile to the usage of that particular USB device.

That's really clever, tying it all together.

Okay, so that covers USBs.

The chapter then wraps up with a summary, right?

Pulling all these artifact types together.

It does, yeah.

It basically recaps how understanding all these different pieces, user profiles, the logs,

file knowledge artifacts,

thumb cache, MRUs, LNKs, jump lists, recycle bin, shell bags, prefetch, location data, program execution traces, user assist, shim cache, and USB history allows investigators to build a comprehensive picture.

A narrative of what happened on the system.

Exactly.

A narrative supported by digital evidence, often revealing user actions, awareness, and timelines.

And it stresses again how vital both commercial and open source forensic tools are for actually digging through all this data efficiently.

This deep dive has definitely given us a thorough tour of that chapter on Windows Artifact Analysis.

We've gone from the basics of user profiles in the registry all the way through tracking accounts, files, locations, programs, and devices.

A really comprehensive overview.

And for those who want to go hands -on, the chapter mentions exercises, tools like autopsy, and further reading, which are great next steps.

For you, the learner, hopefully this gives you that solid foundation in understanding the key digital breadcrumbs left behind on a Windows system.

It really is fascinating how much our everyday computer use gets recorded.

It really is.

The mundane actions leave such a detailed trail.

Absolutely.

So maybe think about which of these artifacts, or perhaps which forensic tool we mentioned, caught your interest the most.

That might be your next area to explore.

Thanks for joining us on this deep dive into Windows forensics.