During an Incident Response (IR) engagement, I'm often asked what artifacts I look at for analysis. Sure, Event Logs are fantastic, the filesystem? Yep! Awesome! Windows Registry? Fantastic! But there's also other artifacts that are extremely powerful. These are artifacts generated by the Windows OS itself. Keep in mind that these artifacts are specifically designed for forensics purposes, but we can sure as heck use them for that! In this blog post, let's talk about the various artifacts that exist in newer Windows OS' and how your OS is watching you without you even knowing it!
The Rundown:
Modern Windows OS systems generate a large number of artifacts when a user interacts with it
These artifacts aren't specifically designed for forensics, but can be used as such
Many of these artifacts can be cleared intentionally by a Threat Actor (TA). With this said, many TAs are familiar with these and attempt to modify them as part of defense of evasion or covering their tracks
These artifacts can be considered volatile and overwrite themselves with heavy use of the OS
There are many artifacts that can be redundant, but more data is always great!
Some artifacts may only be present on systems and not servers, and vice-versa
Understand what the artifacts are telling you. Timestamps can be confusing and some artifacts may not necessarily prove a file was interacted with/executed
Each version of Windows may release more artifacts. More features means more artifacts!
Now that we got that out of the way, lets discuss a few things here. Okay okay.. maybe your OS isn't necessarily spying on you, but in order to provide various "features" that we, as users, take advantage of every day, the data has to be stored somewhere, right? For example, when you open your file explorer and a list comes up with your recently accessed documents, that data is stored somewhere. When you adjust the size of your folders or icons within file explorer, that's stored. In order to ensure your applications are running efficiently and are compatible, Windows needs to be aware of them ahead of time and determine if compatibility functions need to be invoked. This is stored somewhere! Have you ever executed an application for the first time and it takes a bit to open? But the second time, it seems to load much faster? Well, you're not going crazy. Windows will pre-load pieces of code to help applications run more efficiently! But in order to know which applications were opened previously.. yep.. you guessed it.. This is stored somewhere! So although these are general uses that are necessary to provide the many cool features with Windows, these can also be used to our advantage as forensics analysts.
Before we begin, I love to add this little tidbit. As an analyst, I'm a huge advocate of being.. well.. human. Understand that as humans, we don't know everything and we can't retain every single piece of information. Our brains have limits! With this said, there are many paths, values, formats and more when it comes to these artifacts. You should not be expected to remember every small piece of detail when it comes to these! But, you should know where to find this information. A fantastic tip is to consider creating your own forensics notebook that contains various event IDs, artifacts, their locations, notes about the artifact, etc. There are also many online resources ready to go. If you haven't heard of SANS posters, check them out! There's a great poster from SANS that contains these artifacts, which we'll be expanding on today. Specifically, the SANS Red Poster or "Evidence of.."
SANS Posters: https://www.sans.org/posters/
So lets dive right in to the artifacts that we can use to investigate what was executed or at least maintained some sort of presence on the system. A few example scenarios are listed below:
Ransomware was executed and you want to see if you can identify the binary name
A TA maintained persistence and you want to investigate what they interacted with. What tools did they use? Understand their Tactics, Techniques and Procedures (TTPs)
You need a better understanding of timeframes of the incident. When was something suspicious executed
Who executed the encryption binary or unauthorized tool?
What other timestamps can we gather from the binary?
Without having the file available, can we still collect metadata from it, such as hashes?
This article won't dive into each artifact, that'll be for another blog post! But, the main goal of this is to peak your interest in what analyst's use when investigating intrusions.
Let's create a brief list here of the many artifacts that we can use for forensics purposes. The information noted next to each artifact is the legitimate use of the artifact. Please note this list will not contain the many artifacts that can be used.
Evidence of File/Folder Knowledge/Interaction:
LNK Files - Shortcut files created by the OS when a file is interacted with
JumpLists - Provides options when a file/folder is open within the taskbar
Shellbags - Created when you browse to a new directory. Stores information regarding the folder. Such as icon size, window size, sort settings, etc.
RecentDocs - Provides stored settings when opening file explorer
Open/Save MRU - Provides recently closed/interacted with documents that provided an "open" or "save" shell prompt
LastVisited - Tracks apps used by open/save MRU
Evidence of Program Execution/Program Presence
Prefetch - Attempts to preload code for faster execution times
UserAssist - Stores GUI settings for an application
Jumplists - Provides options when a file/folder is open within the taskbar
Amcache - Stores application compatibility information and metadata about stored applications (cannot be used to prove program execution, but can show program existence)
Shimcache - Application compatibility (varies on the OS if this can be used for program execution, but can show program existence)
SRUM - System Resource Usage Monitor. Provides the data you see when opening the resource monitor application or stats within the task manager
Again, please note that some of these artifacts may not entirely confirm that a file was executed. This can vary on what data is presented in the artifact and the OS that these were collected on. The key takeaway here is to note that each artifact listed has a legitimate function, but these settings are stored on the OS to provide these features. Because of that, we can review them to help determine what occurred during an incident.
Additional Resources: