Search Results

When it comes to USB key forensics, understanding the timeline of device connections and disconnections can be crucial. Key Timestamps to Track: Windows starts recording three important timestamps for USB devices: First Time Device Connected Last Time Device Connected Removal Time New Times in Windows 8+ Registry Structure In Windows 8 and above, you'll find additional timestamp information in the USBStor  registry key, specifically under the Properties  key with the GUID {83da6326-97a6-4088-9453-a1923f573b29} . 0064 : First Install Date of the device (Windows 7 and Win8) 0066 : Last Connected Date of the device (Windows 8+ only) 0067 : Last Removal Date (Windows 8+ only) This GUID appears in several device categories such as HID (Human Interface Devices), USBSTOR (USB storage devices), MTP (Media Transfer Protocol), and others. Locations to Find Timestamps Data First Install Date Registry Path: SYSTEM\CurrentControlSet\Enum\USBSTOR\Device-Class\Device-SerialNumber\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0064 Last Connected Date Registry Path: SYSTEM\CurrentControlSet\Enum\USBSTOR\Device-Class\Device-SerialNumber\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0066 Last Removal Date Registry Path: SYSTEM\CurrentControlSet\Enum\USBSTOR\Device-Class\Device-SerialNumber\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0067 -------------------------------------------------------------------------------------------------- How It Works in Modern Windows Systems: Starting from Windows 7, the First Time Device Connected  timestamp was introduced . With Windows 8 and newer versions, additional timestamps were added to track the Last Time Device Connected  and Removal Time . Timestamps are stored in FILETIME format , which is a way of recording time in 64-bit values. Now Question you willl ask what if i am working on older version Fair Point But i got you covered If you’re working with Windows XP or Windows 7, you won’t find the Last Removal Time but you can still use other logs like XP: C:\Windows\setupapi.log Vista+: C:\Windows\inf\setupapi.dev.log The logs  to track when a device was first connected . Keep in mind that older systems use different methods for tracking connection times. -------------------------------------------------------------------------------------------------- How to Make the Process Faster: Use Registry Explorer   this will help speed up the process. This will help you piece together a timeline of USB device activity and track any suspicious behavior during your investigation. -------------------------------------------------------------------------------------------------- Conclusion: Tracking USB device activity is a powerful tool for forensic examiners. By utilizing the registry’s timestamps, you can quickly find when a device was connected, removed, and even when it was first installed. Always document the key details of each device, and cross-reference timestamps to build a clear timeline of event ---------------------------------------------Dean------------------------------------------

When investigating user activity on a Windows system, one of the most valuable forensic artifacts is the RecentDocs  registry key. This key maintains a list of recently opened files and folders , allowing analysts to track file interactions, identify potentially suspicious behavior, and even estimate timeframes for when files were accessed. ------------------------------------------------------------------------------------------------------------- Where is the RecentDocs Key Located? The RecentDocs  key is found in the user-specific registry hive: NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs ------------------------------------------------------------------------------------------------------------- What Data Does RecentDocs Contain? ✅ Last 150 Files Opened (Any Type)   ✅ RecentDocs creates subkeys for different file extensions (e.g., .docx, .pdf, .eml), each storing the last 20 files  opened of that type. ✅ last 30 folders  opened by the user. ✅ MRU (Most Recently Used) Order  – Items are stored in a list format , with Item 1 being the most recently accessed. ✅ Potential Web Searches & Downloads  – Some browsers and Windows search features may log visited websites and downloads  under RecentDocs. --------------------------------------------------------------------------------------------------------------------------- Understanding RecentDocs Timestamps The RecentDocs key itself  has a last write timestamp , which updates every time a new file is opened. However, individual entries within RecentDocs do not store timestamps —except for the most recently used item  in each subkey. 🔹 How This Works: If you open multiple .docx files, only the most recent one  in the .docx subkey will have a timestamp. Older entries remain in order but do not store exact access times . Even though older entries lack timestamps, the MRU list order  can help estimate time ranges. --------------------------------------------------------------------------------------------------------------------------- How RecentDocs Helps in Forensic Investigations 🔍 1. Tracking User Activity Recent Docs provides insight into what files and folders a user interacted with , helping investigators build a digital footprint . 💾 2. Recovering Deleted Evidence Even if a f ile has been deleted, its record in RecentDocs remains  until overwritten —allowing analysts to recover evidence of past activity. 🕵️ 3. Identifying Suspicious Behavior Data Theft:  If a user accessed multiple sensitive files before an unauthorized data transfer, it could indicate data exfiltration . Malware Execution:  If ransomware was detected on a system, RecentDocs might reveal which file triggered the infection . Insider Threats:  Analyzing which files were accessed before a breach  can help determine whether an employee played a role . --------------------------------------------------------------------------------------------------------------------------- Final Thoughts: A Simple Yet Powerful Forensic Tool The RecentDocs  registry key is an essential forensic artifact  for understanding user interactions with files and folders. By analyzing its MRU lists, subkeys, and timestamps, investigators can track user behavior, uncover deleted evidence, and reconstruct activity timelines . If you're conducting an investigation, don’t overlook RecentDocs—it could be the key to uncovering what really happened on a system!  🚀 ------------------------------------------Dean--------------------------------------------------

Updated 24 Feb,2024 When investigating a macOS system, understanding its device information , user accounts , and network settings  is critical. ------------------------------------------------------------------------------------------------------------- Finding macOS Version and Build Information Your macOS version and build number are crucial details, often needed for software compatibility, troubleshooting, and security updates. You can find this information in the SystemVersion.plist  file, which is located in: 📂 /System/Library/CoreServices/SystemVersion.plist For example, if you’re running BigSur (11.2.3), the file will show something like this: System Name:  macOS Version:  11.2.3 Build Number:  20D91 Command : Use cat on a live system to view the .plist file contents. This tells you exactly what version of macOS you're using, which can be helpful when checking for updates or debugging issues. ------------------------------------------------------------------------------------------------------------- Retrieving Your Mac’s Serial Number Your Mac’s serial number is unique to your device and can be retrieved in several ways. The easiest method is through the system_profiler  command: system_profiler SPHardwareDataType | grep "Serial Number" However, on newer versions of macOS, Apple stores the serial number in encrypted databases. One such place is the cache_encryptedA.db  file , where the serial number is often stored in a table named TableInfo . I have used UAC script to collect artifact. I searched Serial Number and found For forensic analysts or tech-savvy users, extracting this information might require additional database query techniques. ------------------------------------------------------------------------------------------------------------- Finding macOS Installation and Setup Dates Want to know when your Mac was first set up? Here are some ways to find out: 1️⃣ Original System Setup Date The file .AppleSetupDone  (located in /private/var/db/) is created when you first complete your Mac’s setup process. The access or modification date of this file can give you an idea of when the system was first registered or set up. 2️⃣ macOS Installation Dates Each time macOS is installed or updated, a record is logged in install.log  files located in: 📂 /private/var/log/install.log If these log files haven’t been overwritten, you can check them to see when different macOS versions were installed. 3️⃣ Software Update History For more detailed timestamps of software installations and updates, check this file: 📂 /private/var/db/softwareupdate/journal.plist This file provides detailed logs of when system updates were applied, making it useful for tracking system changes. ------------------------------------------------------------------------------------------------------------- Checking the System Time Zone Configuration Your Mac stores its current time zone settings in multiple places. The /etc/localtime  file contains the active time zone value. Command: ls -la /etc/localtime For example, if the system is set to Eastern Time (New York), it will reflect in this file. You can also check the time zone settings in the .GlobalPreferences.plist  file , located at: 📂 /Library/Preferences/ Command : plutil -p /Library/Preferences/.GlobalPreferences.plist However, if you've switched from using location-based time zone settings to a manually set time zone, this plist might not update automatically. Is Location Services Being Used for Time Zone Updates? If you’re curious whether your Mac is automatically adjusting the time zone using Wi-Fi or GPS, check this file: 📂 /Library/Preferences/com.apple.timezone.auto.plist Command : cat /Library/Preferences/com.apple.timezone.auto.plist or plutil -p /Library/Preferences/com.apple.timezone.auto.plist If location services are enabled, macOS will determine your time zone based on nearby Wi-Fi networks, which might explain why your time zone occasionally changes when you travel. ----------------------------------------------------------------------------------------------------------------------------- When managing a macOS system, knowing the different types of user accounts and their permissions is crucial. Types of User Accounts in macOS Every user account in macOS falls into one of these categories: Administrator : Has full control over the system. Standard : A regular user account with permission to install apps and change personal settings but without full system control. Managed with Parental Controls : Allows restrictions on app usage, content access, and screen time. Sharing Only : Used for network access without a full user account. Group : Used to organize users for access control in enterprise environments. Guest : Temporary access without a password. Data is deleted upon logout unless configured otherwise. If FileVault is enabled, Guest users can only access Safari, and on macOS 10.7 or later, they cannot log in at all. Where User Data is Stored User and group account information is stored in the directory: /private/var/db/dslocal/nodes/Default/users/ (for users) /private/var/db/dslocal/nodes/Default/groups/ (for groups) The account details are stored in property list (.plist) files, which can be either: XML format  (macOS 10.6 and earlier) Binary format  (macOS 10.7 and later) Accessing these files requires root privileges. Note that users managed via Open Directory (similar to Active Directory) do not have a local .plist file in this directory Tracking Deleted User Accounts When a user account is deleted, macOS provides three options: Save the home folder in a disk image (DMG)  – The most common option, saving the user’s files in /Users/Deleted Users/. Keep the home folder in place  – The user is deleted, but their files remain. Delete the home folder   – Removes all associated data permanently. Deleted user records are stored in the com.apple.preferences.accounts.plist  file under the deletedUsers key, located at: /Library/Preferences/ This file contains: The deleted user’s real name User ID (UID) Username Deletion date Tracking User Login Activity Login-related information is stored in the com.apple.loginwindow.plist  file located at: /Library/Preferences/ or Command : plutil -p com.apple.loginwindow.plist Key details include: lastUser – The currently logged-in user (if the system was imaged live). autoLoginUser – If automatic login is enabled, this field stores the username. lastUserName – The last user who logged in. RetriesUntilHint – Number of failed attempts before a password hint appears. GuestEnabled – Indicates whether the Guest account is active. Automatic Login and Password Storage If a user enables automatic login , macOS stores the password in an encoded format in the file: /etc/kcpassword The password is XOR-encoded with a multi-byte key. A Ruby script can decode it if necessary: sudo ruby -e 'key = [125, 137, 82, 35, 210, 188, 221, 234, 163, 185, 31]; IO.read("/etc/kcpassword").bytes.each_with_index { |b, i| break if key.include?(b); print [b ^ key[i % key.size]].pack("U*") }' However, automatic login is disabled if FileVault is enabled or if the user logs in via iCloud credentials. Managing macOS and iOS Devices For macOS and iOS devices managed by enterprises, configurations and restrictions are controlled through Mobile Device Management (MDM) . These devices contain configuration profiles stored in: /private/var/mobile/Library/ConfigurationProfiles/ /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles To check installed profiles: Settings → General → Profiles (or Device Management) Hidden profiles, do not appear in the standard GUI. Restrictions on app installations, purchases, content access, and privacy settings are stored in files like: UserSettings.plist EffectiveUserSettings.plist PublicEffectiveUserSettings.plist These files track device policies, user permissions, and other restrictions. ---------------------------------------------------------------------------------------------- Network Interfaces Information macOS: 📂 /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist Command : cat /Library/Preferences/ SystemConfiguration/NetworkInterfaces.plist or plutil -p /Library/Preferences/ SystemConfiguration/NetworkInterfaces.plist This file stores details about network interfaces available on the system. Each interface has an associated Item key : Item 0:  Typically represents the Wi-Fi interface (e.g., en0, IEEE802.11). Item 7:  Could represent a USB-C hub with an Ethernet port. Each interface entry includes: Description  (e.g., "IEEE802.11" for Wi-Fi, "Ethernet" for wired connections) Unique MAC Address  for the interface Model Key  showing the system’s model 💡 Tip:  You can search for the system model on Apple’s support page  to find exact hardware details.' Network Services Configuration Interface number  (e.g., en0 for Wi-Fi, en1 for Ethernet). Network Type  (e.g., IEEE802.11 for Wi-Fi, Ethernet for wired connections). MAC address : This may be displayed in Base64-encoded format on Linux but can be decoded using                      echo "(encoded MAC)" | base64 –d | xxd Model : Useful for identifying the device's network hardware. macOS: 📂 /Library/Preferences/SystemConfiguration/preferences.plist The NetworkServices  key inside this file contains configurations for different network interfaces: Wi-Fi Interface (en0): Uses DHCP  for automatic IP address assignment. Has a NetBIOS name  for system identification. ---------------------------------------------------------------------------------------------- DHCP Lease Records This directory contains network configurations for DHCP-based connections. 📂 /private/var/db/dhcpclient/leases/ Files are named based on the network interface (e.g., en0.plist, interface.plis t,  en0-MAC.plist or en0-1,12:12:12:12:12:12.plist ). Where there have been multiple connections on an interface, the files in this folder will contain data relating to the most recent connection and other information like Lease Start Date Router MAC Address Assigned IP Address SSID of the Access Point DHCP Lease Duration Router IP Address Packet Data If you are using UAC Script to collect artifact you can get all the information in system profiler text file ------------------------------------------------------------------------------------------------------------ Known Wi-Fi Networks macOS: 📂 /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist These files store information about Wi-Fi networks previously connected to. Each known network is recorded with: SSID Name Captive Portal Status  (e.g., login screens at hotels) Last Connection Time  (stored in local system time) Auto-Connect Preferences 💡 Key Attributes: AddReason:  Determines whether the network was synced via iCloud or manually added. JoinedByUserAt:  The user manually connected to the AP. JoinedBySystemAt:  The system auto-connected to the AP. Older macOS Versions Older macOS versions store known networks differently, using a wifi.ssid.  format within the KnownNetworks  key. 💡 The PreferredOrder  key defines the priority of saved networks— Item 0  being the highest priority. ------------------------------------------------------------------------------------------------------------ Wrapping Up macOS stores a wealth of system information in various locations, and knowing where to look can help you troubleshoot, perform forensic analysis, or simply satisfy your curiosity. 🔍 Now you know how to peek under the hood of macOS!  Let me know if you need more insights or step-by-step guides. 🚀 ------------------------------------------------------Dean-----------------------------------------------

Updated on 23 February, 2025 Early Apple Days Apple was established on April 1, 1976, and quickly made its mark with the Lisa  in the early 1980s , the first public computer featuring a graphical user interface (GUI). Fast forward to 1984, and Apple released the Macintosh , their first affordable personal computer with a GUI, revolutionizing personal computing. Big Moves in the 1990s and Beyond By the late 1990s, Apple was well-established. In 1998, they introduced the HFS+ file system , which helped users manage larger storage devices and improved overall file organization. But things really got interesting in 2001 with the launch of macOS X —a Unix-based operating system that gave the Mac the robustness and reliability it needed. The Evolution of macOS 2012 : With OS X 10.8 (Mountain Lion) , Apple started to unify its desktop and mobile platforms, borrowing elements from iOS. 2016 : Apple rebranded OS X to macOS , beginning with macOS 10.12 (Sierra). 2 017 : The APFS file system  (Apple File System) was introduced to replace HFS+, designed to be faster and more efficient, especially for SSDs. APFS: Apple's Modern File System When Apple introduced APFS  in 2017, it addressed many limitations of its predecessor, HFS+ . Here’s what makes APFS special and why it matters for modern Macs: Optimized for SSDs : APFS is designed to work seamlessly with solid-state drives (SSDs) and flash storage, making your Mac much faster when it comes to file operations. Atomic Safe Save : Ever worried about losing data if your Mac crashes while saving a file? APFS uses a technique called Atomic Safe Save . Instead of overwriting files (which can corrupt data during a crash), it creates a new file and updates pointers—meaning your data is much safer. Full Disk Encryption : APFS builds encryption right into the file system, giving you multiple ways to secure your data using different recovery keys, including your password or even iCloud. Snapshots : One of the coolest features is snapshots , which create a read-only copy of your system at a specific point in time. If something goes wrong, you can roll back to a previous state—perfect for troubleshooting! Large File Capacity : APFS supports filenames with up to 255 characters  and file sizes up to a theoretical limit of 8 exabytes  (that’s 8 billion gigabytes!). So, you probably won’t run out of space anytime soon. Accurate Timestamps : With nanosecond accuracy, APFS records changes precisely—useful for backups, file versioning, and tracking down when exactly something was altered. macOS File Structure: How Your Files Are Organized macOS organizes files and folders into four main domains , each serving different purposes: Domain Description User - User-Specific Files - Controlled by Each User - Hidden ~/Library Directory Local - Apps/Resources for Local System and Users - Controlled by System and Admin Users - /Library System - System Software Installed by Apple - Controlled by System - /System/Library Network - Apps/Resources on Local Network - Controlled by Network Administrator - Other systems, printers, Time Capsules, NAS, etc. 1. User Domain  (/Users) or User Library This is w here all the files related to your user account live . It includes the home directory, which stores personal documents, downloads, music, and more. Each user on the system has their own isolated space here. There’s also a hidden Library  folder within each user account, where your apps store personal preferences and data. Key folders in the User Domain : Home Directory : Your personal space, with folders like Documents , Downloads , and Desktop . Public Directory : A space where you can share files with others who use the same Mac. User Library : Hidden by default, but this folder is a treasure trove for advanced users and app developers. It contains your preferences, app data, and cached files. If you ever need to dig in, you can reveal it using a simple Terminal command: chflags nohidden /Users//Library 2. Local Domain  (/Library) or Local Library This domain c ontains files and apps that are shared across all users on the Mac. Apps installed via the Mac App Store will be located in the /Applications  folder. There’s also a / Developer  folder here if you’ve installed Xcode or developer tools. /Library – Library files shared across all users. 3. Network Domain  (/Network) The Network Domain  is for shared resources like network drives or printers. In an office setting, this is where you’d find shared servers or Windows file shares. It’s managed by network administrators and isn’t something the average user interacts with often. 4. System Domain  (/System) System Library This is where Apple stores the critical components that make macOS run smoothly. I t’s locked down so that regular users can’t accidentally delete something important. You’ll find OS-level libraries and apps here, safely tucked away from tampering. /System/Library/ A Deeper Look into the User Domain Every user account on macOS has its own Library directory  (~/Library/), which contains various subdirectories packed with forensic gold. The tilde (~) is a shortcut that represents the user’s home directory, so if you’re examining a user named Dean, her Library path would be /Users/Dean/Library/. 1. Containers Directory (Introduced in macOS 10.7) Apple introduced sandboxing  to enhance security, and the Containers directory  plays a crucial role here. Applications that are sandboxed store their data inside ~/Library/Containers/ rather than the traditional Application Support  directory. This means that if you don’t find what you’re looking for in Application Support , you should check Containers  as well. Each container is named in reverse DNS format , such as com.apple.Safari. Inside, you’ll often find a metadata.plist  file that provides information about the app’s sandbox environment. 2. Application Support Directory Think of this as the macOS equivalent of AppData  on Windows. Located at ~/Library/Application Support/ this directory stores configuration files, databases, and other application-specific data. The way each application stores its data varies, so you might find SQLite databases, property list files (.plist), or even proprietary formats. 3. Caches Directory Applications generate a lot of temporary files, and macOS keeps them organized inside ~/Library/Caches/ These cached files may be named using reverse DNS format  (e.g., com.google.Chrome), or simply follow a company’s folder structure (e.g., Adobe/Photoshop/). Cached data can sometimes reveal user activities, recently accessed files, or browsing history. 4. Preferences Directory (.plist Files) User preferences for applications are stored in property list files (.plist) , usually found in ~/Library/Preferences/ These files follow the reverse DNS format , such as com.apple.TextEdit.plist. By examining these files, forensic analysts can uncover user settings, saved states, and even recent application interactions. ------------------------------------------------------------------------------------------------------- Data Directory and Symbolic Links In sandboxed applications, the Data directory within Containers mimics a user’s home directory but with strict access controls. Some directories inside it are symbolic links , meaning they redirect to actual files elsewhere on the system. The ones that are not  links often contain the most valuable forensic data, such as app-specific databases and usage logs. For example, Apple Maps  stores its primary database here, which can be crucial for location-based investigations. ------------------------------------------------------------------------------------------------------- Wrapping Up Forensic analysis on macOS can be tricky due to Apple’s unique approach to data storage and security. However, once you know where to look, the Library directory  and core system directories hold a wealth of useful artifacts. Whether you’re investigating user preferences, app data, cached files, or system logs, each directory has its own forensic story to tell. Next time you’re analyzing a macOS system, keep this guide handy—it might just lead you to the evidence you need! -----------------------------------------Dean---------------------------------------------

Microsoft Office is widely used for business and personal tasks, but it has also been a major target for cybercriminals. One of the most common attack methods has been malicious macros , which execute harmful scripts when an Office document is opened. Malware like Locky, Revil, and Emotet  has successfully exploited this technique for years, often leading to ransomware infections and data breaches. To combat this, Microsoft blocked macros by default in 2022  for files downloaded from the internet . However, many users still need macros for work, and attackers continuously find workarounds. For forensic investigators and cybersecurity professionals, tracking which files a user has trusted and enabled macros for  is crucial. Microsoft Office maintains a TrustRecords  registry key that logs this information. T his key provides a long-term record of what d ocuments were trusted, where they were stored, and when the user enabled macros or editing. ------------------------------------------------------------------------------------------------------- Where is TrustRecords Stored in the Registry? Microsoft has kept a TrustRecords  key in the Windows Registry. NTUSER\Software\Microsoft\Office\\Word\Security\Trusted Documents\TrustRecords ------------------------------------------------------------------------------------------------------- What Information Does TrustRecords Contain? Each entry in TrustRecords  logs valuable forensic data: ✅ Full File Path  – The exact location of the document when it was opened (local, USB, network, or cloud). ✅ Timestamp  – When the user trusted  the document and enabled macros or editing. ✅ Permission Type  – Whether the user allowed editing or macro execution . This data can reveal whether a user has intentionally or unknowingly trusted a malicious document , making it an essential artifact in malware investigations. ------------------------------------------------------------------------------------------------------- Why Is This Important in Digital Forensics? 🔍 1. Identifying Malicious Documents If a system is infected with malware, analysts can check TrustRecords  to see if the user opened and trusted a suspicious document . If an attacker sent a phishing email  with a malicious macro , this registry key can confirm whether the victim enabled  the macro. 💾 2. Recovering Evidence of Past Attacks One of the most powerful aspects of TrustRecords  is that it keeps logs for years . Even if a document has been deleted, its trust history  remains in the Registry, making it possible to trace old infections. 🛡️ 3. Auditing Security Practices Businesses can use TrustRecords  to audit user behavior  and determine if employees are frequently enabling macros in untrusted documents. This helps security teams improve training and reduce future risks . 🖥️ 4. Tracking External & Cloud Documents The registry logs files trusted from different locations , including: Local storage  (C:\Users\PCUser\Documents\report.doc) USB devices  (E:\Malware_Invoice.doc) Network shares  (\CompanyServer\Shared\Finance.xlsm) Microsoft 365 Cloud  (OneDrive documents) This makes it useful for tracking document movement  and identifying external storage devices  used in an attack. ------------------------------------------------------------------------------------------------------- Final Thoughts: A Hidden Treasure for Investigators The TrustRecords  registry key is a goldmine of forensic evidence  when investigating macro-based attacks, phishing incidents, and document-based malware infections. Forensic investigators and cybersecurity professionals should always check this key  when analyzing: ✔️ Malware infections ✔️ Phishing attacks ✔️ Insider threats ✔️ Suspicious document activity By leveraging TrustRecords , we can uncover hidden evidence, track user behavior, and strengthen defenses against macro-based malware attacks . 🚀 ---------------------------------------Dean--------------------------------

The Windows Registry  is like the DNA of an operating system —it tracks system configurations, user settings, and most importantly, installed applications. For forensic investigators, this makes the Registry a valuable source of evidence, helping to i dentify what software has been installed, when it was installed, and even if it has been uninstalled but left traces behind. Where to Find Installed Applications in the Registry Windows stores information about installed applications in multiple locations within the Registry. The primary locations include: 1. Uninstall Keys (Most Common Locations) These keys list installed applications and provide details such as: Application Name Version Number Software Publisher File Size Installation Date Location on Disk Registry Paths for Installed Applications For all users: 1.SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall 2.SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall (for 32-bit apps on 64-bit OS) For specific users: 1. NTUSER\Software\Microsoft\Windows\CurrentVersion\Uninstall 2. NTUSER\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall Many applications today are still 32-bit, even on 64-bit systems, so checking the WOW6432Node  key is essential for a complete audit. -------------------------------------------------------------------------------------------------------- Alternative Registry Locations for Installed Applications Beyond the uninstall keys, additional locations provide useful data: Microsoft Installer (MSI) Applications SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\\Products\\InstallProperties This key tracks software installed using MSI packages . If an application’s UninstallString  contains "msiexec.exe", the MSI Product Code (GUID)  can be searched in the Registry to find more related details. Universal Windows Platform (UWP) Apps (Microsoft Store Apps) SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore This tracks Windows Store apps  and built-in system applications. Other Application Tracking Keys Application Paths (Shortcut Information) SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths NTUSER\Software\Microsoft\Windows\CurrentVersion\App Paths File Extension Tracking (Recently Used Apps) NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts Application-Specific Data Storage (IntelliType Keyboard Software, etc.) NTUSER\Software\Microsoft\IntelliType Pro\AppSpecific These locations contain file paths, execution history, and recently used file extensions , which can be useful when investigating software usage and digital artifacts. -------------------------------------------------------------------------------------------------------- Tracking Software Installation Dates and Updates Every installed application typically has an InstallDate  value , which records the last time the software was installed, updated, or repaired . However, not all applications store this data , and updates (such as Windows patches) can alter timestamps for multiple applications at once. If the InstallDate  field is missing, the Registry last write time  can sometimes be used as an estimate. However, this method isn’t always reliable because system-wide updates can reset multiple timestamps at once. -------------------------------------------------------------------------------------------------------- Finding Uninstalled Software Evidence Even when an application is removed, traces often remain in the Registry. These can include: Leftover registry keys  under the uninstall locations Recently used file extensions  still linked to the software Application-specific MRU (Most Recently Used) lists  stored elsewhere in the Registry A simple keyword search across registry keys, values, and data  can reveal hidden traces of software that no longer appears in the uninstall lists. -------------------------------------------------------------------------------------------------------- Forensic Analysis of Installed Software: The Best Approach To get a complete picture of installed applications, follow these steps: Check all known uninstall registry keys  for software records. Look at the MSI Installer keys  for software installed via Microsoft’s installer service. Audit UWP (Microsoft Store) applications  in the Appx registry location. Search for file extension associations and application paths  to find recent usage. Check Registry last write timestamps , but be aware of system updates affecting accuracy. U se a forensic tool like Registry Explorer  to automatically aggregate relevant data into a table for easier analysis. -------------------------------------------------------------------------------------------------------- Final Thoughts By analyzing multiple registry locations , investigators can track not just what software is installed, but also when and how it was installed, updated, or even removed . However, timestamps can sometimes be unreliable due to system updates, so layering evidence from multiple sources is key to forming accurate conclusions. By mastering Registry analysis, forensic investigators can uncover hidden applications, track software usage, and even identify traces of deleted programs—making it a crucial skill in digital forensics! ------------------------------------------------Dean--------------------------------------------------

With more people working remotely than ever before, concerns about privacy and unauthorized access to microphones and webcams have grown . Windows now includes built-in tracking features that log when applications use these devices. This information is stored in the Windows Registry , making it a valuable forensic artifact for investigators. Where Does Windows Store Microphone and Camera Usage Data? Starting with Windows 10 (build 1903)  and continuing in Windows 11 , Microsoft introduced new Registry keys that log when applications access sensitive devices like microphones, webcams, and location services. These logs are stored in the following locations: For system-wide settings: SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore For user-specific settings: NTUSER\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore Each of these Registry locations contains subkeys that track permissions and usage details for different system capabilities. The ones of most interest to forensic investigators are: microphone  → Logs apps that accessed the microphone webcam  → Tracks camera usage location  → Monitors GPS or location data How Windows Tracks Application Activity Each application that requests access to the microphone or camera gets logged under these Registry keys . Microsoft applications (like Teams or Skype) are stored in dedicated keys, while other applications are grouped under a NonPackaged  key . Each application entry contains: Application Name and Path  – The full path of the program that accessed the device LastUsedTimeStart  – The timestamp when the application started using the microphone or camera LastUsedTimeStop  – The timestamp when the application stopped using it These timestamps are stored in Windows FILETIME format  (a 64-bit timestamp). Investigators can convert these values into readable date and time formats to determine e xactly when an app accessed the microphone or camera—and for how long. Why This Data Matters in Forensic Investigations This Registry data provides concrete evidence of microphone and camera activity , which can be useful in several scenarios: 1. Detecting Unauthorized Access If a user suspects their microphone or webcam was activated without their knowledge, forensic analysts can check these keys to see if any suspicious applications accessed them. 2. Identifying Malware or Spyware Not all applications that use the microphone or camera are legitimate. Malicious software that secretly records conversations or captures video might appear in these logs. If an unknown program shows up in the NonPackaged  section or is running from an unusual location, it could be malware. 3. Investigating Insider Threats In corporate investigations, these logs can help determine if an employee used unauthorized software for video conferencing or recorded private meetings . 4. Digital Evidence in Criminal Cases If an attacker used a victim’s device to make calls, record video, or capture audio , these Registry logs could serve as key evidence, showing when and for how long  the device was accessed. Let’s go through a real-world example. A few days ago, I was giving an interview on my personal laptop, and I wanted to check if these details were logged(In registry using Zoom and webcam) . As mentioned earlier, I examined the Registry to see if any records were generated. Refer to the screenshot below —you can see that the activity was indeed logged. Pay special attention to the timestamp , which is recorded in UTC format . Additionally, if you look closely, abive screenshot the logs also captured how long the session lasted , providing a detailed record of the event. Final Thoughts: A Valuable Source of Digital Evidence The C apabilityAccessManager  Registry keys provide an excellent resource for tracking microphone and camera usage . Whether you’re investigating a privacy concern, looking for signs of malware, or gathering digital evidence in a forensic case, these logs offer valuable insights. However, it’s crucial to cross-check this data with other forensic artifacts —such as event logs, system logs, and application history—to build a complete picture of user activity. --------------------------------------------Dean=-----------------------------------------

When it comes to forensic tools, MFTECmd.exe  is one of my go-to choices . It’s part of the KAPE suite and an incredibly efficient tool fo r parsing NTFS artifacts like $MFT, $J, $Boot, $SDS, and $I30. While I’ve always relied on it, many have requested a detailed guide, so here we are. --------------------------------------------------------------------------------------------------------- Before we dive into the details of this tool, I want to let you know that there are already a rticles available on parsing $J , $MFT , . You can check them out here: https://www.cyberengage.org/courses-1/ntfs-journaling ------------------------------------------------------------------------------------------------------- MFTECmd: Parsing the Master File Table (MFT) As the name suggests, MFTECmd is designed to parse the NTFS Master File Table (MFT) . Developed by Eric Zimmerman , t he tool converts MFT records into human-readable formats, making it easier to analyze files, including deleted ones, alternate data streams, copied files, and more. Here’s what makes MFTECmd  stand out: Fast Processing : It generates CSV or JSON output in under 40 seconds, even for large MFT files. Support for Volume Shadow Copies : With the --vss option, you can parse older versions of the MFT from Volume Shadow Copies. Deduplication : The --dedupe option helps eliminate duplicate entries, simplifying analysis. Command-Line Interface : While it may seem intimidating at first, its straightforward commands provide unparalleled flexibility. Command : MFTECmd.exe -f F:\C\$MFT --csv C:\Users\User\Downloads --csvf mft.csv Once you executed MFTECmd Output will look like below An Alternative: MFT Explorer If you prefer a graphical user interface (GUI), MFT Explorer , also by Eric Zimmerman, is an alternative to MFTECmd. Tree View : MFT Explorer presents parsed MFT data in a Windows Explorer-like structure, making it easier to visualize files and folders. Rich Metadata : It provides detailed information for each MFT record, including raw hex contents. Slower Performance : Due to its GUI and the sheer size of modern MFT files, loading can take up to an hour . While slower, it’s an excellent tool for learning about the MFT. It took me almost 10 minutes to get $MFT  opened in MFTEExplorer . But once loaded, it created a complete Windows-like structure for us . This is expected because the $MFT  (Master File Table) organizes the file system. See the screenshot above for a clear view. ------------------------------------------------------------------------------------------------------- What Did We Find? In this instance, I wanted to show you how to identify a file downloaded from the internet and retrieve the link it was downloaded from . This is also possible through N TFS Alternate Data Streams (ADS) , specifically the Zone.Identifier . If you’re new to the concept, I recommend reading this article: Unveiling File Origins: The Role of Alternate Data Streams (ADS) - Zone Identifier in Forensic Investigations ------------------------------------------------------------------------------------------------------------- Choosing the Right Tool I suggest trying both tools and deciding what works best for you. Personally, I find MFTECmd.exe  to be the best tool—it’s quick, easy to use, and highly efficient . But who knows, you might prefer MFTEExplorer  for its graphical interface. The choice is yours! Final Thoughts MFTECmd is a powerful, fast, and efficient tool that simplifies NTFS artifact parsing, helping forensic analysts uncover critical insights in record time. While MFT Explorer offers a more visual approach, MFTECmd remains my top choice for its speed and flexibility. Experiment with both to find what works best for you. Remember, the ultimate goal is to keep learning and refining your forensic skills. Keep learning, exploring, and experimenting with different tools. They all offer unique benefits and can deepen your forensic capabilities. See you in the next article! --------------------------------------------------Dean------------------------------------------

Updated on 18 Feb, 2025 Master File Table ($MFT) : The MFT is a database that stores information about every file and directory on an NTFS volume. It's essentially a metadata repository, containing records for each file, including its attributes and metadata. Understand the $MFT and there structure check out below article: https://www.cyberengage.org/courses-1/insights-into-file-systems-and-anti-forensics Collection: Investigation with Kape. We'll use KAPE to acquire the NTFS Master File Table ($MFT) and journals. Then, we'll employ MFTECmd to parse the MFT. Kape triage compound target , showcasing snippets of the MFT, $J, and link files targets. The output structure of Kape, with raw files and parsed outputs, is detailed, emphasizing the efficiency of this workflow in gathering artifacts for analysis. Kape can be used as GUI version or Cmd version its depend upon your preference need. command ---------------------------------------------------------------------------------------------------- Parsing: There is complete article written regarding parsing of $MFT using MFTExplorer/MFTECMD check out below https://www.cyberengage.org/post/mftecmd-mftexplorer-a-forensic-analyst-s-guide ---------------------------------------------------------------------------------------------------- Analyzing: Column Headers: As we begin our exploration, take note of the extensive list of column headers. These headers provide essential information about MFT entries, including file names, sizes, and crucially, timestamps. Understanding Timestamps: Each timestamp column corresponds to specific aspects of file operations, such as creation (B), modification (M), and access (A). The timestamps are presented in a hex format.  with hex 0x10 denoting $SI while hex 0x30 represents $FN ---------------------------------------------------------------------------------------------------- Detecting Time Stomping Time stomping can be detected by comparing these two time stamp $SI and $FN we can identify time stomping. You can learn more about Timestomping check out the article below: https://www.cyberengage.org/post/anti-forensics-timestomping ---------------------------------------------------------------------------------------------------- Interpreting Blank Timestamps:  You may notice some blank timestamps in columns ending with hex 0x30. These blanks signify that the $file name timestamps are identical to the corresponding $standard information timestamps. This design choice reduces noise in the data and directs attention to entries where timestamps diverge, aiding in identifying suspicious activities. ---------------------------------------------Dean---------------------------------------------------------

When it comes to forensic analysis, the $LogFile is one of those artifacts that hasn’t received as much attention as other NTFS structures. However, the $LogFile is packed with valuable forensic data, storing full details of changes to critical structures like the $MFT, $I30 indexes, $Bitmap, and even the $UsnJrnl itself. If i talk about parsing the $LogFile one of the best free tools available is LogFileParser  by Joakim Schicht. This tool simplifies the process of parsing the $LogFile and provides multiple output files that make sense of all the data it contains. Why Is the $LogFile Important? The $LogFile keeps track of changes happening within the NTFS file system. It records transaction logs, including file creations, modifications, renaming, and deletions . Even though it doesn’t store traditional timestamps for each event, it uses Log Sequence Numbers (LSNs)  to maintain order, which helps in reconstructing events over time. ------------------------------------------------------------------------------------------------------------ How LogFileParser Helps LogFileParser is designed to extract useful information from the $LogFile efficiently. The primary output file, LogFile.csv , provides an overview of what’s stored in the log. This file is massive, often containing over 100,000 rows  and 60+ fields , although not every field is populated for every entry. For a more targeted approach, the tool also generates: LogFile_INDX_I30.csv  – Extracts metadata from $I30 index entries, including file names, MACB timestamps, file sizes, flags, and MFT record numbers. LogFile_FileNames.csv  – Consolidates file and directory names found within the $LogFile, along with their corresponding MFT record numbers and LSNs. LSN value allow us to piece together the order of events. For instance, if you find a suspicious file in LogFile_FileNames.csv , you can track its LSN back to LogFile.csv   and analyze what actions were taken before and after that event. ------------------------------------------------------------------------------------------------------------ Recovering Deleted Files One of the most powerful features of LogFileParser is its ability to help recover deleted files. While the $LogFile doesn’t store actual file data, it does retain cluster run information , which tells us where data was stored on disk. This can be a game-changer if a file’s MFT record has been overwritten , as the original cluster locations may still be recoverable. To enable this feature, use the /ReconstructDataruns  option, which attempts to rebuild data runs for fragmented files—a task that traditional file carving techniques struggle with. ------------------------------------------------------------------------------------------------------------ How to Use LogFileParser LogFileParser comes with both a GUI  and a command-line interface . Running it is straightforward: By default, output directory next to the LogFileParser executable. To launch the GUI , simply double-click on LogFileParser.exe , which is typically located in: ------------------------------------------------------------------------------------------------------------ Alternative Tools: TZWorks Mala If you’re looking for an alternative, TZWorks’ Mala  is a solid commercial tool for analyzing the $LogFile. It’s incredibly fast, organizes data in a more readable format, and is actively maintained. Even if you’re not purchasing the tool, TZWorks provides excellent documentation  explaining how forensic artifacts work, making it a great reference for learning more about the $LogFile. ------------------------------------------------------------------------------------------------------------ Final Thoughts Parsing the $LogFile isn’t always the first thing that comes to mind in forensic investigations, but it can be incredibly useful. Whether you’re tracking file changes, recovering deleted metadata, or trying to reconstruct the timeline of an incident, tools like LogFileParser and Mala can help extract valuable information . If you haven't already, give LogFileParser a try and see what hidden details you can uncover from the $LogFile! -------------------------------------Dean----------------------------------------------------------

Updated on 18 Feb,2025 If you're digging into NTFS file system changes, the $UsnJrnl (Update Sequence Number Journal)  is one of the best forensic artifacts you can analyze. It keeps track of changes happening on the volume, making it a go-to resource for investigators. The good news? There are great tools  available to parse the $UsnJrnl. One of the best and my favorite tool is Eric Zimmerman’s MFTECmd . --------------------------------------------------------------------------------------------------------- If you want to learn running MFTECmd against $MFT Do check out below article https://www.cyberengage.org/post/mftecmd-mftexplorer-a-forensic-analyst-s-guide ------------------------------------------------------------------------------------------------------- How to Use MFTECmd to Parse the $UsnJrnl Running MFTECmd  against the $UsnJrnl is pretty much the same as running it against the $MFT (Master File Table) . The only difference? You need to specify the $J alternate data stream (ADS)  in addition to the $MFT file. Here’s two simple command to get started: In first command you will include the $MFT while parsing $J MFTECmd.exe -f G:\G\$Extend\$J -m G:\G\$MFT --csv "E:\Output for testing\Website investigation" --csvf usnjrnl.csv What’s Happening Here? -f G:\G\$Extend\$J → Points to the $UsnJrnl file . -m G:\G\$MFT → Includes the $MFT file  to cross-reference file entries and build full path information. --csv "E:\Output for testing\Website investigation" --csvf usnjrnl.csv → Outputs the parsed data into a CSV file  for easy analysis. This will generate a CSV file that contains every change recorded in the journal . In a real-world case, a forensic investigator ran this on a compromised system and parsed 384,493 records , covering 70 hours (about 3 days) of system activity . That’s a lot of valuable data! In Second command you will not include the $MFT while parsing $J MFTECmd.exe -f G:\G\$Extend\$J --csv "E:\Output for testing\Website investigation" --csvf usn.csv I know I know you will asked Dean whats the difference so let me show you with output screenshot With $MFT Without $MFT (As per screenshot its self explanatory: with $MFT you will get path of the exe without $MFT there is no path) ------------------------------------------------------------------------------------------------------------ ***Now if you following me you should have seen i have created an article Name Tracing Reused $MFT Entries Paths : Recovering Deleted File Paths Forensically with CyberCX UsnJrnl Rewind https://www.cyberengage.org/post/tracing-reused-mft-entries-paths-recovering-deleted-file-paths-forensically-with-cybercx-usnjrnl ****Good thing is if you use -m G:\G\$MFT while parsing $J file u do not have to download extra tool, you will get the same output ---------------------------------------------------------------------------------------------------------- Parsing Change Journals in Volume Snapshots One of the coolest things about MFTECmd  is that it lets you analyze volume shadow copies  (VSS). Since Windows maintains snapshots of the volume , you can extract past versions of the $UsnJrnl and extend your timeline even further. To do this, just add the --vss flag: mftecmd.exe -f G:\$Extend\$J -m G:\C\$MFT --vss --csv "E:\Output for testing\Website investigation" --csvf usnvss.csv What’s Different Here? Instead of running it on a single $J file , this command extracts data from all available volume snapshots . The result? Multiple CSVs , each containing records from different points in time. If you’re mounting a full disk image using Arsenal Image Mounter , you can run this command on the mounted drive (e.g., G:) to retrieve historical data. ---------------------------------------------------------------------------------------------------------- Avoiding Duplicate Entries Another handy feature in MFTECmd  is the --dedupe option. This checks the hash of each file  before parsing to avoid duplicate entries . While it’s rare for different snapshots to contain identical $J streams, this option saves time and storage  when working with large dataset s. mftecmd.exe -f G:\$Extend\$J -m G:\C\$MFT --dedupe --vss --csv "E:\Output for testing\Website investigation" --csvf usnvss.csv ---------------------------------------------------------------------------------------------------------- Alternative Tool: TZWorks' "JP" If you're looking for another solid tool, TZWorks' "JP"  is a great option for parsing the $UsnJrnl . It comes with advanced carving features , which means it can recover records even from partially corrupted  or deleted  change journals. This is super useful in forensic investigations where data integrity is an issue. ---------------------------------------------------------------------------------------------------------- Analyses of $J Output: Understanding Column Headers:  As we dive into the USN journal, the column headers are mostly self-explanatory. However, there's one column that warrants special attention - the "Update Reasons" column . Here file create, file delete, and rename, which provide detailed information about each file-related action recorded in the journal. Example Analysis: Suppose we search for an executable file named "New Text Document.txt" and identify its entry number in the journal. By filtering the journal entries based on this entry number, we can observe a chronological timeline of events related to this file. Reconstructing File Activity: In this example, we observe a series of operations involving the file " New Text Document.txt " We witness its renaming to "creds.txt.txt," . This sequence of events, captured in the USN journal, provides a comprehensive narrative of the file's journey on the system. ------------------------------------------------------------------------------------------------------------- Reference video: https://www.youtube.com/watch?v=_qElVZJqlGY&ab_channel=13Cubed ------------------------------------------------------------------------------------------------------------- Reference video: Final Thoughts The $UsnJrnl is a goldmine  when investigating file system changes. Thanks to tools like MFTECmd  and TZWorks' JP , forensic analysts can quickly extract, cross-reference, and analyze  these logs with ease. Whether you're examining a live system, a forensic image, or volume snapshots, these tools help uncover what really happened on a system —no guesswork needed. Happy hunting! 🔍🚀

Updated 18 Feb,2025 Now that we’ve got a solid grasp on how $UsnJrnl and $LogFile work, let’s dive into how we can actually use them for analysis. Which One is Easier to Read? If you quickly scan through both, you’ll notice that $UsnJrnl is much easier to understand . It’s well-documented, and Microsoft provides clear explanations for its codes . On the other hand, $LogFile events are messier and less documented, making their analysis trickier. Plus, a single file action can generate a flood of $LogFile events, adding to the complexity. However, $LogFile holds way more details about a file than $UsnJrnl does , including MFT attributes and $I30 index records. If you find something suspicious in $LogFile, it’s definitely worth the extra effort to analyze it. For more in-depth details, check out the presentation “NTFS Log Tracker”  from Forensic Insight—it’s a great breakdown of $LogFile analysis. Key Markers in $UsnJrnl and $LogFile Action $LogFile Codes $UsnJrnl Codes File/Directory Creation AddIndexEntryAllocation InitializeFileRecordSegment FileCreate File/Directory Deletion DeleteIndexEntryAllocation DeallocateFileRecordSegment FileDelete File/Directory Rename or Move DeleteIndexEntryAllocation AddIndexEntryAllocation RenameOldName RenameNewName ADS Creation CreateAttribute with name ending in “:ADS” StreamChange NamedDataExtend File Data Modification * Op codes for $LogFile often are not sufficient to determine file modification DataOverwrite DataExtend Data Truncation 1. Detecting File or Directory Creation $LogFile : Look for the combination of InitializeFileRecordSegment  and AddIndexEntryAllocation . This means a new “FILE” record was allocated in the MFT, and an entry was added to the parent directory. $UsnJrnl : The FileCreate  event is a clear indicator of a new file or directory . Simple and straightforward! 2. Detecting File or Directory Deletion $LogFile : Look for DeleteIndexEntryAllocation  and DeallocateFileRecordSegment  together. This means the file’s MFT record was removed and the index entry was deleted from the parent directory. $UsnJrnl : Just look for the FileDelete  event—it directly indicates a file or directory was deleted. 3. Detecting File or Directory Renaming $LogFile : A rename action shows up as DeleteIndexEntryAllocation  (removing the old name) and AddIndexEntryAllocation  (adding the new name). $UsnJrnl : You’ll see RenameOldName  followed by RenameNewName , showing both the old and new names in a clear sequence. 4. Detecting File or Directory Movement $LogFile : Just like renaming, a move generates DeleteIndexEntryAllocation  and AddIndexEntryAllocation  events. The difference? The file name stays the same, but the parent directory changes. $UsnJrnl : Similar to renaming, you’ll see RenameOldName  followed by RenameNewName . The key difference here is that the file’s location changes, but the name remains the same. 5. Detecting Alternate Data Stream (ADS) Creation $LogFile : If an ADS is created, a CreateAttribute  event will show up, referencing a stream name ending with :ADS. Since ADS creation isn’t super common, looking at these events can help you spot hidden or suspicious files. $UsnJrnl : The StreamChange event logs any ADS activity. If followed by NamedDataExtend , it confirms that data was added to a newly created ADS . Attackers sometimes delete ADS to evade detection, but spotting their creation is already a win. 6. Detecting File Data Modification $LogFile : This journal doesn’t directly track file data changes, but it does record metadata updates like timestamp changes, allocation status updates, and modifications to the $DATA attribute. $UsnJrnl : When a file’s content is modified, you’ll see a DataOverwrite or DataExtend  event, making it easier to track changes. ------------------------------------------------------------------------------------------------------------- Wrapping Up By combining insights from both $UsnJrnl and $LogFile, forensic analysts can uncover valuable details about file system activities. While $UsnJrnl offers a cleaner, high-level view, $LogFile provides deep, granular insights that can be critical in investigations. If you're looking to dive deeper into NTFS forensic analysis, checking out tools like istat for parsing MFT records and referencing the NTFS Log Tracker  presentation will help sharpen your skills. Happy hunting! ----------------------------------------------------------------------------------------------------------- Why Journal Analysis Matters Let’s say we’re investigating a file that was renamed, moved, and later deleted. With just the $MFT , if we're lucky and the file’s record hasn’t been overwritten, we can find out its last recorded name and location before deletion . But we won’t know when it was deleted—because $MFT timestamps don’t capture that event. Now, enter journal analysis. With it, we can see the entire history of the file: When and what it was renamed to When and where it was moved Exactly when it was deleted That’s a huge advantage! Having this level of visibility helps us reconstruct an attacker's actions, track malware movements, and understand what happened on a system. ----------------------------------------------------------------------------------------------------------- Smart Filtering for Better Insights Since both the $UsnJrnl and $LogFile track file system changes, we can use creative searches and filters to uncover critical details. A good starting point is a nalyzing the $UsnJrnl first —it has a longer history and is easier to read. Then, we can refine our investigation with the $LogFile for more granular details. Here are some high-value filters to consider: Key System Directories to Watch C:\Windows & C:\Windows\System32   C:\Windows\Prefetch   Temp Directories   C:\Users*\Downloads C:\Users*\AppData\Roaming\Microsoft\Windows\Recent C:$Recycle.Bin   A major win in an investigation is identifying where attackers store their tools and stolen data. Once we find their working directory, we can: Look for similar directories on other machines Identify additional Indicators of Compromise (IOCs) Recover deleted or moved files For example, if we discover the attacker’s directory, filtering the journals for activity in that location might show us files that were once there but are now missing. File Types Worth Searching Regardless of location, some file types are always worth investigating: Executables (.exe, .dll, .sys, .pyd) Scripts (.ps1, .vbs, .bat)   Archives (.rar, .7z, .zip, .cab) Known IOCs (file or folder names linked to the attack) Since searching for executables like .exe and .dll can produce a ton of results, it’s best to filter by directories of interest, such as System32 or Temp folders. ----------------------------------------------------------------------------------------------------------- Conclusion Using just the $MFT gives us a snapshot in time, but combining it with journal analysis gives us a dynamic view of file system activity. By filtering for key directories, attacker working directories, and high-risk file types, we can uncover hidden traces of an attack, track an attacker’s movements, and build a stronger case in our investigations. So, the next time you're diving into forensic analysis, don’t just stop at the $MFT—dig into the journals and see the full picture! ------------------------------------------------Dean------------------------------------------------