• A brief introduction
• What are artefacts really?
• An example: Prefetch
• Another example: “Shellbags”
• How do we discover artefacts?
• D3DS Cache Files
• Our first test
• Another test, this time discovering our D3DS artefact
• Is this only for local activity?
• Testing on a case
• What am I saying?
• So what should we be doing?

A brief introduction

In this article I’m going to talk about how I became aware of D3DS cache files. As DFIR investigators we’ll explore briefly

• What they are
• Where to find them
• What they can (and can’t) tell us about program execution
• How to parse them
• How to construct a Velociraptor artefact to do this en-masse across an estate

If you want to jump straight into the artefact, you can scroll past all the rest . But this is not an article about a new cool new artefact, or how D3DS cache files are super useful and the best thing since Prefetch files (they’re not).

This is an article about what artefacts really are, where they come from, and why streamlining the Windows triaging process through tools like KAPE and Velociraptor sometimes risks encouraging us to be complacent when it comes to information gathering.

What are artefacts really?

Every now and then I decide to refresh my memory of basic Windows triage artefacts and their various nuances, for the sake of staying sharp.

Windows triaging has always been a fairly unchanging process:

• Collect Windows triage artefacts
• Parse Windows triage artefacts
• Construct timeline
• Review timeline

It’s a process as old as time and even across Windows XP, Visa, 7, 8, 8.1, 10, 11, the list of artefacts has barely changed. Prefetch, Amcache, Shimcache (kind of), MFT, UsrClass, yada yada. We’ve got new ones like the PCA which spice things up a bit but ultimately a Windows triage bundle is a Windows triage bundle.

But what is a forensic artefact? What is an artefact of execution?

Is it a log that Microsoft put there for me to do investigations with? Well if it is then Prefetch files are some pretty ugly logs. And why would they make things like the Shimcache so misleading??? These are terrible logs!

No, forensic artefacts are simply stores of data (files, registry entries, metadata) used by the Windows operating system for day to day operations, and often intended for efficiencies, providing a better user experience, or handling compatibility problems. As a bi-product of this, they also provide indications that certain events have occurred, like footprints in the snow, or tire marks.

An example: Prefetch

Prefetch files are used to hold onto information about resources that a process loads on execution. Windows does this so that the next time it launches that process, it remembers some of the resources to load, and can do that pre-emptively.

But prefetch files are files and files have timestamps, including creation timestamps.

Process + resource list + timestamp = forensic trace of when a process launched and what resources it loaded at that time. And we call it an artefact of execution

Another example: “Shellbags”

When you’re browsing your family photos in Windows explorer, or you’re scrolling through your report documents trying to figure out whether the latest version is “v2_final(2)” or “v2_updated_USETHIS”, you may want to adjust the size of the icons, the layout of the file list, or various visual elements of the screen. When you go back to that folder again, you’ll find that everything is arranged just as you left it. That is because Windows stores those settings you changed in registry entries, and reads them every time you open that folder again.

But when registry keys are created or changed, “LastWrite” timestamps are recorded. And these keys are getting changed as users browse their files and folders in explorer. Once again…

File and folder access + Timestamps = a crude record of what folders and files were browsed to and when. And we call it a file folder access artefact

This is how most forensic artefacts we use work. To increase the speed, compatibility, or user experience of processes, Windows stores data. And that data, especially when it comes with a timestamp, can be used by investigators to piece together activity on a system. In DFIR, this allows us to investigate threat actor behaviour.

This is important because of how limited the actual Windows event logs are out the box, having never been intended for the kinds of forensic investigation required in the modern day.

How do we discover artefacts?

The discovery of most Windows forensics to date can be broken down into three categories

Public knowledge

Not everything about Windows is a secret. Back in the Windows NT / XP days, a lot of these new components making processes faster, better, and more useable, were exciting news, and openly discussed amongst developers and power users alike. For example, check out this awesome website from 2004 http://members.rushmore.com/~jsky/id14.html where they talk about the Prefetch file like you might talk about your car’s brake pads.

A lot of what we now refer to as forensic artefacts were once discussed as exciting new features of the Windows operating system. So we knew about them all along.

Reverse engineering

Other artefacts are discovered through individuals debugging and reverse engineering the compiled Windows operating system, to uncover how it works under the hood. Some of the earliest known pioneers of this were people like Mark Russinovich and Bryce Cogswell, the creators of the Sysinternals suite, who knew so much about the internal mechanics of Windows that Microsoft eventually hired them. They contributed heavily to the field of “Winternals” with books like Windows Internals.

Forensic practitioners like Eric Zimmerman (creator of KAPE) used this approach to work out the structure of data contained within various forensic data, and created tools to extract the relevant information.

Observation

Sometimes it’s as simple as doing something, and then seeing if anything changed.

Execute a process and see if:

• New files have appeared on disk
• Existing files’ modified timestamps have changed
• New registry entries have appeared
• Existing registry values’ “LastWrite” timestamps have changed

You could make this easier by using a tool like procmon to observe what happens when the process launched, or tools like regshot that can snapshot the registry before and after a process executes and tell you what’s changed.

D3DS Cache Files

So we know that if we wanted to discover a forensic artefact, we’ve got three options. Knowledge, Reverse Engineering, or Observation.

Personally I’m not very knowledgeable, and I’m definitely not motivated enough to start reverse engineering the Windows kernel. So let’s start with some simple observation work.

Our first test

All we’re going to do is execute some programs, and then go looking for anywhere they might have showed up on disk.

First, everything.exe, a tool I use to search for files. We’re going to run it, and then we’re gonna see what shows up in the dumbest way possible.

Okay so we’ve run it. Now we want to know if it’s showed up anywhere interesting. And the way we’re going to do that is to literally grep every file in my entire user profile for the process name. Those of you familiar with forensic artefact parsing will know that this is a stupid idea, and that the process name could be encoded, stored as base64, a compressed format, or even ROT13 or all sorts of strange stuff. But let’s see what we get back.

So we’ve got some interesting stuff here. In no particular order, and by no means suggesting we’ve done anything ground breaking here, we have:

• A crash dump from another process, komorebi - This is my custom window manager which presumably keeps all open Windows in memory. As this dump exists we could theorise that perhaps everything.exe was open around the time it was created
• AppInventory.json - Looks like Windows Feedback Hub sometimes keeps an inventory of installed applications and their associated executables in a JSON file, and possibly whether they are running (”IsRunningApp”) at the time - But wait I don’t have that in my SANS Triage bundle..?
• appsglobals.txt, and AppsIndex.db - These look like inventories of installed apps and corresponding registry entries, created by what forum users describe as “that useless Windows backup app”

Okay so nothing mind blowing, but interesting to find some application inventories that I’ve not heard of before. And a reminder of how much information some crash dumps can contain, even from processes other than those you are looking for.

Now let’s try the C:\Windows folder:

Again, just by doing something as stupid as searching a plaintext process name across disk has found:

• PcaAppLaunchDic.txt - This is the PCA, the new artefact of execution introduced on Windows 11. You can see how this one wouldn’t have been hard for researchers to spot. It’s a text file containing executable file paths and timestamps of execution in a very easy to parse format, so as far as artefacts go it’s an easy one. This is found within C:\Windows\appcompat, a folder rich with artefacts and even things like cached process icons.
• appsglobals.txt - Once again these inventories of installed apps show up. And this time within two new modern default Windows app packages.
• 15274.msi - This was found within the C:\Windows\Installer, a folder that I’ve never heard mentioned much before, but from a quick look (https://devblogs.microsoft.com/setup/windows-installer-cache/) appears to contain 3GB of cached copies of installers that have run on this system over the last year? Which makes us wonder if deleted installers used by threat actors could end up there - a topic for another day perhaps

So just like our user profile, we’ve found at least one very interesting thing here. So just by doing something as dumb as grepping a disk for a process name, we’re already learning more about places that Windows inventories apps, caches installers, and tracks running programs.

Another test, this time discovering our D3DS artefact

So I took another process that I use, fpilot.exe. Note that I’m using uniquely named processes as presumably something like “powershell.exe” would be referenced in thousands of places across the operating system.

Ran it, grepped for it, let’s take a look at the user profile hits:

Interesting. What are these?

It looks like on my laptop, in my user profile, is a folder called “D3DSCache”, presumably something to do with DirectX (and Direct3D), and some cached graphic data. I’d expect this sort of cached data on a user workstation, especially this one as I do occasionally game on it.

However, we found this by searching for FPilot.exe, not a game, which means that the files must contain hits for that string.

At the bottom of this file, we see the full file path to the executable that we ran. More interestingly though, we see from the head of the file that these are actually SQLite DB files. This is great news as these are easy to read with tools like DB Browser for SQLite.

Upon loading up the DB, we see that our file path is stored under a table called “app_id”, alongside some other fields that aren’t used in this instance. Let’s check out what other tables exist:

Tables groupkeys, groups, and vals, were all empty. But see below the table keys

Awesome, we see a field named “last_accessed” and what looks like an epoch timestamp. When converted, it becomes 1 December 2025 at 19:31:46, which lines up with the last modified date of the file.

So what do we know so far?

• There is a folder called D3DSCache, which Google tells us is to do with graphical shader caching by Direct3D.
• The files within are SQLite databases linked to a certain executable
• We have a last accessed timestamp

I noted at the time of discovering this that 1 December 2025 was most certainly the first date that I ran FPilot on this device. And based on how caching generally works, might it be that either the creation timestamp of the file itself, or the last_accessed timestamps within, provide evidence that this app was running at a certain time and date?

Well let’s check out some of the other files to test this hypothesis. I asked Claude (lame I know) to throw together a quick script to pull the relevant fields out of all these SQLite files and create a CSV.

Find the script here

Some of these entries are not surprising, like those related to games. But interestingly, more applications are present than I expected. Evidently, at least on Windows 11, a lot of applications engage in “hardware accelerated graphics”, which is where they are doing things graphically that they then ask the operating system / DirectX to help with through the GPU system, even when it’s just integrated graphics (which is the CPU doing the lifting anyway). So graphical apps like Discord, Spotify, Zoom, all offload some of their graphical processing to Direct3D, hence the creation of cache files.

We can see things in here that would be helpful for an investigation. We see Task Manager, as well as Visual Studio Code, even the Windows settings menu. And promisingly we see many of these applications more than once across cache files, suggesting that perhaps we get more than just the “first launch” timestamp for each of these.

Is this only for local activity?

My first thought was that as this is a hardware based graphical mechanism, perhaps it would not trigger for something like an Azure VM accessed only over RDP.

However, a test on a handful of VMs showed that these files are present by default on at least all the Windows 11 systems I had to hand

Testing on a case

So, we have an artefact. Perhaps not an artefact of execution, but at least an artefact of “that app was probably running and on the screen at that time”, which I will take for now. And we know that it is an artefact that we can also expect to be found on at very least most Windows 11 systems.

So the natural next step is to test it at scale in a large network. And we have just the tool to do that with: Velociraptor.

Many people (myself included) have a tendency to login to VR, launch hunts for all the “usual” Windows artefacts, and then perhaps import the community exchange and launch a few relevant ones from there too - This gets you as far as automating the standard KAPE style collection and processing across multiple systems at once, which in itself is a miracle.

However, the real power of VR comes in your ability to create your own artefacts using its very powerful VQL language.

https://gist.githubusercontent.com/michaeljgoodman/4d4e3416465064d46ebd997d21c12a80/raw/ad57a2d831318d808fdd6a23058e14a4a1921b97/Custom.Windows.Forensics.D3DShaderCache.yaml

Linked above is the VQL artefact I created to find and parse these dxcache files. I based it largely off of the Windows.Applications.Chrome.History artefact, that I knew would also have to find SQLite files and extract epoch timestamps from them.

Hits across nearly every system, across a huge variety of applications and timestamps both recent and historic.

Between the fact that this is user profile specific, and the file and in-database timestamps, we have a decent amount of information to gain from this artefact:

• Executable paths
• First cache date - likely the earliest execution of the app
• More recent cache dates - sign of recent execution
• The account it executed under

And we can see events for apps across several areas including:

• Browsers
• VPN Clients
• Text editors
• Sysadmin tools
• Teamviewer and other remote access software

What am I saying?

Now obviously, what we’ve done here is extremely crude, and very stupid. And obviously more research is needed, and who knows if our assumptions about these timestamps are correct. We could be way off, after all we know how misleading artefacts can be (think Shimcache, Shellbags, etc). And who knows how often these would actually be generated from threat actors tools or activity.

So what am I saying?

Am I saying that D3DS cache files should be added to DFIR triage bundles? No

Am I saying that it’s wrong to collect pre-set lists of artefacts, and that we should all be looking for weird niche stuff like this during every investigation? Of course not

But from a very brief bit of poking around, we’ve seen that there is much more to a Windows system than just the triage artefacts that we all know and love. There is information hiding in unexpected places - and not all of these places have been publicly captured and documented, or integrated into automagic tools that do our jobs for us.

So what should we be doing?

As this has been a long article and we’ve done a lot of goofing around I’ll break this down into what I think are the most important takeaways:

• Do your own research - If you want to improve your investigative instincts, you need to get stuck into the environments you’re investigating. Build them, rip them apart, poke and prod them and see what happens and where. Especially as we see a huge surge in cloud and SaaS compromise in the industry, now more than ever it is important that we as investigators really get familiar with the environments our Clients are operating in.

• Grep, and Quote search - I am not joking. The two most powerful tools you have as an investigator and a researcher are grep, and Google. Seer this into your brain: If you find an indicator of compromise, be it an IP address, a filename, a process:
• Grep every file on every system for it - Because why not? With tools like Velociraptor, why limit yourself to specific artefacts? Sure still do your triaging, but grep grep grep! You will find logs you’ve never seen before, you will find artefacts that only exist in that Client’s very specific environment, you will find the most vital of information in the most random of places.
• Google it in double quotes - If you have found something… quote search for it. I promise you at least 50% of the time, someone somewhere in the big wide world has posted information about that piece of malware you just found. Whether it is in a windows event log dump in a forum by someone troubleshooting browser issues, or a security researcher with no followers on Twitter who’s just found the same thing and has already done your job for you.
• Triaging is called triaging for a reason - It is called triaging because we can get 70% of the vital information from 1% of the data, in a very short space of time. And that helps us make important decisions fast - But after triaging comes investigation.
• You ran all the evidence of execution hunts and found 7 hosts where Akira have been. Great, time to rip those hosts apart. As the Velociraptor motto goes, “dig deeper”.