When it comes to investigating cloud environments, having the right tools can save a lot of time and effort. Today, I’ll introduce two free, powerful tools that are absolutely fantastic for log analysis within the Microsoft cloud ecosystem: Microsoft-Extractor-Suite  and Microsoft-Analyzer-Suite . These tools are easy to use, flexible, and can produce output in accessible formats like CSV and Excel, making them excellent resources for investigating business email compromises, cloud environment audits, and more. About Microsoft-Extractor-Suite The Microsoft-Extractor-Suite  is an actively maintained PowerShell tool designed to streamline data collection from Microsoft environments, including Microsoft 365 and Azur e. This toolkit provides a convenient way to gather logs and other key information for forensic analysis and cybersecurity investigations. Supported Microsoft Data Sources Microsoft-Extractor-Suite can pull data from numerous sources, including: Unified Audit Log Admin Audit Log Mailbox Audit Log Azure AD Sign-In Logs Azure Activity Logs Conditional Access Policies MFA Status for Users Registered OAuth Applications This range allows investigators to get a comprehensive picture of what’s happening across an organization’s cloud resources. ---------------------------------------------------------------------------------------------------------- Installation and Setup To get started, you’ll need to install the tool and its dependencies. Here’s a step-by-step guide: Install Microsoft-Extractor-Suite : Install-Module -Name Microsoft-Extractor-Suite Install the PowerShell module Microsoft.Graph  (for Graph API Beta functionalities): Install-Module -Name Microsoft.Graph Install ExchangeOnlineManagement  (for Microsoft 365 functionalities): Install-Module -Name ExchangeOnlineManagement Install the Az module  (for Azure Activity log functionality): Install-Module -Name Az Install the AzureADPreview module  (for Azure Active Directory functionalities): Install-Module -Name AzureADPreview Once the modules are installed, you can import them using: Import-Module .\Microsoft-Extractor-Suite.psd1 ---------------------------------------------------------------------------------------------------------- Note:  You will need to sign in to Microsoft 365 or Azure with appropriate permissions(Admin level access, included P1 or higher access level, or an E3/E5 license) before using Microsoft-Extractor-Suite functions. ---------------------------------------------------------------------------------------------------------- Getting Started First, connect to your Microsoft 365 and Azure environments: Connect-M365 Connect-Azure Connect-AzureAZ From here, you can specify start and end dates, user details, and other parameters to narrow down which logs to collect. The tool captures output in Excel format by default, stored in a designated output folder. Link :- https://microsoft-365-extractor-suite.readthedocs.io/en/latest/ ---------------------------------------------------------------------------------------------------------- Example Log I collected: One drawback to keep in mind is that logs are collected one by one. example first u collect MFA logs second again you written command and collected Users log. Another thing to keep in mind is if u do not provide path output will be capture under default folder where script is present. ---------------------------------------------------------------------------------------------------------- You might have question why two different suite? Answer is because there is script name Microsoft-Analyzer-Suite developed by evild3ad. This suite offers a collection of PowerShell scripts specifically designed for analyzing Microsoft 365 and Microsoft Entra ID data, which can be extracted using the Microsoft-Extractor-Suite. Current Analysis support by Microsoft-Analyzer-Suite is: Link: https://github.com/evild3ad/Microsoft-Analyzer-Suite ---------------------------------------------------------------------------------------------------------- Before I start, I will show you folder structure of both the tools: Microsoft-Extractor-Suite Microsoft-Analyzer-Suite-main Analyzer-Suit allows You can also add specific IP addresses, ASNs, or applications to a whitelist by editing the whitelist folder in the Microsoft-Analyzer-Suite directory. ------------------------------------------------------------------------------------------------------------ Lets start: I will show you two logs capture and analyzed is message trace log other one Unified audit log all collect using the script Microsoft extractor suite and than I will use Microsoft-Analyzer-Suite. Collecting Logs with Microsoft-Extractor-Suite Now, let’s go over collecting logs. Here’s an example command to retrieve the Unified Audit Log  entries for the past 90 days for all users: Get-UALAll After running this, the tool will output data in Excel format to a default folder. However, you may need to combine multiple excel file into one .csv file. Because Anlyzer suite script only run using .csv. ------------------------------------------------------------------------------------------------------------ Combining CSV Files into One Excel File When working with large data sets, it's more efficient to combine multiple log files into a single file. Here’s how to do this in Excel: Place all relevant CSV files in a single folder. Open a new Excel spreadsheet and navigate to Data > Get Data > From File > From Folder . Select the folder containing your CSV files and click “Open”. From the Combine  drop-down, choose Combine & Transform Data . This option loads your files into the Power Query Editor , where you can manipulate and arrange the data. In the Power Query Editor, click OK  to load your combined data. Edit any column formats, apply filters, or sort the data as needed. Once done, go to Home > Close & Load   Once Done Output will be look like below: But to ensure compatibility with Microsoft-Analyzer-Suite save the file as a .csv Using Microsoft-Analyzer-Suite for Log Analysis With your data collected and organized, it’s time to analyze it with Microsoft-Analyzer-Suite . UAL-Analyzer.ps1 Before using UAL-Analyzer.ps1 script there are few dependencies u have to make sure these are installed for running script First is creating is IPinfo account its free. https://ipinfo.io/signup?ref=cli ImportExcel  for Excel file handling (PowerShell Module) Install-Module -Name ImportExcel https://github.com/dfinke/ImportExcel IPinfo CLI (Standalone Binary) https://github.com/ipinfo/cli xsv (Standalone Binary) https://github.com/BurntSushi/xsv To install xsv: Now as I had WSL (I used command git clone https://github.com/BurntSushi/xsv.git ) You can download folder (as you feel comfortable) Once dependencies are set up, configure your IPinfo  token by pasting it into the UAL-Analyzer  script. To locate this in the script: Open UAL-Analyzer.ps1  with a text editor like Notepad++, search for the token variable, and paste your token there. ------------------------------------------------------------------------------------------------------------- As for latest Microsoft Analyzer suite There is another script called config.ps1 add token here If you are using older analyzer suite, Than its same for you but if not there is changes in script.. ------------------------------------------------------------------------------------------------------------- Running the Analysis Script For Unified Audit Logs, use the UAL-Analyzer  script. For example: .\UAL-Analyzer.ps1 "C:\Path\To\Your\CombinedUALLog.csv" -output "C:\Path\To\Output\" Once script ran successfully and output collected you will get pop up ------------------------------------------------------------------------------------------------------------ Lets check the output: As per screenshot , You can see output will be in CSV, XLSX in both format. Now question arise why there is same output in different. This is because the XLSX will contain output in coloured format, if something suspicious found it will be highlighted automatically. Where as csv will be in no highlighted format. Example of xlsx: Example of CSV: Folder Suspicious Operation: Kind note scripts are still getting updated and modified if you open GitHub you might find newer version it might work better for current this will output for me it make thing easy hope it do for you as well. ------------------------------------------------------------------------------------------------------------ Second Log we are going to talk about Message Trace logs Command : (This will collect all logs) Get-MessageTraceLog Screenshot of Output: Next step is Combined all excel into one(.csv format). Once done run MTL-Analyzer script .\MTL-Analyzer.ps1 "C:\Path\To\Your\CombinedMTLLog.csv" -output "C:\Path\To\Output\" (Make sure before running add token details inside the script than run the script) Conclusion By combining Microsoft-Extractor-Suite  and Microsoft-Analyzer-Suite , you can effectively streamline log collection and analysis across Microsoft 365 and Azure environments. While each suite has its own focus, together they provide an invaluable resource for incident response and cybersecurity. Now that you have the steps, you can test and run the process on your own logs. I hope this guide makes things easier for you! See you, and take care! Akash Patel

When investigating digital forensics cases, confirming which files were deleted or previously existed is crucial . Whether tracking user activity or validating forensic evidence, understanding where and how to find artifacts plays a key role in uncovering the truth. Many articles on my website discuss different deleted items and file existence artifacts. However, putting them all together in a structured way helps streamline forensic investigations. This article serves as a reference guide , consolidating various forensic artifacts that indicate deleted items and file existence , along with their advantages, disadvantages, and relevant analysis techniques. ---------------------------------------------------------------------------------------------------------- Thumbnail Cache (Thumbs.db / Thumbcache) Artifact:  Thumbs.db (Windows XP) and Thumbcache (Windows Vista and later) Forensic Importance:  Stores thumbnail previews of images and documents, even after deletion. Article: Understanding and Managing Thumbnail Cache in Windows: Tools thumbcache_viewer_64 ---------------------------------------------------------------------------------------------------------- Recycle Bin Forensic Importance:  Stores deleted files before permanent removal. Article: Windows Recycle Bin Forensics: Recovering Deleted Files Analyzing Recycle Bin Metadata with RBCmd and $I_Parse ---------------------------------------------------------------------------------------------------------- User Typed Paths Registry Path:  HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths Forensic Importance:  Tracks file paths typed in the Windows Explorer address bar. Article: Windows Registry Artifacts: Insights into User Activity (Typed Path) ---------------------------------------------------------------------------------------------------------- Windows Search Database Artifact:  Windows.edb Forensic Importance:  Stores indexed metadata of files searched on the system. Article: Unlocking Windows Search Indexing for Forensics: A Deep Dive A Deep Dive into Windows Search Database Parsing (WinSearchDBAnalyzer / SQLite / SIDR) ---------------------------------------------------------------------------------------------------------- Search WordWheelQuery Registry Hive:  NTUSER.DAT Registry Key:  NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery Forensic Importance:   Stores user-searched keywords from the Start menu. Analysis Tool:   Registry Explorer ---------------------------------------------------------------------------------------------------------- Conclusion Analyzing deleted files and file existence artifacts plays a vital role in forensic investigations. By leveraging Windows registry artifacts, cache files, and search history, investigators can reconstruct user activity, track deleted files, and build a strong case with digital evidence. A structured approach to investigating these artifacts ensures efficiency and thoroughness in forensic analysis. When investigating digital forensics cases, confirming which files are deleted or file existed is crucial. Whether tracking user activity or validating forensic evidence, understanding where and how to find artifacts plays a key role in uncovering the truth. -------------------------------------------------Dean------------------------------------------------------

WinSearchDBAnalyzer Introduction One of the most powerful tools for parsing the Windows Search Database  is WinSearchDBAnalyzer . This tool effectively makes the contents of the Windows search index  available for forensic investigation. It currently supports parsing ESE (Extensible Storage Engine) database format  up to Windows 10 (Windows.edb files)  and can analyze already exported files or extract the database from a live system. Key Features Provides control over which metadata fields to extract. L Can parse both live and exported Windows.edb files. Can parse corrupt ESE databases, but repairing them beforehand ensures better results. Organizes indexed items by file extension , allowing easy filtering of specific file types (.docx, .zip, etc.). Investigators can explore indexed content structured as folders . Metadata columns can be sorted for better analysis, and a preview pane  displays file details upon selection. The Find  search bar enables keyword searches across multiple metadata fields, including filenames, folder names, and indexed file content ( Search_AutoSummary  field). Carves deleted records from unallocated database space, which may contain traces of previously deleted files. Practical Usage Example In an investigation, a search for "secret"  filtered across all files and metadata. A file named "akash.pdf"  was identified, and its extracted metadata was visible in the preview pane. The metadata included file system timestamps  and indexed content , revealing that the term "secret" appeared within the indexed content (Search_AutoSummary field). Useful Search Queries Practical search tips To view visited URLs : Search for "http://"  or "https://" To find internet queries : Search for "q="  or "query=" To locate records by date: Search for "2021-11-" To view all records : Select "ALL" To recover deleted records: Check "Unknown" Note:  Parsing a full Windows Search Database can be slow due to the large volume of indexed data. Esedatabaseview ---------------------------------------------------------------------------------------------------------- SQLite-Based Windows Search Index Parsing While WinSearchDBAnalyzer automates parsing, manual review  is also possible using a SQLite database viewer. Key SQLite Databases in Windows 11 1. Windows-gather.db Path:   C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows-gather.db This database provides a high-level overview  of indexed files and folders, allowing full path reconstruction . Important Fields in SystemIndex_Gthr Table: ScopeID : Foreign key linked to Scope  in SystemIndex_GthrPth  table (to find parent folder). DocumentID : Unique identifier for a file, linked to WorkID  in Windows.db . FileName : Name of the indexed item. LastModified : Last modified time (Windows FILETIME format). Important Fields in SystemIndex_GthrPth Table: Scope : Foreign key linked to ScopeID . Parent : Identifier for parent folder. Name : Folder name. 2. Windows.db Path:   C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db Stores a massive collection of metadata  for indexed files. Important Fields in SystemIndex_1_PropertyStore Table: WorkId : Unique identifier for an indexed item. ColumnId : Identifies metadata property type (linked to SystemIndex_1_PropertyStore_Metadata). Value : Metadata information. Important Fields in SystemIndex_1_PropertyStore_Metadata Table: Id : Property ID (linked to ColumnId in PropertyStore table). UniqueKey : Describes metadata property type. Example of Parsing Windows.db ---------------------------------------------------------------------------------------------------------- WinEDB and Windows 11 Search Index Changes Their WinEDB project  provides useful SQL queries  for analyzing the new database schema. These queries can be executed in DB Browser for SQLite  to extract human-readable data. 📌 Reference:   GitHub – kacos2000 WinEDB Search Index Tool --------------------------------------------------------------------------------------------------------- Search Index DB Reporter (SIDR) SIDR is an incredibly effective tool for parsing the Windows Search Index Database. It can parse both the original Extensible Storage Engine (ESE) database found in Windows 10 and the newer SQLite database format introduced in Windows 11. Command: E:\Windows Forensic Tools\window.edb.db analysis>sidr.exe -f csv -o "C:\Users\Akash's\Downloads" "C:\ProgramData\Microsoft\Search\Data\Applications\Windows" SIDR is designed to export a curated view of well-known and important items from the database. The output from SIDR is divided into three reports: File Report Activity History Report Internet History Report While the executable exports pre-defined metadata types, advanced users can modify the report output by editing the YAML file within the source code (compilation of the source code would be required). File Report The File Report provides a curated list of metadata for indexed files. It includes: Full file name and path Created, modified, and accessed timestamps File size and owner Indexed content (System_Search_AutoSummary) System_Search_GatherTime (timestamp when the file information was recorded in the database) The System_Search_GatherTime  is particularly useful because it offers another indicator of when a file was present on the system , independent of file creation time. However, it is important to note that SIDR extracts only a subset of the available metadata. Out of potentially hundreds of metadata types, only about ten are included in this report. If an investigation requires more detailed metadata, tools like WinSearchDBAnalyzer (for Windows 10)  or manual SQLite database parsing (for Windows 11) can supplement the extracted data. Internet History Report The Internet History Report extracts browser-related items stored in the Windows Search Index. Currently, this report includes data from Internet Explorer  and Microsoft Edge . It records: Visited URL Page title Date visited System_Search_GatherTime (when the information was recorded in the database) This report can be particularly useful if browser history is missing from primary browser databases. However, it is important to note that InPrivate browsing sessions are not stored  in the Search Index. Activity History Report The Activity History Report provides insights into user activity recorded in the Windows Search Index. It aggregates multiple System_Activity  metadata types, revealing: Files opened by a user Applications used to open those files Start and end times of the activity (providing duration information) A key forensic insight is the Windows Search Index does not delete Activity History information when the original file is removed . This means that even if a suspect deletes or renames a file, uninstalls an application, or attempts other cleanup actions, relevant forensic data may persist in the Search Index. ------------------------------------------------------------------------------------------------------------- Conclusion The SIDR  tool is designed by investigators, for investigators. It efficiently extracts key forensic data from the Windows Search Index without overwhelming analysts with unnecessary information. Advanced users can further customize the tool by modifying the source code and integrating it with additional analysis tools like Velociraptor  or WinSearchDBAnalyzer . -------------------------------------------------Dean---------------------------------------------

Windows search indexing has been an integral part of the operating system since Windows 2000, continuously evolving to improve search efficiency. By default, it is enabled from Windows XP onward, silently cataloging an extensive amount of user data, including file names, metadata, and even partial content of certain file types. While this feature enhances the user experience, it also creates a valuable forensic artifact: the Windows Search Database (Windows.edb) . ------------------------------------------------------------------------------------------------------------- Understanding Windows Search Indexing Windows search relies on the Extensible Storage Engine (ESE) database to store indexed content. This database, known as Windows.edb , contains references to thousands of files, emails, and other indexed data, providing a powerful resource for forensic investigations. Where to Find Windows.edb Windows 11 Microsoft continues to surprise us with its choice of database formats. Windows 11 version 22H2 introduced a new database format to SQLite. Two SQLite databases hold the most interesting data: C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows db C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows-gather.db Windows Vista - Windows 10:   C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb Windows XP:   C:\Documents and Settings\All Users\Application Data\Microsoft\Search\Data\Applications\Windows\Windows.edb ---------------------------------------------------------------------------------------------- Why is Windows.edb/.db Important for Forensics? Windows.edb provides a wealth of information that can help reconstruct user activities. It stores: File and folder names with metadata Indexed email data (subject, sender, and message body in Outlook) Indexed OneNote, SharePoint, and OneDrive content Search query history References to deleted files With indexing covering over 900 file types by default , analysts can extract data from an extensive variety of file formats. ---------------------------------------------------------------------------------------------- Tools for Parsing Windows.edb Historically, analyzing Windows.edb was challenging, requiring manual examination with generic ESE database parsers. Fortunately, several open-source tools now provide efficient ways to extract and analyze its contents: Windows.edb Analysis Tools: WinSearchDBAnalyzer   Search Index DB Reporter (SIDR)   NirSoft ESE Database View   Windows.db Analysis Tools: Db Browser for Sqlite ---------------------------------------------------------------------------------------------- Challenges with Windows.edb Analysis Windows.edb/.db operates differently from traditional database formats. Originally designed for high-performance applications like Microsoft Exchange, ESE databases use a write-ahead model , meaning: Data is first written into log files before being committed to the main database. Uncommitted data can persist in memory for hours or even days. Extracting Windows.edb in a forensic investigation may result in a “dirty” database —one that hasn't consolidated its latest log entries. ---------------------------------------------------------------------------------------------- Handling a Dirty Windows.edb Database When dealing with a dirty  (incomplete) Windows.edb database , forensic analysts have two options: Work with the database as-is  – This means some uncommitted data will be missing, and certain tools may not be able to parse it properly. Recover the database using esentutl  – This built-in Windows utility allows database integrity checking, defragmentation, and recovery. Using esentutl for Recovery and Repair Windows includes esentutl.exe , a command-line tool to manage ESE databases. Key commands include: Check database status: If the database is dirty , it needs to be repaired. esentutl /mh Windows.edb Attempt database recovery: This applies uncommitted log data to the database. esentutl /r edb /d Repair a corrupted database (as a last resort): ⚠️ This will discard uncommitted data, so use it only if necessary. esentutl /p Windows.edb Best Practices for ESE Database Analysis Always work on a copy  of Windows.edb/.db and its associated log files. Use the same Windows version  for recovery as the system where the database was acquired. If possible, extract log files  along with Windows.edb to ensure data consistency . Avoid modifying original evidence whenever possible —use forensic tools that support read-only parsing Conclusion Windows Search Indexing is a double-edged sword: while it enhances user experience, it also creates an invaluable forensic artifact  in Windows.edb. By leveraging modern parsing tools and understanding ESE database behavior, forensic investigators can extract critical evidence, reconstruct user activities, and even recover deleted data. By mastering Windows.edb analysis, forensic professionals gain access to one of the most overlooked but powerful artifacts in Windows forensics . Whether you're performing an investigation or simply exploring how Windows manages search indexing, understanding this artifact can provide deep insights into user activity on a system. -------------------------------------------Dean--------------------------------------------------

USB devices often come with a unique identifier called the iSerialNumber. Why the iSerialNumber Matters? The iSerialNumber is a hardware-based unique identifier. I f you plug the same USB device into multiple computers, each system should log the same iSerialNumber . This makes it incredibly useful for tracking where a device has been used—whether for forensic investigations or enterprise-level monitoring. Exceptions and Windows-Generated Identifiers Unfortunately, not all USB devices report an iSerialNumbe r. If the device lacks this value, Windows generates an identifier for it. You can easily recognize these by looking at the second characte r—Windows-generated IDs will have an ampersand (&). For profiling on a single system, it doesn’t matter whether the identifier is hardware-based or Windows-generated, as both will uniquely identify the device on that system. However, tracking the same device across multiple systems can be problematic if it lacks a unique iSerialNumber since Windows will assign a different identifier on each system. -------------------------------------------------------------------------------------------------------- Challenges with Poorly Designed Devices Low-quality USB devices or adapters can cause confusion. They might report inconsistent identifiers, even on the same system. This can make a single device appear as multiple devices. When this happens, you’ll need to rely on other identifiers like Vendor ID (VID), Product ID (PID), volume names, or the Volume Serial Number to clarify thing s. Extracting the iSerialNumber If you need to retrieve the iSerialNumber from a physical device. Using Hardware Tools A USB write blocker or similar device is the safest way to extract the iSerialNumber. Using Software Tools You can also use tools like Microsoft’s USBView  (part of the Windows Software Development Kit). Physical Inspection Sometimes, USB devices have identifying information engraved on their casing. However, be cautious—this number doesn’t always match the actual iSerialNumber stored in the hardware. ------------------------------------------------------------------------------------------------------------- The SCSI Serial Number: An Alternate Identifier In addition to the iSerialNumber , USB devices often have another serial number called the SCSI Serial Number . Here’s how the two differ: The iSerialNumber is used by the USB subsystem and is typically stored in the device descriptor. The SCSI Serial Number comes from the device’s storage subsystem. These numbers may not match, and forensic tools can sometimes show one but not the other. This can create challenges when trying to correlate data between system logs and the Windows Registry. How to Identify Both Serial Numbers Starting with Windows 10, Microsoft’s Partition/Diagnostic Event Log  provides detailed information about connected devices, including both the iSerialNumber and the SCSI Serial Number. Here’s how you can access them: Run this PowerShell command with a USB device plugged in: Get-WmiObject win32_diskdrive | select-object model, serialnumber, pnpdeviceid, deviceid Open the Microsoft-Windows-Partition/Diagnostic.evtx  log. You’ll find: The iSerialNumber (under the "ParentId" field) The SCSI Serial Number (under "SerialNumber") You can also cross-reference these with other details like the VID, PID, a and device capacity to distinguish devices. ------------------------------------------------------------------------------------------------------------- When dealing with USB devices, it's essential to recognize the difference between standard USB devices and USB Attached SCSI (UASP) devices. UASP devices store information under SYSTEM\\Enum\SCSI key, which requires some unique steps to extract useful forensic data. Profiling UASP Devices: Step-by-Step Identify the Device Look for your device under SYSTEM\\Enum\USB. If the Service value references UASPStor and the DeviceDesc mentions UASP, you’ve found a UASP device. Note the ParentIdPrefix  value; it’s a key link to finding related data in the SCSI registry key. Correlate Data in the SCSI Key Use the ParentIdPrefix  value to find the matching entry under SYSTEM\\Enum\SCSI. This key will reveal manufacturer details, product information, and additional timestamps for the device. Pay special attention to the DiskID  and iSerialNumber . Note : Windows prepends to iSerialNumbers for UASP devices. Use Tools for Simplified Analysis Tools like Registry Explorer offer plugins to simplify analysis of the SCSI key , providing extracted information in a table format for easier documentation. ------------------------------------------------------------------------------------------------------------- Handling Windows USB Cleanup Activities Recent versions of Windows have implemented cleanup mechanisms that can impact USB-related forensic evidence. Here’s what you need to know: Scheduled Cleanup Tasks Early versions of Windows 10 (and Windows 8) used the Plug and Play Cleanup  task to remove USB-related data for devices not detected in the last 30 days. Later versions of Windows 10 removed this specific task but introduced similar cleanup during major updates. This cleanup means USB artifacts may only persist until the next major Windows update , especially in keys like USBSTOR, USB, SCSI, and even the critical Microsoft-Windows-Partition/Diagnostic log. Keys and Logs That Survive Cleanup Some artifacts remain even after cleanup routines, providing critical data for forensic profiling: MountedDevices : Tracks drive letters and volume information. Windows Portable Devices : Identifies devices used on the system. MountPoints2 : Logs drive mount points for user-specific activity. setupapi.dev.log : Records device installation and removal events (though only for a limited time). Volume Shadow Copies : Stores older versions of registry keys and logs, often allowing recovery of deleted artifacts. ------------------------------------------------------------------------------------------------------------- Recovering Data from Cleanup with DeviceMigration Keys Windows archives device data during cleanup or updates in the DeviceMigration keys . These keys allow forensic analysts to go back in time and recover information about devices previously connected to the system. Key locations include: SYSTEM\\Control\DeviceMigration SYSTEM\Setup\Upgrade\PnP\CurrentControlSet\Control\DeviceMigration What Can You Extract? While not all original data is retained , these keys store: Manufacturer and Product Information VID/PID iSerialNumber ParentIdPrefix DiskID LastPresentDate : A 64-bit timestamp showing when the device was last connected. ------------------------------------------------------------------------------------------------------------- Best Practices for Forensic USB Analysis Correlate Data Sources Use DeviceMigration keys to cross-reference older device data with other longer-lasting keys l ike MountedDevices or MountPoints2. This helps identify details like drive letters, volume names, and user-specific usage. Utilize Archived Data Windows.old Folder : Created during major updates, it contains older versions of registry hives and logs that may still hold critical USB-related data. Volume Shadow Copies : If enabled, these snapshots allow you to recover older file system and registry data. Leverage Forensic Logs Logs like setupapi.dev.log and event logs (other than Microsoft-Windows-Partition/Diagnostic) remain useful even after cleanup , though their retention period is often limited. ------------------------------------------------------------------------------------------------------------- Conclusion: By understanding UASP device profiling, cleanup mechanisms, and how to recover deleted artifacts, forensic analysts can still extract valuable information even in challenging scenarios. -------------------------------------------------------Dean--------------------------------

Cloud storage has evolved beyond simple local folder synchronization . Newer technologies, like Files On-Demand  and Smart Sync , allow users to interact with cloud-stored files without downloading them . This presents new forensic challenges  since not all files exist locally , and standard filesystem artifacts may be missing . We’ll cover: ✅ How OneDrive’s new sync model affects forensic investigations ✅ Tracking cloud-only files & deleted data ✅ Using OneDrive’s forensic artifacts to recover missing evidence ------------------------------------------------------------------------------------------------------------- 1️⃣ Understanding "Hydrated" vs. "Dehydrated" Files in OneDrive Microsoft OneDrive introduced Files On-Demand  in Windows 10 (version 1709) , allowing users to view all cloud-stored files without downloading them . 📌 OneDrive File Status Icons: 🌥 Blue Cloud:  File is only in the cloud  (dehydrated) ✅ Green Check (Hollow):  File was opened recently  and cached locally ✅ Green Check (Filled):  File is fully downloaded and always available locally 💡 Why This Matters: S ome files may have never existed on the local system  (dehydrated). A forensic image may miss cloud-only files  unless OneDrive logs or sync databases are analyzed. ------------------------------------------------------------------------------------------------------------- 2️⃣ Where to Find OneDrive Artifacts Even if files are not stored locally , OneDrive leaves forensic traces  in multiple locations: 📍 OneDrive Sync Folder (Locally Stored Files) %UserProfile%\OneDrive\ 💡 Includes only hydrated (downloaded) files. Cloud-only files are missing. 📍 OneDrive Settings & Metadata %UserProfile%\AppData\Local\Microsoft\OneDrive\settings\Personal\ 💡 Contains sync logs, database files, and user metadata. 📍 OneDrive Logs (File Sync History) %UserProfile%\AppData\Local\Microsoft\OneDrive\logs\ 💡 Records uploads, downloads, and file deletions. Stores up to 30 days of logs. 📍 OneDrive Registry Keys (User Account & Sync Details) NTUSER\Software\Microsoft\OneDrive\Accounts\Personal 💡 Tracks the OneDrive sync folder location and last authentication time. ------------------------------------------------------------------------------------------------------------- 3️⃣ Investigating Cloud-Only Files Using OneDrive Sync Database 📌 SyncEngineDatabase.db (SQLite) – The Most Important OneDrive Artifact Since March 2023 , Microsoft migrated OneDrive’s file-tracking system to SQLite . The SyncEngineDatabase.db  file stores: ✅ Cloud-only file records (even if never downloaded) ✅ File metadata (timestamps, size, folder structure) ✅ Synchronization status (e.g., cloud-only, synced, shared) ✅ quickXorHash values (instead of SHA1) for file integrity %UserProfile%\AppData\Local\Microsoft\OneDrive\settings\Personal\SyncEngineDatabase.db Key Tables in SyncEngineDatabase.db 🔹 od_ClientFile_Records (Tracks OneDrive Files) Column Description fileName Name of the file resourceID Unique identifier for each file lastChange Last modification time (Unix Epoch format) size File size fileStatus Synchronization status sharedItem Indicates if the file was shared localHashDigest quickXorHash value for file integrity 📌 File Status Codes: 2 = Available Locally  (Downloaded) 5 = Excluded  (Ignored by sync) 6 = Not Synced 8 = Available Online Only  (Cloud-only) 💡 Forensic Use: Identifies files that only exist in the cloud  (fileStatus = 8). Tracks deleted or moved files  by correlating with OneDrive logs. 🔹 od_ClientFolder_Records (Tracks OneDrive Folders) Column Description folderName Name of the folder resourceID Unique folder identifier folderStatus Sync status (Synced, Not Synced, etc.) sharedItem Indicates if the folder was shared 📌 Folder Status Codes: 9 = Synced 10 = Not Synced 11 = Not Linked ------------------------------------------------------------------------------------------------------------- 4️⃣ Investigating Deleted OneDrive Files When a user deletes a file, it disappears from all synced devices and the cloud . However, OneDrive and Windows keep hidden traces . 💾 Recovering Deleted OneDrive Files ✅ Option 1: Windows Recycle Bin Locally deleted OneDrive files may still be in: C:\$Recycle.Bin\ ✅ Option 2: OneDrive Recycle Bin (Cloud-Based Recovery) OneDrive Personal:  Deleted files stored for 30 days OneDrive for Business:  Deleted files stored for 93 days URL to check deleted OneDrive files: https://onedrive.live.com/ ✅ Option 3: OneDrive Sync Logs & SafeDelete.db SafeDelete.db (SQLite)  stores deleted file records before syncing. Deleted file traces may persist in logs & databases  before being purged. 📍 Location: %UserProfile%\AppData\Local\Microsoft\OneDrive\settings\Personal\SafeDelete.db 💡 Forensic Use: Tracks who deleted a file and when . Identifies files deleted long ago using SQLite carving techniques . ------------------------------------------------------------------------------------------------------------- 5️⃣ Tracking Shared Files & External Data Sources OneDrive allows users to sync shared folders  from other users, Microsoft Teams, or SharePoint. 📌 Registry Key for Shared Folders (Tenants) NTUSER\Software\Microsoft\OneDrive\Accounts\Personal\Tenants 💡 Tracks external data sources, including: ✅ Files shared from other OneDrive accounts ✅ SharePoint & Teams folder synchronization 📌 Forensic Use: Investigators must check this key to avoid missing shared folders stored outside the default OneDrive folder . ------------------------------------------------------------------------------------------------------------- 6️⃣ Locating OneDrive Log Files & Understanding Their Purpose 📍 Log File Location: %UserProfile%\AppData\Local\Microsoft\OneDrive\logs\ OneDrive logs track interactions  between the local system and the cloud, recording: ✅ File synchronization events  (uploads, downloads, deletions) ✅ File modifications (renames, moves, metadata changes) ✅ Cloud-only file interactions (Files On-Demand downloads, file access timestamps) 📌 Common OneDrive Log File Extensions File Extension Purpose .odl Main log file tracking file activities .odlsent Logs of files successfully synced .odlgz Compressed logs (older entries) .aodl Advanced logging (for internal Microsoft use) 📌 Important Notes: Log filenames are anonymized  (filenames replaced with obfuscated values). Older OneDrive versions used ObfuscationStringMap.txt to decode filenames , but newer versions encrypt logs with Bcrypt  (key stored in general.keystore). 🔍 Forensic Tools to Parse OneDrive Logs: OneDriveExplorer  (by Brian Maloney) Python scripts by Yogesh Khatri A big thank you to Brian Maloney for reaching out to me regarding issue i said that tool is not working for me. I must admit, I had forgotten to recheck it. Today, I downloaded the latest version of OneDrive Explorer from the github, and it appears to be working perfectly. The tool is now parsing the .odl logs as expected, and OneDrive Explorer is successfully displaying the data. Parsing ODL logs getting output in csv ------------------------------------------------------------------------------------------------------------ 7️⃣ Investigating OneDrive File Activity Using .ODL Logs 📌 OneDrive logs are essential for tracking: ✅ File uploads & downloads  (date, time, file size) ✅ File deletions & renames ✅ Cloud-only file access (even if the file never existed locally) 🔹 Recovering Deleted File Activity from .ODL Logs Even after a file is deleted from OneDrive, remnants remain in .ODL logs . Look for file delete events  (Deleted column in OneDriveExplorer output). Correlate timestamps  with Windows Recycle Bin logs ($Recycle.Bin). Check cloud-based OneDrive Recycle Bin  (retains files for 30–93 days). 🔍 Cross-reference OneDrive logs with: Windows Event Logs  (tracks OneDrive file modifications) Volume Shadow Copies  (may store previous versions of OneDrive files) ------------------------------------------------------------------------------------------------------------- OneDrive’s Setting Important File: ------------------------------------------------------------------------------------------------------------- OneDrive’s Evolving Forensic Challenges Microsoft OneDrive has transformed digital forensics , requiring investigators to look beyond standard filesystem artifacts . We will explore more about OneDrive  in the next article (I nvestigating OneDrive for Business: Advanced Forensics & Audit Logs ) , so stay tuned! See you in the next one.

If you're digging into Windows forensic artifacts, SRUM (System Resource Usage Monitor) data is a goldmine. But manually decoding the SRUM database? That’s a nightmare. Thankfully, Mark Baggett’s free tool, SRUM_DUMP , does all the heavy lifting for us. ------------------------------------------------------------------------------------------------------------- What is SRUM_DUMP? SRUM_DUMP processes the SRUDB.dat database and generates an Excel spreadsheet with separate tabs for each table in the database. It also correlates some fields from the Windows Registry, making it easier to identify network connections, system usage, and even user activities. This tool is a game-changer for forensic analysts. It provides structured Excel templates that can be customized for better data visualization, such as calculating network connection times or applying conditional formatting. ----------------------------------------------------------------------------------------------------------- How to Use SRUM_DUMP Let’s get straight to the process. After extracting your forensic image or pulling out the SRUDB.dat  file and the SOFTWARE  registry hive, follow these steps: Launch SRUM_DUMP  and click the Browse  button to select the SRUDB.dat  file. If you're analyzing a mounted image, you’ll likely find it in: E:\Windows\System32\SRU\SRUDB.dat Choose an output folder  where the processed Excel sheet will be saved. Stick with the default Excel template  (unless you have a specific need to change it, which is rare). Provide the SOFTWARE registry hive   to allow SRUM_DUMP to cross-reference network and user names. Since incident response often deals with systems that weren’t properly shut down, the registry hive might be in a dirty state. Ideally, use a cleaned-up version for accuracy. Click OK , and within seconds, you'll have a neatly structured Excel file ready for analysis. ----------------------------------------------------------------------------------------------------------- Output ----------------------------------------------------------------------------------------------------------- Understanding SRUM Data Now, let’s break down what kind of forensic insights we can extract from SRUM data. 1. Network Connectivity Usage Table This table logs when and where a system connected to a network. Here’s what you’ll see: Column B  – Timestamp of when the connection was recorded. Column E  – Network interface used (e.g., Wi-Fi, Ethernet). Column F  – Network name (SSID of Wi-Fi connections). Column G  – Duration of the connection. Column H  – Start time of the connection. In some cases, overlapping connections suggest a system went into sleep or hibernate mode between sessions. Investigators can use this data to establish movement patterns or even detect suspicious activities. ------------------------------------------------------------------------------------------------------------- 2. Windows Network Data Usage Table This table shows: The application name  using the network. The total bytes sent and received . The user SID  associated with the activity. ------------------------------------------------------------------------------------------------------------- 3. Application Resource Usage Table Unlike the Network Data Usage table, this one logs all running applications, whether they used the network or not. It records file paths , execution times , and CPU/memory usage . It can indicate whether a user was running resource-heavy software  or simply had it open in the background. Foreground/Background bytes read/written  can help determine if large amounts of data were copied (e.g., to an external USB device). ------------------------------------------------------------------------------------------------------------- Final Thoughts SRUM data is an incredibly powerful forensic resource, but making sense of it manually is next to impossible. With SRUM_DUMP , analysts can quickly extract and analyze network activity, application usage, and potential signs of data exfiltration. Whether you’re investigating insider threats, tracking a hacker’s movements, or simply auditing system usage, SRUM_DUMP makes life a lot easier. So, if you haven't tried it yet, give it a shot—it might just become one of your go-to forensic tools! ---------------------------------------------------Dean--------------------------------------------------

When investigating digital forensics cases, confirming which files and folders have been opened or accessed is crucial . Whether tracking user activity or validating forensic evidence, understanding where and how to find artifacts plays a key role in uncovering the truth. Many articles on my website discuss different execution artifacts. However, putting them all together in a structured way helps streamline forensic investigations. This article serves as a reference guide, consolidating various forensic artifacts that indicate file and folder access , along with their advantages, disadvantages, and relevant analysis techniques. ------------------------------------------------------------------------------------------------- 1. Open/Save MRU / Last Visited MRU Description: The Open/Save MRU (Most Recently Used) and Last Visited MRU registry keys record file paths and directories accessed through common dialog boxes. They are valuable for determining recently accessed files. Article: Windows Registry Artifacts: Insights into User Activity (Last Visited MRU/ Open Save MRU) 2. Recent Files (RecentDocs) Description: The RecentDocs registry key stores metadata about recently opened files, categorized by file extensions. Article: RecentDocs: Uncovering User Activity Through Recently Opened Files 3. Shortcut (LNK) Files Description: Windows automatically generates LNK (shortcut) files when users open files and folders. These files contain metadata, including access timestamps and file locations. Articles: Windows LNK Files: A Hidden Treasure for Forensic Investigators LECmd: A Powerful Tool for Investigating LNK Files 4. Office Recent Files Description: Microsoft Office maintains records of recently accessed files within the Windows registry. Article: Tracking Recently Opened Files in Microsoft Office: A Forensic Guide 5. ShellBags Description: ShellBags store information about folder views and access history in Windows Explorer. They can provide insights into directories that were accessed, even if deleted. Articles: Understanding ShellBags: A Forensic Goldmine in Windows Investigations Unlocking ShellBags Analysis with ShellBags Explorer (SBE) / SBECmd.exe 6. Jump Lists Description: Jump Lists store metadata about recently accessed files and applications pinned to the Windows taskbar. Articles: Windows Taskbar Jump Lists: A Forensic Goldmine Mastering JLECmd for Windows Jump List Forensics 7. Office Trust Records Description: Office Trust Records store information about trusted Office documents, often used in investigations related to macro-based malware and suspicious document execution. Article: Tracking Trusted Office Documents: A Key to Investigating Macro-Based Malware -------------------------------------------------------------------------------------------------- Conclusion Understanding file and folder access artifacts is essential in forensic investigations. Each artifact provides unique insights, but they also come with limitations . By combining multiple sources of evidence, investigators can build a comprehensive timeline of user activity. Whether tracking user actions, detecting suspicious activity, or validating forensic findings, these artifacts serve as invaluable tools in digital forensics. Happy hunting! -------------------------------------------------Dean--------------------------------------------

When investigating digital forensics cases, confirming application execution is crucial. Whether analyzing malware execution, tracking user activity, or validating forensic evidence, understanding where and how to find execution artifacts is essential. Many articles on my website discuss different execution artifacts. However, putting them all together in a structured way helps streamline investigations . This article serves as a timeline and reference guide, consolidating various forensic artifacts that indicate application execution, their advantages, disadvantages, and relevant analysis techniques. ------------------------------------------------------------------------------------------------------------ Key Artifacts for Identifying Application Execution Each artifact provides unique insights, and choosing the right one depends on the investigation’s requirements . Below is a list of the most important artifacts, along with links to detailed articles that explain their forensic significance. 1. ShimCache (AppCompatCache) ShimCache is a valuable artifact for identifying application execution, especially when prefetching is disabled. However, it does not provide timestamps for execution, only last modification times. Understanding Microsoft’s Application Compatibility Cache (ShimCache) in Digital Forensics Understanding AppCompatCache tool for ShimCache Forensic Analysis 2. TaskBar Feature Usage This artifact helps track executed applications based on user interactions with the Windows Taskbar. TaskBar FeatureUsage: Tracking executed Applications 3. Amcache.hve Amcache.hve is one of the most reliable sources for identifying program execution, storing detailed information about executed applications, including timestamps. Understanding Amcache.hve: A Powerful Forensic Artifact Mastering AmcacheParser and appcompatprocessor.py for Amcache.hiv Analysis 4. Jump Lists Jump Lists store data about recently opened applications and files, making them useful for tracking execution history. Windows Taskbar Jump Lists: A Forensic Goldmine Mastering JLECmd for Windows Jump List Forensics 5. Prefetch Files Prefetch files record program execution details, including the exact timestamp of when an application was last run. Windows Prefetch Files: A Forensic Goldmine for Tracking Program Execution Prefetch Analysis with PECmd and WinPrefetchView 6. Program Compatibility Assistant (PCA) This artifact logs execution history when an application triggers compatibility warnings. Evidence of Execution: Program Compatibility Assistant (PCA) 7. CapabilityAccessManager This registry artifact logs application access to sensitive components like the microphone and camera, indirectly confirming execution. Tracking Microphone and Camera Usage in Windows (Program Execution: CompatibilityAccessManager) 8. SRUM (System Resource Usage Monitor) SRUM records extensive details about executed applications, including their network usage and execution time. SRUM: Unveiling Insights for Digital Investigations 9. Last Visited MRU (Most Recently Used) This registry artifact provides insights into recently accessed applications and files. Windows Registry Artifacts: Insights into User Activity (Last Visited MRU/ Open Save MRU) 10. Run Dialog (RunMRU) Tracking commands executed in the Windows Run dialog provides additional evidence of application execution. Windows Registry Artifacts: Insights into User Activity (RunMRU) RADAR and MUICache RADAR and MUICache provides extensive details about executed applications Using RADAR and MUICache for Evidence of Execution in Windows ---------------------------------------------------------------------------------------------------------- Conclusion Each of these artifacts plays a unique role in application execution analysis. While some provide direct evidence with timestamps, others offer indirect indicators. Depending on the investigation's requirements, a combination of these sources ensures a more comprehensive analysis. If you want to dive deeper, refer to the linked articles for detailed explanations and practical analysis techniques. Happy hunting! ------------------------------------------------------Dean-----------------------------------------

MUICache (Evidence of Execution) ------------------------------------------------------------------------------------------------------------- Power of MUICache in Digital Forensics If you're into digital forensics, especially Windows forensic analysis, you've probably heard of MUICache . But what exactly is it, and why does it matter? In this article, I'll break it down in the simplest way possible while showing you how this artifact can be a game-changer in forensic investigations. ------------------------------------------------------------------------------------------------------------- What is MUICache? MUICache (Multilingual User Interface Cache) is a registry entry found in Windows that stores metadata about programs that have been executed on a system. Essentially, when an application runs, Windows keeps a record of its details, including its executable file name  and user-friendly description . This is valuable for forensic analysts because it provides historical evidence  of program execution, even if traces of the executable have been deleted from the system. ------------------------------------------------------------------------------------------------------------- Where Can You Find MUICache? MUICache entries are typically stored in the Windows Registry at: HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache or HKEY_USERS\\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache Each user on the system will have a separate MUICache entry under their Security Identifier (SID) . This means you can track program execution on a per-user basis! ------------------------------------------------------------------------------------------------------------- Why is MUICache Important in Forensics? MUICache can provide critical insights during an investigation. Here's why: Evidence of Program Execution  – If an attacker runs a malicious program and then deletes it , MUICache might still hold the name of the executable. Attribution to a Specific User  – Since MUICache is stored per user , it can help link program execution to a specific account. Context for Incident Response  – It helps analysts understand what software was used on a compromised system . Detection of Suspicious Applications  – Unusual or unauthorized software in MUICache could be an indicator of compromise (IoC). ------------------------------------------------------------------------------------------------------------- Limitations of MUICache While it's a great forensic artifact, MUICache has a few limitations: No Timestamps  – Unlike Prefetch files, MUICache doesn’t store execution timestamps. Doesn't Confirm Execution  – MUICache may contain entries for programs that were only previewed in Explorer , not actually executed. Easily Altered   – Since it's stored in the registry, an attacker with admin access can clear or modify it. ------------------------------------------------------------------------------------------------------------- How to Analyze MUICache To extract and analyze MUICache entries, you can use forensic tools like: RegRipper  – A great open-source tool for pulling registry data. Registry Explorer - Eric Zimmerman tool FTK Imager  – Allows viewing and exporting registry hives. Velociraptor  – A powerful tool for hunting and forensic analysis. Example RegRipper  command: rip.exe -r NTUSER.DAT -p muicache This will pull the MUICache entries from a user’s registry hive. ------------------------------------------------------------------------------------------------------------- Real-World Example Imagine a scenario where an attacker runs Mimikatz  to dump credentials and then deletes it. Even if no Prefetch or event logs remain, MUICache might still reveal mimikatz.exe  in the registry. That’s a red flag for forensic analysts! ------------------------------------------------------------------------------------------------------------- Radar Heap Leak Detection (RADAR)(Evidence of Execution) In digital forensics, identifying whether a program executed on a system is crucial. While well-known artifacts like Prefetch and MUICache exist, there's another lesser-known registry-based artifact that can help: Radar Heap Leak Detection . This artifact, found in the Windows Registry, can provide evidence of execution, though it doesn't track every process. What is Radar Heap Leak Detection? Radar, short for Resource Exhaustion Detection and Resolution , is part of Windows' memory leak diagnostic system. It was introduced in Windows Vista to detect memory leaks, collect diagnostic data, and help resolve application issues. Where to Find It in the Registry This artifact is stored in the Windows Registry at the following location: HKEY_LOCAL_MACHINE\Software\Microsoft\RADAR\HeapLeakDetection\DiagnosedApplications Each application listed under this key indicates that it executed on the system at some point. How Does an Application Get Tracked Here? Not all executed applications appear in this registry key. An application ends up under DiagnosedApplications  if it consumes a significant amount of system memory On systems with 4GB RAM , the threshold is 5% or more  of available memory. On systems with 16 GB RAM or more , the threshold is even lower. Because of this memory usage condition, the presence of an application in this key is somewhat random— not all executed applications will appear here . How to Determine Execution Time Each application entry has two important time-related indicators: Last Detection Time This timestamp updates within minutes  of an application exceeding the memory threshold. However, it does not indicate  the exact time of execution. Last Write Timestamp This is the most useful timestamp  because it tells us when the registry subkey was last modified. If an application appears in DiagnosedApplications , we can say it executed on or before  this timestamp. Why is This Useful for Forensics? While this artifact is not as reliable as Prefetch , it can still be valuable in investigations. But we can confirm that: The application did execute  on the system. The execution happened on or before  the last write timestamp. This evidence can be combined with other artifacts like Prefetch, MUICache, or event logs to build a stronger case. ------------------------------------------------------------------------------------------------------------- Importance on Windows Servers Windows servers do not enable Prefetch by default , which makes Radar even more valuable  as an execution artifact in server environments. ------------------------------------------------------------------------------------------------------------- Conclusion MUICache is a simple yet powerful forensic artifact that can help track program execution on a Windows machine. While it has some limitations, it remains a valuable piece of the puzzle  in digital investigations. Another artifact Radar Heap Leak Detection is a lesser-known but potentially useful  forensic artifact. While it won’t capture every executed application, its presence in forensic analysis can strengthen evidence collection. When combined with other artifacts, it provides another piece of the puzzle  in identifying program execution on Windows systems. Next time you're investigating execution artifacts, don’t forget to check DiagnosedApplications  in the registry! Stay tuned for more forensic insights! 🔍 ---------------------------------------------------Dean--------------------------------------------

The Universal Windows Platform (UWP)  is Microsoft's modern application model, designed to replace traditional desktop applications with a sandboxed, secure environment . While UWP apps improve system security and organization, they also introduce new forensic challenges , as many of their artifacts exist outside of expected locations . --------------------------------------------------------------------------------------------------------- What Are UWP Applications? UWP applications were first introduced as Metro Apps in Windows 8  and later evolved into Modern Apps in early Windows 10 . Over time, Microsoft has encouraged developers to adopt this model, and now many built-in and third-party applications use it, including: Notepad Microsoft Paint Calculator Microsoft Office (some versions) Microsoft Edge Dropbox Your Phone Since UWP apps are installed per user, they do not follow the traditional program installation structure. Instead, they are located in: %UserProfile%\AppData\Local\Packages\ Each installed UWP app has a dedicated folder here, containing its settings, cache, and data. --------------------------------------------------------------------------------------------------------- Finding Installed UWP Applications on a Live System To list installed UWP apps, run the following PowerShell  command: Get-AppxPackage | Select-Object -Property Name This command will display all UWP applications installed for the current user. --------------------------------------------------------------------------------------------------------- How UWP Apps Store Data: Virtualization and Sandboxing Unlike traditional applications, UWP apps are heavily sandboxed , meaning they have limited access to system files and the registry . Instead of writing directly to the Windows Registry , UWP apps use virtualized registry hives , which are unique to each application. According to Microsoft: "In traditional environments, apps can create, update, and delete files in most places in the file system. And they can create, update, and delete entries in the Windows Registry. Those files and Registry entries are visible to other apps on the system. In contrast, UWP applications have their files and registry entries virtualized, making them only visible to the app that created them and removing them when the app is uninstalled." --------------------------------------------------------------------------------------------------------- Where Are UWP Registry Files Stored? Since UWP applications do not write directly to the system registry, they maintain their own per-application registry hives  inside their respective package folders. These can be found in: %UserProfile%\AppData\Local\Packages\\SystemAppData\Helium\ These hives include: Registry.dat  → Equivalent to the system SOFTWARE hive User.dat  → Equivalent to NTUSER.dat UserClasses.dat  → Equivalent to UsrClass.dat These hives do not propagate to the system registry , meaning traditional forensic registry analysis tools may miss them  unless specifically collected. --------------------------------------------------------------------------------------------------------- Analyzing UWP Registry Data Since UWP registry hives  exist separately from traditional Windows registry locations, f orensic analysts must extract and analyze them manually. How to Identify and Extract UWP Registry Hives A simple way to locate relevant hives is to collect them during initial triage  using tools like KAPE . KAPE includes a target that recursively scans the UWP Packages folder  to extract these hives for further investigation. Once extracted, hives can be analyzed using: Registry Explorer RegRipper PowerShell scripts Why This Matters for Investigators If an uninstalled   UWP application was used for malicious activity , its registry d ata might still be recoverable  from forensic images. If malware was running inside a UWP sandbox , it may have stored configuration files or registry artifacts  in these virtualized locations instead of standard system paths. These alternative registry hives can contain crucial forensic evidence that traditional registry analysis might miss . --------------------------------------------------------------------------------------------------------- MSIX and UWP Registry Redirection Microsoft also introduced the MSIX packaging format  for UWP apps , which further complicates forensic investigations. MSIX applications  are containerized, meaning registry modifications are redirected to per-app hives , just like standard UWP apps. While not all UWP applications use MSIX , those that do require registry redirection , making it even more important to check the Helium folder for forensic artifacts. No need to worry Kape has already done it for easy collection --------------------------------------------------------------------------------------------------------- UWP Internet Artifacts and Web Data Aside from registry data, UWP applications store web-related artifacts   in their package directories. Browser residue  (such as cached websites and session data) is stored inside each UWP browser’s application folder  rather than standard locations like C: \Users\\AppData\Local\Microsoft\Edge. Internet metadata  for UWP browsers is still recorded in the Internet Explorer WebCacheV.dat * database, even in Windows 11 . 💡 Key Takeaway:  Traditional browser forensics may not detect UWP browser activity  unless analysts specifically check inside UWP package folders . --------------------------------------------------------------------------------------------------------- Investigative Techniques for UWP Forensics 🔍 1. Identify Installed UWP Apps Use Get-AppxPackage | Select-Object -Property Name to list UWP apps. Browse %UserProfile%\AppData\Local\Packages\ for per-user installations. 🗂️ 2. Extract UWP Registry Hives Check %UserProfile%\AppData\Local\Packages\\SystemAppData\Helium\ Collect Registry.dat, User.dat, and UserClasses.dat  for analysis. Use forensic tools like Registry Explorer  to review extracted hives. 🌐 3. Investigate UWP Browser Artifacts Look inside each UWP browser’s package folder for cached data. Examine WebCacheV*.dat for internet browsing metadata . 🛑 4. Watch for UWP Malware & Persistence Malware can operate inside UWP sandboxes to avoid detection. Checking UWP registry hives may reveal unauthorized app activity . Look for suspicious app paths or execution timestamps  inside UWP registry data. --------------------------------------------------------------------------------------------------------- Identifying UWP Apps UWP apps have a distinct naming convention that can help you identify them. The name format is typically: _ For example, the Dropbox app appears as Microsoft.WindowsNotepad_8wekyb3d8bbwe Whenever you encounter references to the Packages folder or these unique naming patterns, you’re likely dealing with a UWP application . Recognizing these traces will help you uncover valuable insights in your investigations. --------------------------------------------------------------------------------------------------------- Final Thoughts: Why UWP Forensics Matters The rise of UWP applications  means forensic analysts must adapt their techniques. Unlike traditional software, UWP apps store artifacts in separate per-application directories and virtualized registry hives , making them easy to overlook. 🚀 Key Takeaway:  If you’re conducting a forensic investigation on a Windows system, don’t ignore UWP applications!  They could hold critical evidence that traditional forensic techniques might miss. ---------------------------------------Dean---------------------------------------------------------

Windows keeps track of many user activities, and one of the lesser-known but valuable forensic artifacts  is the Background Activity Moderator (BAM)  and Desktop Activity Moderator (DAM) . These registry keys store evidence of executed programs , making them useful for tracking user activity, malware execution, and forensic investigations . ----------------------------------------------------------------------------------------------------------- What Are BAM and DAM? 🔹 Background Activity Moderator (BAM) First introduced in Windows 10 (build 1709)  and still present in Windows 11 . Stores the full path of an executable  and the last execution timestamp . Designed to regulate background activity  to improve battery life  and system efficiency. Entries expire after seven days  if the program is inactive. 🔹 Desktop Activity Moderator (DAM) Functions similarly to BAM but focuses on desktop applications . Primarily found on devices using Modern Standby , a power management feature that limits desktop app activity when the screen is off. Less commonly found on desktop PCs but can still appear on some systems. Key Point:  Both BAM and DAM store execution timestamps but are not permanent records — entries are removed after seven days of inactivity  or upon system reboot if the executable has been deleted . ----------------------------------------------------------------------------------------------------------- Where Are BAM and DAM Stored in the Registry? BAM and DAM data is recorded per user profile , meaning each user has their own set of logs. SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID} SYSTEM\CurrentControlSet\Services\Dam\UserSettings\{SID} Each user’s data is stored under their Security Identifier (SID) , so you must identify the correct SID before extracting execution records. ----------------------------------------------------------------------------------------------------------- What Data Do BAM and DAM Store? Each BAM/DAM entry contains: ✅ Full Path of Executable  – The exact location of the program that was run. ✅ Last Execution Timestamp  – A 64-bit Windows FILETIME timestamp , showing when the program was last executed. ✅ User-Specific Data  – Entries are tied to individual users, identified by their SID . ----------------------------------------------------------------------------------------------------------- Why Is BAM/DAM Important in Digital Forensics? ✅ 1. Even if a user deletes an application, BAM may still contain a record of its execution  for up to seven days . ✅ 2. If malware ran on a system, BAM/DAM could provide evidence of when and where it was executed . However, malware running from USB drives or network shares  will not  appear in BAM. ✅ 3. Analysts can determine which programs a user interacted with , when they were used , and whether any unauthorized applications  were executed. ✅ 4. BAM timestamps can vary by several minutes , it’s best to cross-reference BAM data with: Prefetch files   UserAssist registry ShimCache & AmCache artifacts ----------------------------------------------------------------------------------------------------------- Limitations of BAM and DAM ⚠️ Entries Are Not Permanent  – BAM records are deleted after seven days  of inactivity. ⚠️ No Records for Network/USB Executions  – Programs executed from removable drives or network shares  are not logged  in BAM. ⚠️ Timestamps May Be Slightly Off  – Execution times in BAM may differ by a few minutes  from actual program launch times. Because of these limitations, BAM/DAM should be used alongside other forensic artifacts  for a complete investigation. ----------------------------------------------------------------------------------------------------------- Final Thoughts: A Simple Yet Powerful Execution Artifact The BAM and DAM registry keys  provide a quick way to track recently executed applications  on a Windows system. While entries only last for seven days , they can still offer crucial insights  into user activity, malware infections, and forensic investigations . 🚀 Key Takeaway:  If you’re investigating recent application execution on Windows (especially within the last seven days) , BAM/DAM should be one of your go-to forensic artifacts!  🔍 ----------------------------------------Dean---------------------------------------------------