While exploring the world of DevSecOps, I came across Damien Burks’ The DevSec Blueprint - a comprehensive, free, and open-source learning guide that provides the foundational skills and knowledge needed to break into the field. After grasping the basics, I was eager to get hands-on and build a pipeline in AWS. I decided to dive in by following a guide straight from the DevSec Blueprint website. In this post, I’ll share my experience setting everything up, along with some lessons learned that might be helpful for anyone following a similar path.

Setting up Dependencies

First things first, I began by setting up the dependencies listed below.

• Setup GitHub Repos

• Setup Snyk Account

• Setup Terraform Cloud

• Configure Deployment Role in AWS

• Configure Secrets and Environment Variables

Setup GitHub Repos

I forked both the repos AWS DevSecOps Pipeline and Awesome FastAPI to my personal github account and then cloned both the forked repos to my local machine. I used GitHub CLI to interact with my GitHub account.

gh repo clone mdcn47/aws-devsecops-pipeline

gh repo clone mdcn47/awsome-fastapi

Setup Snyk Account

I signed up for Snyk using my GitHub account. Once logged-in, I clicked on my name in the bottom-left corner of the page and selected Account Settings. In the General section, I located the Auth Token field, generated a token, and noted it down for later integration. After that, I navigated to the Organization Settings page to obtain the Organization ID as well.

Setup Terraform Cloud

I signed up for Terraform Cloud, also using my GitHub account. Once I logged-in, I created an organization named MDCN which was pretty straightforward.

Configure Deployment Role in AWS

In this step, I’m setting up an AWS IAM role with OpenID Connect (OIDC), so Terraform Cloud can assume the role and deploy infrastructure changes on my behalf.

Adding Terraform Cloud as an OIDC provider

Creating an IAM Role for Terraform

I’ve begun by filling out the trust relationship fields, as shown below.

Following that, I created the role named terraform-cloud-deployer-oidc, attached the AdministratorAccess policy to it, and recorded its ARN for use in later steps.

Configure Secrets and Environment Variables

I started by defining the Organizational Variable Set in Terraform Cloud, which included creating the variables TFC_AWS_PROVIDER_AUTH and TFC_AWS_RUN_ROLE_ARN.

The following step was not documented in the guide; I identified it while working through the implementation.

Since we'll be using GitHub Actions to automate deployments when changes are pushed to the main branch, we need to generate a Terraform API token and add it as a repository secret in GitHub.

So I generated a Terraform API token using the steps shown below. Be sure to store the token securely, as it will only be displayed once.

Then I added the Terraform API token as a secret to the forked aws-devsecops-pipeline repository.

Deploying and Testing

In this final stage, I deploy and configure the infrastructure, run the pipeline, and analyze the output.

Deploying and Configuring the Pipeline

I logged into Terraform Cloud and created a project called devsecops-aws under my organization, MDCN. Within this project, I set up two workspaces: aws-devsecops-eks-cluster and aws-devsecops-pipelines.

Note*: In the guide, the workspace names included the organization name as a prefix. However, this will lead to errors later when running the workflow, since the workspace names in the Terraform configuration files (provider.tf) and the GitHub Actions workflow files (terraform-apply-eks.yml and terraform-apply-pipelines.yml) do not match.*

However, there's an issue: Terraform Cloud is unable to validate the configurations because the organization name in my account differs from the one specified in the Terraform code of the forked repository.

So, I used grep to search the local repository for the string dsb - the organization name used in the guide - to identify all the files that needed to be updated.

grep -rniw . -e "dsb"

I replaced all instances of dsb with mdcn in the relevant files and pushed the changes to the repository.

Next, I created two variables, SNYK_ORG_ID and SNYK_TOKEN, in the aws-devsecops-pipelines workspace and populated them with their respective values.

I then tried to deploy the changes using GitHub Actions.

However, the deployment failed at the Create Apply Run step. From the error message, it seems the connection to the AWS account failed.

While troubleshooting this issue, I noticed another required change in the main.tf file - replacing the AWS username from damien to mdcn47 (my AWS IAM user). I made the change right away.

After digging through the Terraform code, IAM role settings, and Terraform Cloud configuration, I finally tracked down the issue. I had originally created my Terraform Cloud project as aws-devsecops, but when setting up the IAM role I followed the guide and used AWS as the project name. This mismatch caused the trust policy to reference the wrong project. To fix it, I simply renamed my Terraform Cloud project to AWS.

I tested the connection by running terraform plan locally.

With that fixed, it’s a good time to kick off another deployment using GitHub Actions. This time the failure happened during the Apply step. Turns out the AMI type specified in the configuration is incompatible with the current Kubernetes version.

So I updated the code, swapping out ami_type = AL2_x86_64 for ami_type = AL2023_x86_64_STANDARD in the aws_eks_node_group resource block (line number 98).

The git push automatically triggered the workflow again and this time both the eks-cluster and pipelines terraform ran successfully.

I logged into my AWS account, checked the EKS console, and confirmed that the cluster, nodes, and pods were all successfully created.

However, when I checked AWS CodePipeline, I noticed that the awsome-fastapi application failed to deploy because of a GitHub connection error.

Navigating to Settings > Connections clearly indicates that the connection is in a pending status.

I followed the steps in the guide and was able to set up the connection without any issues.

The pipeline is now operational and configured to automatically detect and deploy changes from the GitHub repository.

Running the Pipeline and Analyzing Outputs

I triggered the pipeline by navigating to the CodePipeline dashboard, selecting the awsome-fastapi pipeline, and clicking Release change.

Clicking that button kicks off the pipeline - it’s expected to pull the latest code from GitHub, build the project, run tests and security scans, and finally deploy the application into the EKS cluster. However, the pipeline failed at the SnykSecurityScan step within the Test phase.

Digging into the error, I found that it failed while executing the command snyk auth ${SNYK_TOKEN}. A bit of research suggested that the curly braces {} might not be necessary, and removing them could fix the issue.

I went ahead and updated the sastscanning.yml file inside codepipeline/buildspecs and pushed the changes to the repository.

The new commit triggered another pipeline run. For the application deployment, I manually triggered the pipeline again by clicking Release change in CodePipeline. This time, Snyk authenticated successfully, but the pipeline failed as expected because it detected a critical severity vulnerability, exceeding the high threshold we had set.

The Snyk CLI exits with status code 1 whenever it finds vulnerabilities that meet or exceed the severity threshold we’ve set (high in our case). However, for testing the application deployment, I want the pipeline to continue while still reporting any issues. To achieve this, I appended || true to the command, making it: snyk test --file=requirements.txt --severity-threshold=high || true.

I updated the sastscanning.yml file once more and pushed the changes to the repository.

With this run, every test passed and the app was deployed without any issues.

While going through the execution logs, I noticed that the Snyk Code scan hadn’t run because it wasn’t enabled in my Snyk account. I quickly turned it on and reran the deployment.

Synk Scan Results

Trivy Scan Results (Container Security Scan)

With the application successfully deployed, I wanted to verify that it was running smoothly without any issues. I opened my EKS cluster (mdcn-devsecops-cluster), navigated to Resources > Services > awsome-fastapi, grabbed the load balancer URL, and accessed it in the browser. Since the app was running on port 80, I used HTTP. I was greeted with a Hello World message, confirming that the app was up and running without any issues.

It’s been a great learning journey, but I can’t stop here - I need to tear down the AWS infrastructure from this exercise before it surprises me with a painful credit card bill.

I navigated to the pipeline and eks-cluster Terraform directories and ran terraform destroy --auto-approve.

And that’s a wrap! The pipeline ran, the app deployed successfully, I learned a ton, and all AWS resources are now safely cleaned up - no surprises for my credit card.

History

The browser's history is a fundamental artifact for understanding a user's online journey.

• Description: This artifact records websites visited by date and time. It stores details for each local user account and records the number of times visited (frequency). Importantly, it also tracks access of local system files and includes the website history of search terms in search engines.

• Location:

  • Internet Explorer:

    • IE6-7: %USERPROFILE%\Local Settings\History\History.IE5.

    • IE8-9: %USERPROFILE%\AppData\Local\Microsoft\Windows\History\History.IE5.

    • IE10, 11, Edge: %USERPROFILE%\AppData\Local\Microsoft\Windows\WebCache\WebCacheV*.dat.

  • Firefox:

    • XP: %userprofile%\Application Data\Mozilla\Firefox\Profiles\<randomtext>.default\places.sqlite.

    • Win7/8/10: %userprofile%\AppData\Roaming\Mozilla\Firefox\Profiles\<randomtext>.default\places.sqlite.

  • Chrome:

    • XP: %USERPROFILE%\Local Settings\Application Data\Google\Chrome\User Data\Default\History.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\History.

• Interpretation: The history artifact allows investigators to understand what sites a user has been visiting and can list the files that were opened from remote sites and downloaded to the local system. It also records the access to files on websites that were accessed via a link.

Cookies

Cookies offer insights into specific activities and visits.

• Description: Cookies give insight into what websites have been visited and what activities may have taken place there.

• Location:

  • Internet Explorer:

    • IE6-8: %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Cookies.

    • IE10: %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Cookies.

    • IE11: %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCookies.

    • Edge: %USERPROFILE%\AppData\Local\Packages\microsoft.microsoftedge_<APPID>\AC\MicrosoftEdge\Cookies.

  • Firefox:

    • XP: %USERPROFILE%\Application Data\Mozilla\Firefox\Profiles\<random text>.default\cookies.sqlite.

    • Win7/8/10: %USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\<randomtext>.default\cookies.sqlite.

  • Chrome:

    • XP: %USERPROFILE%\Local Settings\ApplicationData\Google\Chrome\User Data\Default\Local Storage.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Local Storage.

• Interpretation: By examining cookies, forensicators can gain valuable insight into websites visited and the actions performed on them.

Cache

Browser cache provides a tangible snapshot of content viewed by a user.

• Description: The cache is where web page components can be stored locally to speed up subsequent visits. It gives the investigator a "snapshot in time" of what a user was looking at online. It identifies websites which were visited and provides the actual files the user viewed on a given website. These cached files are tied to a specific local user account, and their timestamps show when the site was first saved and last viewed.

• Location:

  • Internet Explorer:

    • IE8-9: %USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5.

    • IE10: %USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5.

    • IE11: %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache\IE.

    • Edge: %USERPROFILE%\AppData\Local\Packages\microsoft.microsoftedge_<APPID>\AC\MicrosoftEdge\Cache.

  • Firefox:

    • XP: %USERPROFILE%\Local Settings\ApplicationData\Mozilla\Firefox\Profiles\<randomtext>.default\Cache.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Mozilla\Firefox\Profiles\<randomtext>.default\Cache.

  • Chrome:

    • XP: %USERPROFILE%\Local Settings\Application Data\Google\Chrome\User Data\Default\Cache - data_# and f_######.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Cache\ - data_# and f_######.

• Interpretation: The cache acts as a direct evidence source of content a user has viewed, with timestamps providing a temporal context of access and viewing.

Flash & Super Cookies

These persistent tracking mechanisms often bypass typical browser cookie management.

• Description: Local Stored Objects (LSOs), also known as Flash Cookies, have become ubiquitous on most systems due to the extremely high penetration of Flash applications across the Internet. They tend to be much more persistent because they do not expire, and there is no built-in mechanism within the browser to remove them. Many sites have begun using LSOs for their tracking mechanisms because they rarely get cleared like traditional cookies.

• Location: Win7/8/10: %APPDATA%\Roaming\Macromedia\FlashPlayer\#SharedObjects\<randomprofileid>.

• Interpretation: Due to their persistence and lack of easy user-deletion mechanisms, Flash and Super Cookies are powerful artifacts for long-term user tracking and profiling, often revealing activity that might otherwise be hidden if only traditional cookies were examined.

Session Restore

Session restore features can inadvertently preserve crucial browsing context.

• Description: This artifact relates to Automatic Crash Recovery features built into the browser.

• Location:

  • Internet Explorer Win7/8/10: %USERPROFILE%/AppData/Local/Microsoft/Internet Explorer/ Recovery.

  • Firefox Win7/8/10: %USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\<randomtext>.default\sessionstore.js.

  • Chrome Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\ Files = Current Session, Current Tabs, Last Session, Last Tabs.

• Interpretation: Session restore data can provide insights into:

  • Historical websites viewed in each tab.

  • Referring websites.

  • Time the session ended.

  • Modified time of .dat files in the LastActive folder.

  • Time each tab opened (only when a crash occurred).

  • Creation time of .dat files in the Active folder.

Google Analytics Cookies

These specific cookies offer highly detailed tracking information often used by websites.

• Description: Google Analytics (GA) has developed an extremely sophisticated methodology for tracking site visits, user activity, and paid search. GA holds a commanding market share, estimated at over 80% of sites using traffic analysis and over 50% of all sites, largely because it is free. Key GA cookies include:

  • __utma: Tracks Unique visitors, including Domain Hash, Visitor ID, Cookie Creation Time, Time of 2nd most recent visit, Time of most recent visit, and Number of visits.

  • __utmb: Used for Session tracking, including Domain hash, Page views in current session, Outbound link clicks, and Time current session started.

  • __utmz: Identifies Traffic sources, including Domain Hash, Last Update time, and Number of visits.

• Location: The specific file paths for Google Analytics cookies are not explicitly detailed in the provided source separate from the general browser cookie locations. One would typically look for these within the browser's main cookie storage.

• Interpretation: These cookies provide a highly granular view of user interaction with specific websites, allowing forensicators to reconstruct visitor history, session duration, referral sources, and even repeat visit patterns to sites that employ Google Analytics.

By thoroughly analyzing these browser usage artifacts, digital forensic investigators can reconstruct significant portions of a user's online activities, providing critical evidence for a wide range of investigations.

Key Identification

Identifying the specific USB devices that have been connected to a machine is a foundational step in any forensic investigation.

• Description: This artifact helps to track USB devices plugged into a machine.

• Location: The relevant information can be found in the SYSTEM Hive, specifically at SYSTEM\CurrentControlSet\Enum\USBSTOR and SYSTEM\CurrentControlSet\Enum\USB.

• Interpretation: This allows investigators to identify the vendor, product, and version of a USB device. It also helps to identify a unique USB device plugged into the machine. Furthermore, it can determine the time a device was plugged into the machine. A notable detail is that devices that do not have a unique serial number will have an "&" in the second character of the serial number.

First/Last Times

Pinpointing the exact temporal usage of USB devices provides a critical timeline for forensic analysis.

• Description: This artifact is used to determine temporal usage of specific USB devices connected to a Windows Machine.

• Location:

  • For the First Time of connection, investigators should look at Plug and Play Log Files:

    • XP: C:\Windows\setupapi.log

    • Win7/8/10: C:\Windows\inf\setupapi.dev.log

  • For First, Last, and Removal Times (specific to Win7/8/10 only), the information is in the System Hive:

    • \CurrentControlSet\Enum\USBSTOR\Ven_Prod_Version\USBSerial#\Properties\{83da6326-97a6-4088-9453-a19231573b29}\####

• Interpretation:

  • In the log files, investigators can search for the Device Serial Number. It's important to note that Log File times are set to the local time zone.

  • Within the System Hive, specific numerical values indicate different temporal events:

    • 0064: Signifies the First Install (Win7-10).

    • 0066: Indicates the Last Connected (Win8-10).

    • 0067: Represents the Last Removal (Win8-10).

User

Determining which user was responsible for plugging in a specific USB device is essential for attributing actions.

• Description: This artifact helps to find the user that used the Unique USB Device.

• Location: Investigators need to look for the GUID from SYSTEM\MountedDevices and then correlate it with NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2.

• Interpretation: The last write time of the MountPoints2 key is used to identify the user that plugged in the device.

PnP Events

Plug and Play (PnP) events capture the system's response to new hardware connections, including USB devices.

• Description: When a Plug and Play driver install is attempted, the service will log an ID 20001 event and provide a Status within the event. This event will trigger for any Plug and Play-capable device, which includes, but is not limited to, USB, Firewire, and PCMCIA devices.

• Location: These events are found in the System Log File:

  • Win7/8/10: %system root%\System32\winevt\logs\System.evtx

• Interpretation:

  • The Event ID: 20001 specifically indicates a Plug and Play driver install attempted.

  • The event includes a Timestamp, Device information, Device serial number, and a Status (where 0 indicates no errors).

Volume Serial Number

Beyond the device's hardware serial, the volume serial number of the filesystem partition can provide additional linkage to user activity.

• Description: This artifact helps to discover the Volume Serial Number of the Filesystem Partition on the USB. It's important to note that this is not the USB Unique Serial Number, which is hardcoded into the device firmware.

• Location: The information is typically found in the SOFTWARE Hive at SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ENDMgmt. To derive the serial number, one would use the Volume Name and USB Unique Serial Number to find the last integer number in the line, then convert the Decimal Serial Number into a Hex Serial Number.

• Interpretation: Knowing both the Volume Serial Number and the Volume Name, you can correlate the data across Shortcut File (LNK) analysis and the RECENTDOCs key. The Shortcut File (LNK) contains the Volume Serial Number and Name. Additionally, the RecentDocs Registry Key, in most cases, will contain the volume name when the USB device is opened.

Drive Letter and Volume Name

Understanding the drive letter assigned to a USB device can assist in reconstructing file paths and user access.

• Description: This artifact helps to discover the last drive letter of the USB Device when it was plugged into the machine.

• Location:

  • XP:

    • Find ParentIdPrefix at SYSTEM\CurrentControlSet\Enum\USBSTOR.

    • Then, using ParentIdPrefix, discover the Last Mount Point at SYSTEM\MountedDevices.

  • Win7/8/10:

    • SOFTWARE\Microsoft\Windows Portable Devices\Devices

    • SYSTEM\MountedDevices - investigators should examine Drive Letters looking at Value Data Looking for the Serial Number.

• Interpretation: This technique allows investigators to identify the USB device that was last mapped to a specific drive letter. However, it's crucial to remember that this technique will only work for the last drive mapped and does not contain historical records of every drive letter mapped to a removable drive.

Shortcut (LNK) Files

Shortcut files are automatically generated by Windows and can provide rich details about file and folder access, including those on external devices.

• Description: Shortcut files are automatically created by Windows. These include Recent Items, and opening local and remote data files and documents will generate a shortcut file (.lnk).

• Location: While LNK files can be found in other locations, primary locations related to user activity include:

  • XP: C:\%USERPROFILE%\Recent

  • Win7/8/10:

    • C:\%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent\

    • C:\%USERPROFILE%\AppData\Roaming\Microsoft\Office\Recent\

• Interpretation: LNK files offer a wealth of information:

  • The Creation Date of the Shortcut (LNK) File indicates the Date/Time a file of that name was first opened.

  • The Last Modification Date of the Shortcut (LNK) File indicates the Date/Time a file of that name was last opened.

  • The LNKTarget File (Internal LNK File Information) Data itself contains:

    • Modified, Access, and Creation times of the target file.

    • Volume Information (including Name, Type, and Serial Number).

    • Network Share information.

By leveraging these artifacts, forensic experts can paint a detailed picture of external device interactions, identifying not only the devices themselves but also the timeline of their usage and the users involved, which is invaluable for incident response and digital investigations.

Last Login

The "Last Login" artifact provides a quick snapshot of when local accounts were last accessed.

• Description: This artifact lists the local accounts of the system and their equivalent security identifiers.

• Location: The relevant information can be found within the SAM (Security Account Manager) hive, specifically at C:\windows\system32\config\SAM and within the SAM\Domains\Account\Users key.

• Interpretation: It's important to note that only the last login time will be stored in this registry key.

Last Password Change

Tracking password changes is crucial for understanding account hygiene and potential compromise.

• Description: This artifact lists the last time the password of a specific local user has been changed.

• Location: Similar to "Last Login," this information is located within the SAM hive at C:\windows\system32\config\SAM and under the SAM\Domains\Account\Users key.

• Interpretation: Like last login, only the last password change time will be stored in this registry key.

RDP Usage

Remote Desktop Protocol (RDP) activity is a common vector for unauthorized access, making its forensic artifacts highly significant.

• Description: "RDP Usage" artifacts track Remote Desktop Protocol logons to target machines.

• Location: This data is primarily recorded in the Security Log. On Windows 7/8/10 systems, the relevant log file is found at %SYSTEM ROOT%\System32\winevt\logs\Security.evtx.

• Interpretation:

  • For Windows 7/8/10, Event ID 4778 signifies a Session Connected/Reconnected.

  • Event ID 4779 indicates a Session Disconnected.

  • The event log further provides the hostname and IP address of the remote machine making the connection.

  • Forensically, it's a common observation on workstations that a current console session disconnected (Event ID 4779) is often followed by an RDP connection (Event ID 4778).

Services Events

Services are a frequent target for malware persistence and system manipulation, and their event logs provide critical insights.

• Description: These events allow investigators to analyze logs for suspicious services running at boot time and to review services started or stopped around the time of a suspected compromise.

• Location: All relevant Event IDs for services reference the System Log. Specific Event IDs include:

  • 7034: Service crashed unexpectedly.

  • 7035: Service sent a Start/Stop control.

  • 7036: Service started or stopped.

  • 7040: Start type changed (e.g., Boot | On Request | Disabled).

  • 7045: A service was installed on the system (specific to Win2008R2+).

  • 4697: A service was installed on the system (from the Security log).

• Interpretation:

  • It's important to note that all Event IDs except 4697 reference the System Log.

  • A large amount of malware and worms in the wild utilize Services for various malicious purposes.

  • Services started on boot illustrate persistence, which is a desirable trait for malware.

  • Furthermore, services can crash due to attacks like process injection.

Logon Types

Understanding the "Logon Type" provides granular detail about the method of account authentication.

• Description: Logon Events provide very specific information regarding the nature of account authorizations on a system. Beyond the date, time, username, hostname, and success/failure status of a logon, they enable investigators to determine exactly by what means a logon was attempted.

• Location: For Windows 7/8/10, the primary Event ID for logon events is 4624.

• Interpretation: The "Logon Type" field within these events deciphers the method of logon:

Authentication Events

These events offer insight into the underlying authentication protocols used for account verification.

• Description: This artifact describes the authentication mechanisms employed on the system.

• Location: Authentication events are recorded on the system that authenticated the credentials.

  • For local account/workgroup authentication, the events are found on the workstation.

  • For Domain/Active Directory authentication, they are found on the domain controller.

  • On Windows 7/8/10, these events are typically located in the Security Event Log at %SYSTEM ROOT%\System32\winevt\logs\Security.evtx.

• Interpretation: Specific Event ID Codes help interpret the authentication protocol used:

  • NTLM protocol:

    • 4776: Indicates Successful/Failed account authentication.

  • Kerberos protocol:

    • 4768: Signifies that a Ticket Granting Ticket was granted (successful logon).

    • 4769: Indicates a Service Ticket was requested (access to server resource).

    • 4771: Denotes that Pre-authentication failed (failed logon).

Success/Fail Logons

A fundamental aspect of security analysis, these events directly report the outcome of logon attempts.

• Description: This artifact allows investigators to determine which accounts have been used for attempted logons and to track account usage for known compromised accounts.

• Location: On Windows 7/8/10, these events are found within the Security Event Log at %system root%\System32\winevt\logs\Security.evtx.

• Interpretation: The following Event IDs provide clear indications of logon outcomes on Windows 7/8/10 systems:

  • 4624: Indicates a Successful Logon.

  • 4625: Denotes a Failed Logon.

  • 4634 | 4647: Signify a Successful Logoff.

  • 4648: Represents a Logon using explicit credentials (Runas).

  • 4672: Indicates an Account logon with superuser rights (Administrator).

  • 4720: Shows that An account was created.

By meticulously analyzing these "Account Usage" artifacts, forensic investigators can establish a comprehensive understanding of user and account activities, identify potential security breaches, and piece together the narrative of events that occurred on a Windows system.

XP Search – ACMRU

The XP Search – ACMRU artifact provides insight into a user's search history on Windows XP systems.

• Description: The search assistant on a Windows XP machine allows users to search for a wide range of information. This assistant will remember a user’s search terms for filenames, computers, or words that are inside a file, serving as a form of "Search History".

• Location: This artifact is found within the NTUSER.DAT HIVE, specifically at NTUSER.DAT\Software\Microsoft\Search Assistant\ACMru\####.

• Interpretation: The #### in the location denotes different categories of searches:

  • 5001 indicates a search for "Search the Internet".

  • 5603 indicates a search for "All or part of a document name".

  • 5604 indicates a search for "A word or phrase in a file".

  • 5647 indicates a search for "Printers, Computers and People". This artifact can reveal what a user was looking for, even if the files or information themselves are no longer present.

Thumbcache

Thumbcache databases store visual representations of files, providing a glimpse into previously viewed content.

• Description: The thumbcache is a database that contains thumbnails of pictures, office documents, and folders. Each user has their own database, which is based on the thumbnail sizes the user has viewed (small, medium, large, and extra-large).

• Location: The thumbcache files are located at C:\%USERPROFILE%\AppData\Local\Microsoft\Windows\Explorer.

• Interpretation: These thumbnail caches are created when a user switches a folder to thumbnail mode or views pictures via a slideshow. On Windows 7 and later, four distinct sizes for thumbnails are stored in separate database files, reflecting sizes 32 (small), 96 (medium), 256 (large), and 1024 (extra large). The thumbcache stores a copy of the picture's thumbnail based on the size in the content of the equivalent database file. This means that even if the original image or document file has been deleted, its thumbnail might still exist in the thumbcache, offering evidence that the file was once present and viewed.

Thumbs.db

Similar to Thumbcache, Thumbs.db files offer another avenue for uncovering previously viewed images.

• Description: Thumbs.db is a hidden file found in directories where images exist. It stores smaller thumbnail graphics and catalogs pictures in a folder, importantly, it stores a copy of the thumbnail even if the pictures were deleted.

• Location:

  • On Windows XP and Windows 8/8.1, Thumbs.db is automatically created anywhere with homegroup enabled.

  • On Windows 7, 8, and 10, it is automatically created anywhere and can be accessed via a UNC Path (local or remote).

• Interpretation: The contents of Thumbs.db include:

  • The Thumbnail Picture of the Original Picture.

  • Document Thumbnails, even if the original document was deleted.

  • Last Modification Time (for XP Only).

  • Original Filename (for XP Only). This artifact is crucial for identifying images that were once present in a specific folder, even after their deletion.

IE | Edge file://

This artifact provides a less obvious but powerful way to track local file access.

• Description: A "little-known fact" is that Internet Explorer History is not solely related to Internet browsing. It also records local, removable, and remote (via network shares) file access. This makes it an "excellent means for determining which files and applications were accessed on the system, day by day".

• Location: The location varies by Internet Explorer version:

  • IE6-7: %USERPROFILE%\Local Settings\History\History.IE5.

  • IE8-9: %USERPROFILE%\AppData\Local\Microsoft\WindowsHistory\History.IE5.

  • IE10-11 & Edge: %USERPROFILE%\AppData\Local\Microsoft\Windows\WebCache\WebCacheV*.dat.

• Interpretation: Entries for local or remote file access are stored in index.dat and appear as [file:///C:/directory/filename.ext](file:///C:/directory/filename.ext). It's important to note that this does not mean the file was opened within the browser itself. Instead, it simply indicates that the file was accessed via a path that IE's history tracks.

Search – WordWheelQuery

This artifact provides a direct record of user search queries made through the Start menu.

• Description: This artifact tracks keywords searched for from the START menu bar on a Windows 7 machine (and subsequently Windows 8/10).

• Location: This information is stored in the NTUSER.DAT Hive at NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery.

• Interpretation: The keywords searched are added in Unicode format and are listed in temporal order within an MRU (Most Recently Used) list. This can be valuable for understanding what a user was looking for on their system, providing clues about file names or content, even if the files themselves were later deleted or moved.

Win7/8/10 Recycle Bin

The Recycle Bin is often the first place to look for deleted files, offering direct evidence of their removal.

• Description: The Recycle Bin is a "very important location on a Windows file system to understand" for forensic investigations. Generally, every file deleted from a Recycle Bin-aware program is first placed in the Recycle Bin.

• Location: This is a Hidden System Folder located at C:\$Recycle.bin. Within this location, the Deleted Time and Original Filename of the deleted items are contained in separate files for each recovery file.

• Interpretation:

  • The Security Identifier (SID) associated with Recycle Bin contents can be mapped to a specific user via Registry Analysis.

  • For Windows 7, 8, and 10:

    • Files preceded by $I###### contain the Original PATH and name of the deleted file, along with its Deletion Date/Time.

    • Files preceded by $R###### contain the Recovery Data (the actual content of the deleted file). The Recycle Bin provides critical information about what was deleted, when, by whom, and from where, potentially allowing for recovery of the original data.

Last-Visited MRU

This artifact links file access to the applications used and the last directories accessed.

• Description: The Last-Visited MRU tracks the specific executable used by an application to open the files documented in the OpenSaveMRU key. Additionally, each value in this artifact tracks the directory location for the last file that was accessed by that application. An example given is Notepad.exe last run using the C:\%USERPROFILE%\Desktop folder.

• Location:

  • Windows XP: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU.

  • Windows 7/8/10: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU.

• Interpretation: This key specifically tracks the application executables used to open files in OpenSaveMRU and, critically, the last file path used by that application. This can provide context on what files were being worked on with what applications, even if the files themselves are no longer directly accessible.

XP Recycle Bin

Similar to its modern counterpart, the XP Recycle Bin provides crucial information about deleted files on older Windows systems.

• Description: The Recycle Bin is a "very important location on a Windows file system to understand" for forensic investigations. Similar to later Windows versions, every file that is deleted from a Windows recycle bin aware program is generally first put in the recycle bin on XP.

• Location: This is a Hidden System Folder located at C:\RECYCLER for Windows 2000, NT, XP, and 2003. Within this directory, a subfolder is created with the user’s SID. A hidden file named INFO2 within this subfolder contains the Deleted Time and Original Filename. The filename is stored in both ASCII and UNICODE formats.

• Interpretation:

  • The SID can be mapped to the specific user via Registry Analysis.

  • This artifact maps the file name to the actual name and path it was deleted from. By examining the XP Recycle Bin, investigators can determine what files were deleted, when, and from where, allowing for a reconstruction of events surrounding file removal on Windows XP systems.

By understanding and meticulously analyzing these artifacts, digital forensic investigators can piece together a compelling narrative about file activity, even when explicit files have been removed from the system. These digital breadcrumbs are invaluable for revealing the truth about what happened on a Windows machine.

Open/Save MRU

The Open/Save Most Recently Used (MRU) key is a treasure trove for understanding file interactions.

• Description: This key tracks files that have been opened or saved within a Windows shell dialog box. This includes a vast array of applications, not just web browsers like Internet Explorer and Firefox, but also a majority of commonly used applications.

• Location:

  • XP: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU.

  • Win7/8/10: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePIDlMRU.

• Interpretation:

  • The * key within this structure tracks the most recent files of any extension that were input in an OpenSave dialog.

  • Subkeys named after three-letter extensions (e.g., .doc, .pdf) store file information from the OpenSave dialog specific to that extension.

Recent Files

Windows keeps a dynamic list of recently accessed files and folders, directly influencing the "Recent" menus available to users.

• Description: This Registry Key tracks the last files and folders opened and is used to populate data in “Recent” menus of the Start menu.

• Location: NTUSER.DAT: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs.

• Interpretation:

  • The RecentDocs key itself tracks the overall order of the last 150 files or folders opened. Its MRU (Most Recently Used) list maintains the temporal order in which each file/folder was opened. The last entry and modification time of this key will reveal the time and location the last file of a specific extension was opened.

  • Subkeys named after specific extensions (e.g., .???) store information about the last files with that extension that were opened. Their MRU lists also track temporal order.

  • The Folder subkey tracks the last folders that were opened, with its MRU list maintaining their temporal order. The last entry and modification time of this key identifies the time and location of the last folder opened.

Jump Lists

Introduced with Windows 7, Jump Lists provide a quick way for users to access frequently or recently used items, but also serve as a forensic goldmine.

• Description: The Windows 7 taskbar (Jump List) is designed to allow users to "jump" or access items they have frequently or recently used quickly and easily. This functionality includes not only recent media files but also recent tasks. The data is stored in the AutomaticDestinations folder, where each unique file is prepended with the AppID of its associated application and contains embedded LNK files within its streams.

• Location: Win7/8/10: C:\%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations.

• Interpretation:

  • The Creation Time of an item indicates the first time of execution of the application, or when the item was first added to the AppID file.

  • The Modification Time indicates the last time of execution of the application when a file was open, or when the item was last added to the AppID file.

  • Forensic investigators can use a Structured Storage Viewer to open these AutomaticDestination jumplist files. Each one is a separate LNK file, numerically stored in order from the earliest (usually 1) to the most recent (largest integer value). A list of Jump List IDs is available online for further reference.

Shell Bags

Shell Bags offer valuable insights into a user's browsing of folders, even those that no longer exist.

• Description: Shell Bags track which folders were accessed on the local machine, the network, and/or removable devices. They can provide evidence of previously existing folders after deletion/overwrite and when certain folders were accessed.

• Location:

  • Explorer Access:

    • USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags.

    • USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU.

  • Desktop Access:

    • NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU.

    • NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags.

• Interpretation: Shell Bags store information about which folders were most recently browsed by the user.

Shortcut (LNK) Files

Windows automatically creates shortcut files, which are a rich source of information about accessed files and their locations.

• Description: Shortcut Files (.lnk) are automatically created by Windows for "Recent Items" and whenever local or remote data files and documents are opened.

• Location:

  • XP: C:\%USERPROFILE%\Recent.

  • Win7/8/10:

    • C:\%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent\.

    • C:\%USERPROFILE%\AppData\Roaming\Microsoft\Office\Recent\.

  • It's important to note that while these are primary locations, LNK files can also be found elsewhere on the system.

• Interpretation:

  • The Creation Date of the Shortcut (LNK) File indicates the date/time the file of that name was first opened.

  • The Last Modification Date of the Shortcut (LNK) File indicates the date/time the file of that name was last opened.

  • LNKTarget File Data (Internal LNK File Information) provides critical details about the target file, including:

    • Modified, Access, and Creation times of the target file itself.

    • Volume Information (Name, Type, Serial Number) where the target file resided.

    • Network Share information if it was accessed remotely.

    • The Original Location of the file.

    • The Name of the System where the file was located.

Prefetch

Prefetch files are primarily for system performance optimization, but they inadvertently record valuable execution history for forensic analysis.

• Description: Prefetch increases system performance by pre-loading code pages of commonly used applications. The Cache Manager monitors all files and directories referenced for each application or process and maps them into a .pf file. This artifact is utilized to know if an application was executed on a system.

  • Limitations: Limited to 128 files on XP and Win7, and 1024 files on Win8 and Win8-10.

  • Files are named in the format (exename)-(hash).pf.

• Location: WinXP/7/8/10: C:\Windows\Prefetch.

• Interpretation:

  • Each .pf file includes the last time of execution, the number of times the program was run, and the device and file handles used by the program.

  • The Creation Date of the .pf file (minus 10 seconds) indicates the date/time the file by that name and path was first executed.

  • The embedded last execution time within the .pf file, or the Last modification date of the .pf file (minus 10 seconds), indicates the date/time the file by that name and path was last executed.

  • Win8-10 systems will contain the last 8 times of execution. Additionally, these files can be examined for recently used file handles and device handles.

Last-Visited MRU

Complementing the Open/Save MRU, this artifact narrows down the specific executable and path for the last accessed file.

• Description: This artifact tracks the specific executable used by an application to open the files documented in the OpenSaveMRU key. Furthermore, each value tracks the directory location for the last file that was accessed by that application. An example given is "Notepad.exe was last run using the C:\Users\Rob\Desktop folder".

• Location:

  • XP: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU.

  • Win7/8/10: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU.

• Interpretation: This artifact directly tracks the application executables used to open files in OpenSaveMRU and the last file path used.

IE | Edge file://

Often overlooked, browser history can record much more than just internet browsing.

• Description: A little-known fact about the Internet Explorer (IE) History is that the information stored within its history files is not solely related to Internet browsing. The history also records local, removable, and remote (via network shares) file access, providing an excellent means for determining which files and applications were accessed on the system, day by day.

• Location:

  • Internet Explorer:

    • IE6-7: %USERPROFILE%\Local Settings\History\History.IE5.

    • IE8-9: %USERPROFILE%\AppData\Local\Microsoft\Windows\History\History.IE5.

    • IE10-11: %USERPROFILE%\AppData\Local\Microsoft\Windows\WebCache\WebCacheV*.dat.

• Interpretation:

  • This information is stored in index.dat files, typically formatted as: [file:///C:/directory/filename.ext](file:///C:/directory/filename.ext).

  • It is crucial to understand that the presence of such an entry does not mean the file was opened within the browser itself, but simply that the file was accessed.

Office Recent Files

Microsoft Office applications maintain their own internal logs of recently opened documents, offering specific insights into productivity and file interaction.

• Description: Microsoft Office programs track their own "Recent Files" list to make it easier for users to remember the last file they were editing.

• Location:

  • NTUSER.DAT\Software\Microsoft\Office\VERSION, where VERSION corresponds to:

    • 10.0 = Office XP.

    • 11.0 = Office 2003.

    • 12.0 = Office 2007.

    • 14.0 = Office 2010.

  • NTUSER.DAT\Software\Microsoft\Office\VERSION\UserMRU\LiveID_####\FileMRU, specifically for:

    • 15.0 = Office 365.

• Interpretation: Similar to the general "Recent Files" artifact, this tracks the last files that were opened by each specific MS Office application. The last entry added, according to the MRU, signifies the time the last file was opened by that particular MS Office application.

By meticulously examining these "File/Folder Opening" artifacts, digital forensic investigators can reconstruct detailed timelines of user activity, identify accessed documents, and uncover crucial evidence related to data manipulation, exfiltration, or general system usage.

Timezone

Understanding the system's timezone is fundamental for accurately correlating all other time-stamped activities.

• Description: This artifact identifies the current system time zone.

• Location: The timezone information is located in the SYSTEM Hive, specifically at SYSTEM\CurrentControlSet\Control\TimeZoneInformation.

• Interpretation: Time activity is incredibly useful for correlation of activity across various logs and artifacts. Internal log files and date/timestamps will be based on the system's configured time zone. It's also vital for correlating information with other network devices, ensuring all timelines align accurately.

Cookies

Cookies offer valuable insights into a user's web browsing habits and online interactions.

• Description: Cookies give insight into what websites have been visited and what activities may have taken place there.

• Location: The location of cookies varies by browser and Windows version:

  • Internet Explorer:

    • IE6-8 and IE10: %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Cookies.

    • IE11: %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCookies.

    • Edge: %USERPROFILE%\AppData\Local\Packages\microsoft.microsoftedge_<APPID>\AC\MicrosoftEdge\Cookies.

  • Firefox:

    • XP: %USERPROFILE%\Application Data\Mozilla\Firefox\Profiles\<random text>.default\cookies.sqlite.

    • Win7/8/10: %USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\<randomtext>.default\cookies.sqlite.

  • Chrome:

    • XP: %USERPROFILE%\Local Settings\ApplicationData\Google\Chrome\User Data\Default\Local Storage.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Local Storage.

• Interpretation: While the general description highlights their use for understanding visited websites and activities, specific types like Google Analytics Cookies provide even deeper insights. For instance, __utma tracks unique visitors, including domain hash, visitor ID, cookie creation time, time of most and second most recent visits, and number of visits. __utmb aids in session tracking, noting domain hash, page views in the current session, outbound link clicks, and when the current session started. Lastly, __utmz focuses on traffic sources, revealing the domain hash, last update time, and number of visits.

Network History

This artifact is critical for identifying the networks a computer has connected to, providing a historical record of its network environments.

• Description: This artifact identifies networks that the computer has been connected to. This includes both wireless or wired networks, and helps to identify the domain name/intranet name, SSID, and Gateway MAC Address.

• Location: On Windows 7/8/10, these details are stored in the SOFTWARE HIVE at several locations:

  • SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged.

  • SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Managed.

  • SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache.

• Interpretation: Identifying intranets and networks a computer has connected to is incredibly important for investigations. Forensicators can determine the intranet name and the last time the network was connected to based on the last write time of the key. This also reveals any networks that have been connected to via a VPN. Furthermore, the MAC Address of the SSID for the Gateway could potentially be physically triangulated.

WLAN Event Log

For wireless network connections, the WLAN Event Log provides a detailed history, aiding in physical location determination.

• Description: The WLAN Event Log helps determine what wireless networks the system associated with and identify network characteristics to find location. Key Event IDs include:

  • 11000: Wireless network association started.

  • 8001: Successful connection to a wireless network.

  • 8002: Failed connection to a wireless network.

  • 8003: Disconnect from a wireless network.

  • 6100: Network diagnostics (found in the System log).

• Location: This log is found at Microsoft-Windows-WLAN-AutoConfig Operational.evtx.

• Interpretation: This artifact shows a historical record of wireless network connections. It contains both the SSID and BSSID (MAC address), which can be used to geolocate the wireless access point (though BSSID is not present on Win8+ systems).

Browser Search Terms

While often associated with general browsing history, browser artifacts also explicitly record search terms entered into search engines.

• Description: The browser's history records websites visited by date and time, with details stored for each local user account, including the number of times visited (frequency). It also tracks access to local system files. Crucially for this section, the history will also include the website history of search terms in search engines.

• Location: The locations vary by browser and operating system:

  • Internet Explorer:

    • IE6-7: %USERPROFILE%\Local Settings\History\History.IE5.

    • IE8-9: %USERPROFILE%\AppData\Local\Microsoft\Windows\History\History.IE5.

    • IE10-11, Edge: %USERPROFILE%\AppData\Local\Microsoft\Windows\WebCache\WebCacheV*.dat.

  • Firefox:

    • XP: %userprofile%\Application Data\Mozilla\Firefox\Profiles\<random text>.default\places.sqlite.

    • Win7/8/10: %userprofile%\AppData\Roaming\Mozilla\Firefox\Profiles\<random text>.default\places.sqlite.

  • Chrome:

    • XP: %USERPROFILE%\Local Settings\Application Data\Google\Chrome\User Data\Default\History.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\History.

• Interpretation: The history records can reveal many sites that list files opened from remote sites and downloaded to the local system. It also records access to files on websites that were accessed via a link. Specifically, the inclusion of search terms from search engines can indicate a user's intent or areas of interest, even if the resulting files or websites are no longer present.

System Resource Usage Monitor (SRUM)

SRUM provides a rich dataset of system performance and network activity, offering a broad view of applications and their resource consumption.

• Description: SRUM records 30 to 60 days of historical system performance. This includes applications run, the user account responsible for each, and application and bytes sent/received per application per hour.

• Location: SRUM data is found in the SOFTWARE Registry Hive and an associated database file:

  • Registry keys: SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SRUM\Extensions.

    • Specific GUIDs within Extensions include:

      • {d10ca2fe-6fcf-4f6d-848e-b2e99266fa89}: Application Resource Usage Provider.

      • {973F5D5C-1D90-4944-BE8E-24B94231A174}: Windows Network Data Usage Monitor.

      • {DD6636C4-8929-4683-974E-22C046A43763}: Windows Network Connectivity Usage Monitor.

  • Additional location: SOFTWARE\Microsoft\WlanSvc\Interfaces\.

  • Database file: C:\Windows\System32\SRU\.

• Interpretation: To interpret SRUM data, forensicators should use tools such as srum_dump.exe to cross correlate the data between the registry keys and the SRUM ESE Database. This correlation allows for a comprehensive understanding of an application's network activity and overall resource usage over a significant historical period.

By leveraging these powerful Windows artifacts, forensic investigators can meticulously piece together a comprehensive picture of a system's network engagements and even its movements, providing critical intelligence for any digital investigation.

Open/Save MRU

The "Open/Save MRU" (Most Recently Used) key is a fundamental artifact for tracking user interaction with files.

• Description: This key tracks files that have been opened or saved within a Windows shell dialog box. It represents a significant data set, encompassing not only web browsers like Internet Explorer and Firefox, but also a majority of commonly used applications.

• Location:

  • Windows XP: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU.

  • Windows 7/8/10: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePIDlMRU.

• Interpretation:

  • The "*" key within this artifact tracks the most recent files of any extension that were input in an Open/Save dialog.

  • Subkeys named after three-letter extensions (.???) store file information from the Open/Save dialog specifically by that extension.

Email Attachments

Email attachments are a primary method for file transfer, leaving distinct forensic traces on a system.

• Description: The email industry estimates that 80% of email data is stored via attachments. Since email standards fundamentally allow only text, attachments must be encoded using MIME/base64 format for transfer.

• Location:

  • Outlook XP: %USERPROFILE%\Local Settings\ApplicationData\Microsoft\Outlook.

  • Windows 7/8/10: %USERPROFILE%\AppData\Local\Microsoft\Outlook.

• Interpretation: Microsoft Outlook data files, such as OST and PST files, can be found in these locations. Additionally, forensic investigators should examine the OLK and Content.Outlook folders, as their roaming behavior can depend on the specific Outlook version used.

Skype History

Communication platforms like Skype often log file transfers, which can be critical for investigations.

• Description: Skype history maintains a log of chat sessions and files transferred from one machine to another. This logging functionality is enabled by default in Skype installations.

• Location:

  • Windows XP: C:\Documents and Settings\<username>\Application\Skype\<skype-name>.

  • Windows 7/8/10: C:\%USERPROFILE%\AppData\Roaming\Skype\<skype-name>.

• Interpretation: Each entry within the Skype history will include a date/time value and a Skype username associated with the recorded action.

Browser Artifacts (History)

While not directly focused on file downloads, browser history can provide crucial context and indirect evidence of such activities.

• Description: Browser history records websites visited by date and time. It stores details for each local user account, including the frequency (number of times visited). Importantly, it also tracks access to local system files. A "little-known fact" is that Internet Explorer history, in particular, records local, removable, and remote (via network shares) file access, providing an excellent means to determine which files and applications were accessed on the system daily. Search terms used in search engines may also be included.

• Location: The specific location varies by browser and Windows version:

  • Internet Explorer:

    • IE6-7: %USERPROFILE%\Local Settings\History\History.IE5.

    • IE8-9: %USERPROFILE%\AppData\Local\Microsoft\WindowsHistory\History.IE5.

    • IE10-11 & Edge: %USERPROFILE%\AppData\Local\Microsoft\Windows\WebCache\WebCacheV*.dat.

  • Firefox:

    • XP (v3-25): %userprofile%\Application Data\Mozilla\Firefox\Profiles\<random text>.default\places.sqlite.

    • Win7/8/10 (v26+): %userprofile%\AppData\Roaming\Mozilla\Firefox\Profiles\<random text>.default\places.sqlite.

  • Chrome:

    • XP: %USERPROFILE%\Local Settings\Application Data\Google\Chrome\User Data\Default\History.

    • Win7/8/10: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\History.

• Interpretation: Browser history can reveal numerous sites that listed files opened from remote sites and subsequently downloaded to the local system. It records access to files on websites that were accessed via a link. For Internet Explorer, entries stored in index.dat as [file:///C:/directory/filename.ext](file:///C:/directory/filename.ext) indicate local or remote file access, but this does not necessarily imply the file was opened within the browser itself.

Downloads (Browser Download Manager History)

Beyond general history, browsers often keep a dedicated log of downloaded files, offering direct evidence of download activity.

• Description: Firefox and Internet Explorer incorporate built-in download manager applications that meticulously record a history of every file downloaded by the user. This specific browser artifact is an "excellent" source of information regarding the websites a user has visited and the types of files they have been downloading from those sites.

• Location:

  • Firefox:

    • XP: %userprofile%\Application Data\Mozilla\Firefox\Profiles\<random text>.default\downloads.sqlite.

    • Win7/8/10: %userprofile%\AppData\Roaming\Mozilla\Firefox\Profiles\<random text>.default\downloads.sqlite.

  • Internet Explorer:

    • IE8-9: %USERPROFILE%\AppData\Roaming\Microsoft\Windows\IEDownloadHistory\.

    • IE10-11: %USERPROFILE%\AppData\Local\Microsoft\Windows\WebCache\WebCacheV*.dat.

• Interpretation: These download history artifacts offer a wealth of information, including:

  • The Filename, Size, and Type of the downloaded file.

  • The originating URL (Download from) and the Referring Page.

  • The File Save Location on the local system.

  • The Application Used to Open File.

  • The Download Start and End Times.

ADS Zone.Identifier

A subtle but powerful artifact, the "Zone.Identifier" is an Alternate Data Stream (ADS) that tags the origin of downloaded files.

• Description: Beginning with Windows XP SP2, whenever files are downloaded from the "Internet Zone" via a browser to an NTFS volume, an alternate data stream (ADS) named "Zone.Identifier" is automatically appended to that file. This stream serves as a digital marker, indicating the file's source.

• Location: This artifact is not a standalone file or registry entry; instead, it is an alternate data stream embedded directly within the downloaded file itself on an NTFS volume.

• Interpretation: The presence of the "Zone.Identifier" explicitly indicates that a file was downloaded from the "Internet Zone". This provides a potent piece of evidence for understanding the initial entry point of a specific file onto the system.

These artifacts, when analyzed individually and correlated, provide a robust framework for reconstructing file download events and understanding user behavior on a Windows system. They are indispensable tools in any digital forensic investigation.

UserAssist

The UserAssist artifact tracks GUI-based programs that have been launched from the desktop environment on a Windows system.

• Location: You'll find this data within the NTUSER.DAT HIVE, specifically at NTUSER.DAT\Software\Microsoft\Windows\Currentversion\Explorer\UserAssist\{GUID}\Count.

• Interpretation: The values stored here are ROT-13 Encoded, meaning they need to be decoded to reveal the actual program names. The specific GUID (Globally Unique Identifier) can tell you more about the type of execution:

  • For Windows XP, the GUID 75048700 signifies "Active Desktop".

  • For Windows 7, 8, and 10, CEBFF5CD indicates "Executable File Execution," while F4E57C4B points to "Shortcut File Execution".

Windows 10 Timeline

Windows 10 introduced a "timeline" feature that records recently used applications and files, accessible via the "WIN+TAB" key. This data is meticulously stored in a SQLite database.

• Location: The timeline data resides at C:\Users\<profile>\AppData\Local\ConnectedDevicesPlatform\<random-name-folder>\ActivitiesCache.db.

• Interpretation: This artifact provides crucial information about application execution and even the focus count per application, offering insights into user interaction and engagement with specific programs.

BAM/DAM

The Windows Background Activity Moderator (BAM), and its related artifact DAM, are particularly useful for understanding background processes.

• Location: On Windows 10 systems, these artifacts can be found in the SYSTEM hive: SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID} and SYSTEM\CurrentControlSet\Services\dam\UserSettings\{SID}.

• Interpretation: BAM and DAM provide the full path of the executable file that was run on the system, along with its last execution date/time. This can be vital for tracking both legitimate and unauthorized background activity.

Shimcache (AppCompatCache)

The Windows Application Compatibility Database, often referred to as Shimcache or AppCompatCache, is a powerful artifact used by Windows to address potential application compatibility issues with executables.

• Location:

  • On Windows XP, it's found at SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatibility.

  • For Windows 7, 8, and 10, the location is SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache.

• Interpretation: Any executable run on the Windows system could potentially be found in this key. This makes it an excellent resource for identifying systems where specific malware might have been executed. The time-based data within Shimcache can help determine the last time of execution or activity on the system.

  • Windows XP systems will contain at most 96 entries, and the LastUpdateTime is updated when files are executed.

  • Windows 7 systems can have up to 1,024 entries, but the LastUpdateTime field does not exist.

Amcache.hve

The Amcache.hve registry file is utilized by the ProgramDataUpdater task (associated with the Application Experience Service) to store data during process creation.

• Location: On Windows 7, 8, and 10, this file is located at C:\Windows\AppCompat\Programs\Amcache.hve.

• Interpretation: Amcache.hve contains an entry for every executable that has been run. This includes critical details such as the full path information of the executable, its $StandardInfo Last Modification Time, and the Disk volume from which it was executed. Notably, the First Run Time is equivalent to the Last Modification Time of the key itself. Furthermore, the SHA1 hash of the executable is also stored within the key, providing a valuable identifier for forensic analysis.

System Resource Usage Monitor (SRUM)

The System Resource Usage Monitor (SRUM) logs historical system performance, typically for 30 to 60 days. It records applications run, the user account responsible for each, and network activity (bytes sent/received) per application per hour.

• Location: SRUM data is found in a registry key: SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SRUM\Extensions\{d10ca2fe-6fcf-4f6d-848e-b2e99266fa89} (Application Resource Usage Provider), and in an ESE database at C:\Windows\System32\SRU\. Other extensions like {973F5D5C-1D90-4944-BE8E-24B94231A174} (Windows Network Data Usage Monitor) and {DD6636C4-8929-4683-974E-22C046A43763} (Windows Network Connectivity Usage Monitor) are also relevant.

• Interpretation: Tools like srum_dump.exe can be used to cross-correlate the data between the registry keys and the SRUM ESE Database. This allows investigators to see not only what was run but who ran it and the associated network activity, providing a comprehensive picture of resource utilization.

Jump Lists

Introduced with Windows 7, Jump Lists provide quick access to frequently or recently used items and tasks directly from the taskbar.

• Location: Jump List data is stored in the AutomaticDestinations folder: C:\%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations. Each file in this folder is uniquely prepended with the AppID of its associated application.

• Interpretation:

  • The Creation Time of an AppID file indicates the first time of execution of the application (or the first time an item was added to that AppID file).

  • The Modification Time indicates the last time the application was executed with a file open (or the last time an item was added to the AppID file).

  • Each file within the AutomaticDestinations folder is a separate LNK file, stored numerically from earliest to most recent. A list of common Jump List IDs can further aid in interpretation.

Last-Visited MRU

The Last-Visited MRU (Most Recently Used) artifact specifically tracks the executable used by an application to open files documented in the OpenSaveMRU key.

• Location:

  • On Windows XP, it's found at NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU.

  • On Windows 7, 8, and 10, the location is NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU.

• Interpretation: Beyond just the executable, this artifact also tracks the directory location for the last file accessed by that application. For instance, it could show that Notepad.exe was last run using the C:\%USERPROFILE%\Desktop folder.

Prefetch

Windows uses Prefetch files to improve system performance by pre-loading code pages of frequently used applications. The Cache Manager monitors file and directory references for each application and maps them into a .pf file.

• Location: Prefetch files are located at C:\Windows\Prefetch across Windows XP, 7, 8, and 10.

• Interpretation: The very existence of a .pf file indicates that an application was executed on the system. Each .pf file contains valuable information, including the last time of execution, the number of times the program was run, and the device and file handles used by the program.

  • The first execution time can often be inferred from the Creation Date of the .pf file (minus approximately 10 seconds).

  • The last execution time is indicated by the embedded last execution time within the .pf file or the Last modification date of the .pf file (minus approximately 10 seconds).

  • It's important to note limitations: Windows XP and 7 are limited to 128 Prefetch files, while Windows 8 and 10 can store up to 1024. Windows 8-10 Prefetch files will also contain the last 8 execution times.

These Windows artifacts—UserAssist, Windows 10 Timeline, BAM/DAM, Shimcache, Amcache.hve, SRUM, Jump Lists, Last-Visited MRU, and Prefetch—collectively offer a powerful toolkit for digital forensic investigators. By understanding their descriptions, locations, and interpretations, examiners can reconstruct program execution events, identify suspicious activity, and build a clearer picture of user and system behavior. Each artifact provides unique pieces of the puzzle, and their combined analysis often yields the most comprehensive insights into the digital story.