Hey everyone, First things first — I owe you an apology for going quiet. Life got a little hectic on the personal side and I had to step away for a bit, but I'm back now and planning to write and post a lot more frequently going forward. Good to be back. Before we get into today's topic, I want to mention something quickly — www.cyberengage.org/ started as just sharing knowledge, and honestly it's grown into something bigger than I expected. Because of that, I'm actually looking for writers who can contribute articles. If you're in writing for the blog, send me an email (apatel19800@gmail.com)— I'm happy to pay per article. --------------------------------------------------------------------------------------------------------- Now, let's get into it. If you've already read the complete cloud forensics guide — covering what artifacts to collect and how to investigate Box, Google Drive, and OneDrive — you know the foundation. If you haven't, go check that out first because today's article builds on it. https://www.cyberengage.org/courses-1/mastering-cloud-storage-forensics%3A-google-drive%2C-onedrive%2C-dropbox-%26-box-investigation-techniques Today we're going a step further and talking specifically about collection — how you actually go about acquiring this data, what tools to use, what trips people up, and why cloud drive forensics is genuinely different from regular Windows acquisition. --------------------------------------------------------------------------------------------------------- First, Understand What You're Actually Dealing With Back in the early days, cloud drive apps were simple. They synced a local folder to the cloud. You wanted the files? Go to the folder, grab them, done. That's not how it works anymore. The new generation of cloud apps lets you see every file in your cloud drive — even ones that aren't actually downloaded to your machine. You browse them, interact with them, but they're not sitting on the local disk. They're ghosts. And that creates a real headache when it comes to collection. Here's how each of the big three handles it, because they all do it differently: OneDrive is the most straightforward. When a file is cached locally it's physically in the OneDrive folder and a forensic image will capture it. Files that are cloud-only won't be there, but OneDrive at least shows you a Status column — blue cloud icon for cloud-only, green checkmark for locally available. Box Drive is trickier. It uses something called a callback filesystem — essentially a reparse point that redirects all filesystem activity in the Box folder to a virtualized volume. If you image the C drive, the Box folder looks completely empty. If the user is logged out or the app isn't running, the Box folder won't even exist. Google Drive for Desktop takes it even further. It creates a virtual mount point but only when the app is running and the user is authenticated. And here's a fun wrinkle — the mounted filesystem is FAT32, which breaks some acquisition tools including KAPE in certain configurations. --------------------------------------------------------------------------------------------------------- So How Do You Actually Collect This Data? If you have access to a live system with the user logged in, tools like FTK Imager (use "Contents of a Folder") or KAPE can logically acquire whatever's in that virtualized filesystem. Requesting those files may also trigger the app to automatically download cloud-only files and cache them locally — which sounds helpful but comes with two serious caveats. First, automatically pulling files from the cloud could push you outside your legal scope of authority. Get legal guidance before you let that happen. Second, those newly downloaded files get written to the disk, potentially overwriting unallocated space that might hold deleted evidence. You gain files and lose evidence at the same time. Going straight to the cloud and acquiring directly from the cloud instance is often cleaner — but that needs credentials and the right tooling. And it's not always the better option. If the user was running encryption that keeps data encrypted in the cloud, the local copy — even if incomplete — might be the only readable version you'll ever get. Plan your acquisition strategy before you start. This is new territory and winging it will cost you. --------------------------------------------------------------------------------------------------------- KAPE for Cloud Storage Collection KAPE, written by Eric Zimmerman, handles cloud storage collection well when used correctly. Box, Dropbox, Google Drive, and OneDrive all have dedicated target files in the default KAPE installation. They're split into Metadata targets and UserFiles targets so you can grab just the database metadata without accidentally pulling gigabytes of user documents. The compound targets — CloudStorage_Metadata.tkape and CloudStorage_All.tkape — reference all the individual app targets at once. --------------------------------------------------------------------------------------------------------- API-Based Collection: Going Direct to the Cloud Every major cloud provider exposes an API and there are forensic tools built around them. Google Takeout lets the user (or investigator with credentials) download everything — Drive, Gmail, contacts, calendar, Chrome history. Data comes out zipped with the original folder hierarchy intact. Google Workspace adds Admin Data Export, which lets admins export everything for every user in the organization — though it's all or nothing, no filtering. F-Response is a commercial tool that supports all the major platforms. Add credentials and it writes the cloud content to a VHD or local share. Magnet AXIOM has extensive cloud support built in — OneDrive, Google, Dropbox, Box, iCloud and more. With Google Workspace admin credentials it can collect across an entire organization. When the API allows it, AXIOM also pulls usage logs. One thing that gets overlooked constantly — file version history. Many providers keep multiple versions and expose them via API. Google Drive is a good example. If you only need to dig into a few files, manually browsing the web interface while recording your screen is honestly sometimes the quickest option. --------------------------------------------------------------------------------------------------------- The Windows Artifacts You Still Shouldn't Skip Here's what's easy to forget when you're deep in cloud collection mode — the machine itself is still full of evidence. Browser history is often the first clue a cloud app was even in use. Cloud storage URLs are surprisingly rich. They can show file sharing activity, access to deleted items, version history browsing, specific files opened, searches conducted, and even the user's email embedded in URL parameters. LNK files can show you files that used to be in a cloud folder even if they're long gone. A LNK referencing a OneDrive path is evidence that file existed there. The Recycle Bin is worth checking specifically for cloud storage paths. Deleted items often end up here before being permanently removed. Registry searches for terms like "OneDrive", "Google Drive", "My Drive", "Dropbox", and "Box" across user hives can surface files and folders that were once accessed — including the drive letter Google Drive mounted its virtual filesystem on. Alternate Data Streams — Dropbox tags files with ADS markers. Copy that file anywhere within NTFS and the Dropbox fingerprint follows it. --------------------------------------------------------------------------------------------------------- Bottom Line Cloud drive forensics is complex because the apps themselves are designed to blur the line between local and cloud. The strategy that works for OneDrive won't work for Box. Legal scope gets murky the moment files start auto-downloading. Plan before you acquire, cross-reference the local artifacts with your cloud collection, and don't walk past the browser history and LNK files — they'll often tell you things the cloud API won't. --------------------------------------------Dean----------------------------------------------------------- As mentioned at the top — if you're a writer want to contribute to the blog, I'm paying per article. Send me an email and let's talk. And if you want to see the full cloud forensics guide covering what artifacts exist across Box, Google Drive, and OneDrive — that's linked below. https://www.cyberengage.org/courses-1/mastering-cloud-storage-forensics%3A-google-drive%2C-onedrive%2C-dropbox-%26-box-investigation-techniques

So let's talk about something that doesn't get nearly enough attention in the digital forensics world — the FeatureUsage registry key. If you're investigating Windows systems and you're not checking this, you're genuinely leaving evidence on the table. ------------------------------------------------------------------------------------------------------------ Okay, But What Even Is FeatureUsage? FeatureUsage showed up in Windows 10 build 1903 and was first publicly reported by researcher Jai Minton. At its core, it's Windows quietly keeping tabs on how users interact with the taskbar and GUI applications — things like which apps were launched, how often they were in focus, how many notifications popped up, and even how many times someone right-clicked an icon. Now here's the part that makes investigators happy: this data doesn't disappear when an app gets uninstalled. That means if someone ran a VPN client, a privacy cleaner, or some sketchy chat app and then deleted it trying to cover their tracks? FeatureUsage still has the receipts. You'll find it sitting in the user's NTUSER.DAT file at: Since it's tied to individual user profiles, every user on the machine has their own copy of this data. ------------------------------------------------------------------------------------------------------------ The Subkeys You Actually Care About AppLaunch — "What Was Pinned and How Often Was It Clicked?" This one only tracks apps that were pinned to the taskbar — which is already telling you something useful. If an app is pinned, the user knew about it, used it enough to want it front and center, and actively kept it there. That's not an accident. Each pinned application shows up as a value, and the data field tells you exactly how many times that pinned shortcut was clicked to launch the app. Even if the user later unpinned it, the record stays. And because , you typically get the full file path — which is great for spotting apps running out of weird locations like temp folders or random AppData subdirectories. Malware loves hiding in unusual spots, and this key can expose that. AppSwitched — "Which Apps Were Actually Being Used?" While AppLaunch only covers pinned apps, AppSwitched casts a much wider net. This one tracks how many times any application became the active window — meaning keyboard input, mouse focus, the whole thing was directed at it. It even catches the original installer apps (think setup wizards), since those are GUI-based and require user focus to get through. In practice, you'll often see something like a browser absolutely dominating the count, which makes sense. AppBadgeUpdated — "How Many Notifications Did They Get?" This one tracks the notification badges that appear on taskbar icons — you know, like when your Slack icon shows "11 new messages." AppBadgeUpdated counts how many of those accumulated for each app. ShowJumpView — "Did They Right-Click and Dig Deeper?" When a user right-clicks a taskbar icon, they get a Jump List — quick access to recent files, saved sessions, frequent actions, etc. ShowJumpView counts how many times that happened per application. Here's a practical example: if Remote Desktop Connection shows 4 right-clicks in ShowJumpView, that strongly suggests the user was accessing saved RDP connections from the Jump List. Combine that with Jump List forensics and you've got a much richer picture of where they were connecting. TrayButtonClicked — The One People Always Forget This is the subkey that covers everything else on the taskbar — the clock, the Start button, the search box, Cortana, system tray widgets, all of it. And it's surprisingly powerful. Think about what the search box alone can tell you. If someone was running searches on a system, TrayButtonClicked will reflect that activity. Now imagine you're looking at a profile created during an attacker's RDP session — and you can see they were hammering the search functionality. That's a huge behavioral clue about what they were looking for on the machine. ------------------------------------------------------------------------------------------------------------ Why This Changes the Investigation? The thing that makes FeatureUsage genuinely powerful isn't any one subkey in isolation — it's the combination. You've got execution evidence even for uninstalled apps, focus and interaction evidence for everything GUI, passive engagement evidence even when apps weren't actively opened, deep interaction evidence through Jump List usage, and taskbar behavior evidence covering searches, clock use, and more. None of this gets wiped when someone uninstalls software and tries to clean up. That's a big deal. ------------------------------------------------------------------------------------------------------------ How to Use It Properly Cross-reference everything :- AppSwitched data hits different when you line it up against UserAssist and Prefetch. If all three are pointing at the same application, that's a strong execution timeline. Pay attention to deleted apps :- If AppLaunch shows a high execution count for a path that no longer exists on the system, something was there and it was used regularly before being removed. Sort by count :- High focus counts in AppSwitched = high user interaction. Start with the outliers. Watch for behavioral anomalies. A user who "never touches Jump Lists" but has 50+ right-clicks on a VPN shortcut? That tells a story. ------------------------------------------------------------------------------------------------------------ Bottom Line FeatureUsage tracks application usage at a granular level and survives uninstallations Use AppSwitched to counter "I never used that program" claims with hard numbers Use AppLaunch to find evidence of deleted or hidden applications Don't sleep on TrayButtonClicked — especially on attacker RDP profiles Always pair with Prefetch, BAM/DAM, and UserAssist for a full timeline ---------------------------------------------Dean-----------------------------------------------------------

Every craftsman will tell you the same thing — knowing your tools is half the battle. You could understand the Windows Registry inside and out, but if you're staring at raw hex dumps with no way to decode them, you're going to have a bad time. The good news? The forensic community has spent years building some genuinely excellent registry analysis tools. Some are free. Some cost money. Some have been around for a decade. One was practically rebuilt from scratch in a modern programming language. And one of them is, without much debate, the current gold standard. Let's walk through the lineup. ------------------------------------------------------------------------------------------------------------ The Main Players You don't need to use all of these. But you absolutely need to know  all of them — because the right tool depends on the job, the environment, and sometimes just what your employer's IT policy allows. ------------------------------------------------------------------------------------------------------------ The Concept Is King Before we go any deeper into Registry Explorer specifically, here's something worth burning into your brain: the tool is not what matters — the understanding is . This sounds like a motivational poster, but it's genuinely practical advice. Forensic tools change. Vendors stop updating. Better options emerge. If your entire skill set is muscle memory for one specific GUI, you're in trouble the moment that GUI isn't available. But if you deeply understand what  the registry contains and why  certain keys matter, you can pick up any tool — or even a raw hex editor in a pinch — and still do the job. That said, if you're going to master one tool, Registry Explorer is one of my favorite tool ------------------------------------------------------------------------------------------------------------ Registry Explorer — A Guided Tour Registry Explorer isn't just a registry viewer. It's closer to a full forensic workstation for registry analysis. Let's break down what you're actually looking at when you open it. ------------------------------------------------------------------------------------------------------------ Plugins: The Feature That Changes Everything Here's what separates Registry Explorer from a basic registry browser: plugins . Raw registry data is often encoded, compressed, or stored in binary formats that are completely unreadable to human eyes. A value might contain a list of recently opened files, but the raw bytes look like absolute gibberish. Plugins handle all of that decoding automatically. The moment you click on a key that Registry Explorer recognises — say, the Recent Documents key — a plugin silently fires in the background, decodes every value, and presents the results in a clean, sortable grid. No manual decoding. No looking up data formats. It just works. The best part? You didn't have to ask for it. The plugin system runs passively as you navigate. It's like having an expert sitting next to you who taps your shoulder every time something interesting appears. ------------------------------------------------------------------------------------------------------------ Searching Like a Pro The search functionality in Registry Explorer is where things get genuinely powerful for investigations. It isn't just a "Ctrl+F and hope for the best" situation. The Best way to use this find I have showed in USB Forensics Link below https://www.cyberengage.org/post/drive-letter-identification-and-volume-guid-and-user-mapping Complete USB Forensics: https://www.cyberengage.org/courses-1/usb-forensics ------------------------------------------------------------------------------------------------------------ Timeline Analysis — The Hidden Superpower One feature that doesn't get enough attention: the timestamp range search. It sounds mundane. It isn't. When you're responding to a compromise and you know roughly  when something bad happened, you can punch in a time window and ask Registry Explorer to show you every single key that was modified during that period — across all loaded hives simultaneously. Sort by timestamp, and suddenly you have a chronological trail of registry activity. You can watch a piece of malware establish persistence in real time, just from the registry's own timestamps. For root cause analysis — figuring out exactly what happened and in what order — this is genuinely one of the most powerful techniques available. And it's not a fancy add-on feature. It's just the search box with a date range. ------------------------------------------------------------------------------------------------------------ The Bookmarks Tab: Forensics on Rails For analysts who don't want to manually navigate to known-important registry locations every time, the Available Bookmarks  tab is a shortcut to every forensically relevant key across all loaded hives. Think of it as Registry Explorer's built-in list of "here's where the interesting stuff lives." Click a bookmark, land directly on the key, and the adjacent information panel updates with context. For newer analysts learning the ropes, this is an incredible guide to what the registry actually contains that matters. For experienced analysts, it's a time saver. ------------------------------------------------------------------------------------------------------------ The Honest Bottom Line If you only have time to learn one registry tool deeply, Registry Explorer is the right choice — not because the others aren't excellent, but because it covers the most ground, costs nothing, and is actively maintained by someone (Eric Zimmerman) who genuinely cares about the forensics community. But keep RegRipper in your back pocket. It's been running on real cases since before many current analysts were in the field, and its plugin library is a goldmine of institutional knowledge about what the registry contains and why it matters. Use the right tool. Understand the data. Never confuse the two. ------------------------------------------Dean-------------------------------------------------------------- Full series below: https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A

For More detailed one check out below article: https://www.cyberengage.org/post/tracking-usb-activity-through-event-logs-every-plug-tells-a-story Windows Event Logs are an excellent resource for investigating USB-related activities. These logs provide insights into when devices are connected or disconnected, driver installations, user actions, and more. Let’s break this down in simple terms. ----------------------------------------------------------------------------------------------------- Key Logs to Monitor for USB Activity System Log (Plug and Play Events) When a new USB or Plug and Play device is connected, Windows installs a driver, logging Event ID 20001  (start of installation) and 20003  (completion of installation). These events include details like: Timestamp  (when the installation occurred) Device Information  (Vendor ID, Product ID, iSerialNumber) Installation Status  (e.g., 0x0 means no errors). Limitation : Modern W indows versions (10/11) often log only Event ID 20003 by default. Example Use : Correlate timestamps with user logins to identify who connected the device. Security Log (Audit Removable Storage) Event ID 4663  is logged when files or folders on a removable device are accessed, created, or modified. Tracks: User Account  performing the action. Action Type  (e.g., file creation, deletion, or read). Object Name  (the specific file or folder). Challenge : The log does not directly tie file operations to a specific device. Investigators must cross-reference with other logs or artifacts. Security Log (Audit Plug and Play Activity) Event ID 6416  records every time a Plug and Play device is added. Provides: Detailed device information (VID, PID, iSerialNumber, volume name). Benefit : Unlike System Logs, these events are recorded each time a device is connected. How to Enable : Configure the “Audit PNP Activity” option in Advanced Audit Policy Configuration. Microsoft-Windows-Partition/Diagnostic Log Tracks detailed removable device activity, including when a device is connected or disconnected. Often used alongside Event ID 6416 and 4663 for a complete timeline. ----------------------------------------------------------------------------------------------------- Additional Logs for Device Activity Microsoft-Windows-DriverFrameworks-UserMode/Operational Log Available by default in Windows 7, but must be enabled in later versions. Logs connection and removal of devices, allowing you to determine how long a device was connected. MBAM/Operational Log (Microsoft BitLocker Administration and Monitoring) Tracks the mounting and dismounting of removable devices. Includes the volume GUID , which can help correlate device activity with registry data ----------------------------------------------------------------------------------------------------- Setting Up Auditing for USB Devices To make the most of these logs, you need to configure Windows to track the necessary events: Enable Removable Storage Auditing : Go to Advanced Audit Policy Configuration > Object Access > Audit Removable Storage . Enable both Success  and Failure  auditing. Enable Plug and Play Activity Auditing : Under Advanced Audit Policy Configuration > Detailed Tracking , enable Audit PNP Activity . ----------------------------------------------------------------------------------------------------- Key Takeaways Use System Logs  for identifying the first-time connection of devices. Rely on Security Logs  for tracking file and folder operations. Combine Event IDs 4663, 6416, and 20003  to get a complete picture of device activity. Cross-reference logs with the Registry  or other artifacts like Prefetch data  to match devices with user actions. Enable auditing policies to ensure detailed logs are captured. By strategically leveraging these logs, investigators can gain valuable insights into USB usage, even in environments with limited historical data retention. --------------------------------------------------Dean--------------------------------------------------

So, I had previously created a quick summary about USB activity, but I got a lot of requests asking for a more detailed version. That’s exactly why I’m here with this updated article! I’ve tried to keep things simple while adding a bit more depth so it’s easier to understand and actually useful. If you’re curious to learn even more, don’t forget to check out the full USB forensics series as well — it covers everything in much greater detail.. USB activity summary Windows Event Logs for USB Activity https://www.cyberengage.org/post/windows-event-logs-for-usb-activity USB Forensic Series https://www.cyberengage.org/courses-1/usb-forensics ------------------------------------------------------------------------------------------------------ There's a moment in almost every data theft investigation where the question becomes: did they use a USB drive?  Not whether they could  have — whether they actually did , when, and what they put on it. Windows Event Logs answer that question in remarkable detail. Not from one log, and not from one event ID — but from a layered set of logging mechanisms that, used together, can reconstruct every removable device interaction down to the individual file that was copied. The challenge is knowing which logs to pull, which event IDs matter, and how to connect the dots between them. ------------------------------------------------------------------------------------------------------ Let's walk through the whole picture. The Logging Ecosystem Before diving into specific events, it's worth understanding that USB forensics in Windows isn't a single artifact — it's a collaboration between three different log sources, each with different strengths and coverage ------------------------------------------------------------------------------------------------------------ The System Log: First Impressions Only The simplest entry point into USB forensics is the System log. When any new Plug and Play device connects and Windows tries to install a driver for it, Event IDs 20001 and 20003 fire — and they carry the device's identifying information including its serial number. The critical caveat: These events only fire for the first  connection of a specific device. Once the driver is installed, subsequent connections don't trigger new Plug and Play install events. So the System log tells you the device was ever  connected, and gives you the exact timestamp of that first introduction — but goes silent for every repeat visit. One important gap: The user account logged in at the time of device insertion isn't included in the Plug and Play events themselves. To connect a device to a user, you need to correlate the event timestamp with logon events in the Security log — or with USB registry artifacts that do tie connections to user sessions. Modern Windows (recent Win10 and Win11 builds) has shifted toward logging only EID 20003 by default, skipping 20001 entirely. ***Check both when analyzing a system, and don't assume absence of 20001 means no device was connected.**** ------------------------------------------------------------------------------------------------------------ The Security Log: Where Files Get Named If the System log tells you that  a device was connected , the Security log — when properly configured — tells you what happened on it . This is the capability that transforms USB forensics from "a device was plugged in" to "this user copied this specific file to this device at this exact time." Two audit settings unlock this capability: Audit Removable Storage  (EID 4663) — records every interaction with a removable device: files read, files written, files deleted, even attribute changes. Each event names the user account, the process responsible, and the operation type. The limitation is significant: The device is identified by a volume path like \Device\HardDiskVolume9\  rather than by serial number. You have to cross-reference with other artifacts to know which  device that volume path corresponds to. Audit PNP Activity  (EID 6416, Win10+) — records every device connection with full hardware identifiers: Vendor ID, Product ID, and iSerialNumber. Unlike the System log, this fires on every  connection, not just the first. And because it lives in the Security log, it's far more likely to have been captured by enterprise SIEM infrastructure than System log events. Neither is on by default. Finding them populated on a system you're investigating means someone proactively configured auditing — which itself tells you something about the environment's security posture. ------------------------------------------------------------------------------------------------------------ Connecting the Dots: A Real Scenario Here's how these events work together in practice. Two events, same device, four minutes apart — and between them, a complete picture of what happened. The Volume Path Problem Here's the gap in the middle of this whole system that you need to know about: EID 4663 doesn't include a device serial number . It identifies the device by its assigned volume path — something like \Device\HardDiskVolume9\ — which is a runtime assignment that changes every time the device is plugged in. This means if you only have EID 4663 events and no 6416 events, you can see file operations on a removable device but you can't definitively identify which  physical device it was without external help. The solution is correlation: Match the EID 4663 timestamp with a contemporaneous EID 6416 event showing the same volume path — that gives you the serial number Cross-reference with USB registry artifacts like USBSTOR and MountedDevices to confirm the device identity Once the volume path is tied to a physical device, every other EID 4663 event using that same path and Logon ID during that session can be attributed to the same device connection Once that link is established for a session, the Logon ID in EID 4663 events lets you track every single file operation that user performed on that device for the duration of their session ------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------ The Access Type Dictionary When EID 4663 fires, the Accesses field tells you what operation the user performed on the device. This field uses Windows access right terminology that can seem cryptic at first: AppendData  — a new file was written to the device. This is the exfiltration indicator. Data was copied to  the drive. ReadData  — a file on the device was read. Data was accessed from  the drive. Delete  — a file on the device was deleted. WriteData  — an existing file was modified. SYNCHRONIZE  — a standard access right that accompanies most operations; not meaningful on its own. The Process Name field is equally useful. explorer.exe means a human dragged and dropped or copy-pasted through the GUI. cmd.exe means command-line operation. robocopy.exe or xcopy.exe means a scripted or bulk copy. The process name tells you how  the transfer happened — and sometimes, whether it looks deliberate and scripted or like normal user behavior. ------------------------------------------------------------------------------------------------------------ The Big Picture USB forensics from event logs is a layered discipline. No single event ID gives you everything. But stack them correctly — 6416 to identify the device, 4663 to track the files, correlation with logon events to tie it to a user — and you can build a minute-by-minute record of every removable device interaction on a machine. That's not circumstantial. That's a chain of evidence built entirely from logs the operating system generated for its own purposes, long before anyone suspected they'd need to be reviewed.# ------------------------------------------------------------Dean--------------------

Part 1: https://www.cyberengage.org/post/meet-the-ce-sentinelone-assistant-i-built-it-for-myself-but-you-can-try-it-too 1. DFIR Investigation Tab The DFIR Investigation tab is the biggest addition to the CE S1 Assistant since launch. It takes a completely different approach to the problem — instead of helping you write queries to find things, it analyses logs you already have. Here is the workflow it was built around. You get an alert. You open SentinelOne Deep Visibility and run a query across the affected endpoint. You export the results as a JSON file. You upload that file to the DFIR tab. The tool processes it, anonymises all sensitive data, validates the result. You get a full incident report back — verdict, confidence, attack chain, indicators, immediate actions. The analysis that used to take an analyst an hour or two of manually correlating events gets done in seconds. And because the data is anonymized before it leaves your browser session, you can run it against real incident data without exposing confidential information. What the Upload Does? When you upload a Deep Visibility JSON export, the tool runs through four stages . These stages happen automatically — you do not configure them. Stage What Happens 1. Load & Parse Reads your JSON file. Handles both raw array exports and wrapped exports. Detects multi-endpoint files early. 2. Anonymise Replaces real usernames, hostnames, internal IPs, and client names with numbered labels (USER-001, ENDPOINT-001, etc.). Catches names anywhere they appear — in file paths, command lines, process names. 3. Validate Scans every field of every event for any real value that survived anonymisation. If anything is found, the submission is blocked and you are told exactly what needs fixing. 4. Build Brief Constructs a structured incident brief from the cleaned data — process timeline, DNS activity, network connections, file operations, and SentinelOne behavioural indicators — then sends it for analysis. The Anonymisation System — Why It Matters? This is the part I want to explain in detail because it is the part most people do not expect. When you are dealing with a real incident, the logs contain real data. Real names in file paths. Real hostnames. Confidential things in process arguments or script variables. If you paste that directly I, you have just sent potentially sensitive personal and business data. The anonymisation system I built specifically to prevent that. What Gets Replaced? Usernames — replaced with USER-001, USER-002, etc. (consistent across the entire file) Endpoint hostnames — replaced with ENDPOINT-001, ENDPOINT-002, etc. Internal IP addresses — replaced with INTERNAL-IP-001, INTERNAL-IP-002, etc. Company names — replaced with COMPANY-001 fragments (you specify these if needed) Credentials found in command lines — Bearer tokens, passwords, API keys — replaced with [REDACTED-CRED] Cloud keys — AWS AKIA keys, Azure AccountKey, api_key= values — replaced with [REDACTED-CLOUD-KEY] The replacement is case-insensitive and not path-based. If a username appears anywhere — in a fie path, in a process name, in a command line argument, in a script parameter — it gets caught and replaced. This works on macOS paths, Windows paths, and Linux paths without any configuration. The Validation Block? After anonymization, the tool runs a separate validation pass before it will allow the data to be analyzed . It scans every field of every event for any real value that survived — case-insensitively. Hard Block:  If any real username, hostname, or company name fragment is found anywhere in the cleaned data, the submission is blocked entirely. You see a list of exactly which values were found and in which events. This is not a warning — it is a hard block. The data does not move until the validation passes. This is deliberate. What You See in the UI? After upload and anonymisation, the tool shows you a summary panel before it runs the investigation: How many events were in the file What was replaced — a map of real name → anonymised label (visible in your browser only, never stored, gone on refresh) Event type breakdown — how many Process Creation, DNS, Network, File events Any behavioural indicators SentinelOne flagged in the raw data Any warnings (e.g. a hostname that looks like it might be a client machine) The real values shown in the mapping panel exist only in your browser session. They are never sent anywhere, never logged, and disappear when you refresh the page. What the Investigation Report Contains? Once the brief is built and validated, investigation starts. The report that comes back is structured into specific sections: Attack Chain — chronological reconstruction of what happened, from first event to last observed Indicators of Compromise — hashes, IPs, domains, file paths, process names extracted directly from the logs MITRE ATT&CK Techniques — technique IDs and names mapped to observed behaviours Additional Logs Needed — if the log window was too short or missing event types, the report flags what you should pull next Verdict — MALICIOUS / SUSPICIOUS / FALSE POSITIVE / INCONCLUSIVE Confidence — percentage confidence in the verdict with reasoning Key Findings — the three to five most important things the analysis found ------------------------------------------------------------------------------------------------------------- 2. Three Investigation Modes The DFIR tab does not do one thing. It has three distinct investigation modes because different situations call for different approaches. You select the mode before submitting. Mode 1 — Full Investigation Use this when you want the complete picture. You do not know yet what happened, or you want confirmation of what you suspect. You upload the JSON and let the tool do the full sweep. What it does: Builds a complete incident brief from all events in the file Perform full DFIR investigation. Returns the structured report covering attack chain, IOCs, techniques, verdict, and actions Best for: ·         New alerts where you do not yet know the scope ·         Confirming or ruling out a suspected compromise ·         Generating a report you can share with the team or document in a ticket Mode 2 — Targeted (Ask a Question) Use this when you have a specific question about the incident and you do not need the full report. You upload the same JSON, type your question, and the tool pulls out only the events relevant to that question. Examples of targeted questions: "Was there any lateral movement in this data?" "What persistence mechanisms were set up on this endpoint?" "Did the suspicious process make any outbound connections?" "Was there any credential access activity?" "Did anything run from a temp directory?" Instead of analysing the full event timeline, the tool uses a separate extraction function that filters and summarises only the events that are relevant to your specific question. This makes the response faster, more focused. The answer format is always: ·         YES / NO / CANNOT DETERMINE — a direct answer to your question ·         Evidence — the specific events that support the answer ·         Context — what those events actually mean in terms of attacker behaviour Mode 3 — IOC Hunt Use this when you have a list of IOCs — from a threat report, from a feed, from another analyst — and you want to know if any of them appear in your log data. You do not need a question. You just give it the IOCs and it tells you what matched. Input format — one IOC per line, any mix of: SHA256 / SHA1 / MD5 hashes IP addresses Domains and URLs (defanging is handled automatically — hxxp becomes http, [.] becomes ) File paths Process names Keywords What you get back for each IOC: ·         FOUND or NOT FOUND ·         How many times it appeared in the log data ·         First seen and last seen timestamps ·         Which processes were associated with it ·         Classification — TRUE POSITIVE / FALSE POSITIVE / SUSPICIOUS This mode direct pattern scan against the event data. ------------------------------------------------------------------------------------------------------------- 3. Follow-up Chat After an investigation runs — in any mode — there is a chat panel directly below the results. You can keep asking questions about the same incident without re-uploading anything. The way this works is important. The context from the investigation — the anonymised brief, the original report, the IOC list if you ran an IOC hunt — is carried forward into the conversation. What You Can Ask The follow-up chat is not a general assistant. It is grounded in the incident data from your upload. Things it handles well: Expanding on something in the report — "tell me more about that bypass" Asking about specific techniques — "what does xattr -c actually do and why does it matter?" Asking for a query based on findings — "give me an S1QL query to hunt for this on other endpoints" Asking about a specific IOC — "what is the typical behaviour associated with this process name?" Asking about next steps — "what else should I pull to confirm lateral movement?" Asking for a summary in a specific format — "summarise this for a non-technical stakeholder" Session Behaviour The conversation context resets if you upload a new file or refresh the page There is no history saved from the chat — if you need to keep something, copy it before navigating away ------------------------------------------------------------------------------------------------------------- 4. Sigma Rule Library Sigma is the universal detection rule format for the security community. Rules written in Sigma describe attacker behaviour in a way that can theoretically be converted to any SIEM or EDR query language. There are thousands of community-contributed Sigma rules covering almost every known attack technique. The problem for SentinelOne users is that Sigma rules need to be converted to S1QL before you can use them in Deep Visibility. The field names are different. The operators are different. Sigma uses logsource categories that need to be mapped to SentinelOne event types. Getting it right manually takes time and good knowledge of both formats. The Sigma Rule Library solves this in two ways. Part 1 — Pre-Converted Community Rules The library contains Sigma rules from the upstream community repository that have already been converted to S1QL and verified to work. You browse, filter, find what you need, and copy the query directly. Filter options: Platform — Windows, Linux, macOS, or all Severity — Critical, High, Medium, Low Status — Verified, Unverified, Failed (so you know which ones have been tested) MITRE ATT&CK tactic and technique Free text search across rule titles and descriptions Each rule card shows the Sigma rule title, the mapped MITRE technique, the severity level, the platform, and the converted S1QL query. You can expand the card to see the full query and copy it with one click. The library syncs from the upstream Sigma repository automatically, so it stays current as new community rules are released. Part 2 — Custom Sigma Converter This is the part I find most useful day to day. You paste any Sigma YAML — a rule from GitHub, a rule from a threat report, a rule a colleague sent you, or one you wrote yourself — and the tool converts it to S1QL immediately. What the converter handles: Field name mapping — Sigma's Image Logsource translation — mapped to S1 event types Operator conversion — contains, startswith, endswith, re translated to S1QL equivalents Detection logic — all, any, not conditions preserved in the S1QL output Validation — tells you if any part of the rule cannot be translated and why Why this matters:  Every time a new threat report drops with a Sigma detection rule attached, you no longer need to manually work out the S1QL translation. Paste it in, get the query, start hunting. The field mapping knowledge that used to live in your head is now handled automatically. ------------------------------------------------------------------------------------------------------------- 5. Query Feedback System In the original launch article I mentioned a feedback system was coming. It is live now. The problem it solves is straightforward. The natural language query generator is good, but it is not perfect. Sometimes a query comes back with a wrong field name. Sometimes the operator is right but the filter logic is off. Sometimes the query works technically but misses what the analyst actually needed. Before the feedback system, those issues would disappear. I would edit the query manually and move on. Nobody would know the generator got it wrong, and the same mistake would happen again for the next person who asked a similar question. How It Works — Analyst Side Every generated query now has a flag button next to it. If the query does not work — or does not do what you expected — you click it. You are asked two things: ·         What was wrong with the query? ·         What did you actually need? That feedback, along with the original input and the generated query, gets submitted and shows up in the admin review panel. You do not need to do anything else. How It Works — Admin Side The admin panel has a dedicated Feedback section that shows every submission. For each one you can see: The original natural language input the analyst typed The query the tool generated The feedback text explaining what was wrong Status — Pending, Reviewed, or Dismissed Submission timestamp Why This Matters Long-Term The quality of the query generator improves over time because the failure signals are visible. Without feedback, you are flying blind — you know the tool is not perfect but you do not know where or why. With the feedback system, you see exactly which inputs produce bad outputs and you can fix the prompt or the field schema specifically for those cases. ----------------------------------------------------Dean---------------------------------------------------- I'm still working on a fully offline, self-hosted version — something you can spin up yourself on your own machine. No cloud, no dependencies. It's not ready yet but I'm heads down on it — watch this space.

Press Windows + R. Type something. Hit Enter. That's it — that's the entire user interaction. What happens in the registry afterward is far more interesting. The Run dialog  has existed since Windows XP and hasn't changed much since. It's the power user's shortcut — a quick way to launch applications, open specific paths, fire up system tools, or connect to network resources without touching a mouse. Most casual users have never opened it. The ones who have tend to use it constantly . And that habit leaves a very clean trail. ------------------------------------------------------------------------------------------------------------ Why This Key Matters The Run dialog skews heavily toward technically proficient users — administrators, power users, developers, and, notably, attackers operating on a compromised machine. Someone who knows to press Win+R and type \\192.168.1.1\c$ to map a network share, or regedit to open the registry editor, or cmd /k whoami to check their privilege level — that's not an accidental user. That's someone who knows exactly what they're doing. Every command typed into that dialog gets preserved at: NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU The key maintains a full MRU list — most recent entry at position 0, with the Last Write Time of the key anchoring precisely when that most recent command was typed. Everything else in the list is ordered by recency, giving you a sequenced history of every Run dialog command this user ever typed on this machine. ------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------ Reading the List Like an Analyst The MRU ordering is your friend here. Position 0 is the most recent command — timestamped. Everything below it is ordered from most to least recent, giving you a behavioral sequence even without individual timestamps. That sequence is often more revealing than any single entry. A list that shows notepad → calc → explorer is a normal user having a normal day. A list that shows powershell -ep bypass -w hidden → cmd /k whoami /priv → \\192.168.1.50\c$ → regedit is someone working through a deliberate playbook. Commands worth flagging immediately: UNC paths (\\hostname\share or \\IP\share) — direct navigation to network resources PowerShell with execution policy bypass flags or hidden window arguments whoami, net user, net localgroup — reconnaissance commands runas — privilege escalation attempts Registry paths typed directly — someone who knows exactly where they're going in the registry Remote management tools — mstsc, psexec, wmic The Run dialog is a power user feature. When you find it populated with sophisticated commands, you're not dealing with someone who stumbled onto the machine. You're dealing with someone who knew exactly what to type — and left every keystroke in the registry for you to find. ---------------------------------------------Dean-------------------------------------------------------- Full Registry forensic Series: https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A

Windows has a dirty little secret. Every time you double-click an application, launch something from your taskbar, or open a file through the Start Menu, a registry key quietly takes notes. It records what you ran, how many times you ran it, when you last ran it, and — most fascinatingly — how long that application actually had your attention. That key is UserAssist . And it was never designed for forensics. It was designed to make your Start Menu smarter. The fact that it became one of the most powerful execution-tracking artifacts in Windows forensics is a beautiful accident. ------------------------------------------------------------------------------------------------------------- What UserAssist Actually Is UserAssist exists to populate the "most frequently used applications" list in the Windows Start Menu. To do that job, it needs to track GUI-based application launches — and it does so with remarkable granularity. The critical word there is GUI . UserAssist has no interest in: Background processes running silently Anything executed from a command terminal Scheduled tasks firing without user interaction If a human clicked something on screen and a window appeared, UserAssist probably knows about it. If a script ran in the dark, UserAssist missed it entirely. This scope limitation is important — it means UserAssist tells you specifically about human interaction , which is exactly what makes it so valuable. The key lives per-user in NTUSER.DAT : NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\ ------------------------------------------------------------------------------------------------------------- The Focus Time and Focus Count fields deserve special attention. Every other execution artifact tells you an application ran . UserAssist also tells you whether someone actually used it . An application that launched and immediately crashed will have a run count but near-zero focus time. An application that someone spent three hours inside will have substantial focus time. That distinction matters enormously in both insider threat and malware investigations. ------------------------------------------------------------------------------------------------------------- The GUID Problem — and Why It Actually Helps Here's where UserAssist gets architecturally interesting. The data isn't stored in one flat list. It's organized under subkeys named with GUIDs — each representing a different method  of launching the application. Most of these GUIDs are ghost towns. Users don't launch software through exotic methods, so those subkeys stay empty. Two GUIDs do almost all the heavy lifting: CEBFF5CD-ACE2-4F4F-9178-9926F41749EA   → Tracks applications executed   directly via .exe files  (e.g., double-clicking a program). F4E57C4B-2036-45F0-A9AB-443BCFE33D9F   → Tracks applications executed   via shortcuts  (e.g., Start Menu, taskbar, desktop shortcuts). ------------------------------------------------------------------------------------------------------------- Why It's So Hard to Read Raw The developers of UserAssist went out of their way to make it painful to analyze manually — and nobody quite knows why. The obstacles stack up: Application names are ROT-13 encoded  — a simple substitution cipher where each letter shifts 13 places. Paths use KNOWNFOLDERID aliases  instead of real folder paths — {6D809377-6AF0-444B-8957-A3773F02200E} instead of C:\Program Files\. These are documented but add a decoding step. All the actual execution data  — run count, focus time, last run time — lives in binary blobs at specific byte offsets within each value. In practice, nobody reads UserAssist raw. Registry Explorer's UserAssist plugin handles all decoding automatically — ROT-13, KNOWNFOLDERID mapping, and binary blob parsing — and presents clean, sortable, filterable output. But understanding what's happening under the hood means you can validate findings when it matters. ------------------------------------------------------------------------------------------------------------- The Accuracy Problem Nobody Talks About Enough Here's the uncomfortable truth about UserAssist: it's unreliable enough that you should never use it as a sole source of truth. The degradation in data quality from Windows XP through modern Windows 10/11 has been consistently documented, and specific quirks make overconfident claims dangerous: ------------------------------------------------------------------------------------------------------------- What to Actually Look For When you load UserAssist into Registry Explorer and the plugin decodes everything, you're looking at a sortable table of every GUI application this user ever launched. Here's how experienced analysts work through it: Sort by Last Run Time  to find what was running around your investigation window — this is almost always the first sort you do Filter by Program Name  when you have a specific application in mind — encryption tools, remote access software, data exfiltration utilities Sort by Run Count  to understand the user's baseline habits — legitimate heavy users show high counts for office apps and browsers; anything with a high count that shouldn't be there is a flag Sort by Focus Time  to find what the user was actually doing  rather than just what was open — the application with the most accumulated focus time is where this person spent their day Watch for remote access tools  — AnyDesk, TeamViewer, ngrok, Cobalt Strike — appearing in either GUID tells you a human ran a remote access capability on this machine Watch for admin tools  appearing on a non-admin user's machine — registry editors, process monitors, privilege escalation utilities ------------------------------------------------------------------------------------------------------------- The Bottom Line UserAssist is complicated, imperfect, and worth every minute you spend learning it. No other single registry artifact gives you focus time. No other artifact can tell you not just that an application ran, but that a person sat there using it  for a specific accumulated duration. The quirks and limitations aren't reasons to avoid it — they're reasons to understand it deeply. An analyst who knows UserAssist's failure modes can use it confidently. One who doesn't might stake a case on a run count that Windows quietly reset during the last Patch Tuesday. Use it as a compass. Let the other execution artifacts be your map. ------------------------------------Dean--------------------------------------------------------- Complete Series Below https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A

Most forensic investigations focus on what a user did with files on their own  machine. But there's a category of activity that flies under the radar of even experienced analysts: files accessed from — or exfiltrated through — Windows file sharing and offline caching mechanisms. A shared folder on a workstation. A cached copy of a network file that persists after the user disconnects. These aren't exotic attack techniques. They're built-in Windows features being used in ways their creators probably didn't intend forensic analysts to care about. And yet here we are. ------------------------------------------------------------------------------------------------------------ Why Shares Matter in an Investigation The most obvious scenario is also the most common: a user — deliberately or accidentally — shares an entire drive or sensitive folder over the network. Anyone on the same network can now access those files remotely, and unless you're specifically looking for active shares, you might never realize the machine was functioning as a de facto file server. This becomes critical in cases involving planted files or unauthorized access claims. If a machine has an open share pointing to C:\, and the investigation hinges on how  a specific file appeared in a specific folder, the existence of that share is a material fact. Files don't have to be physically copied to a machine if they can be written there remotely through an open share. The registry key that answers this question is: SYSTEM\CurrentControlSet\Services\lanmanserver\Shares\ Every share configured on the machine — including administrative shares — leaves an entry here. And each entry is surprisingly information-rich. ------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------ Client-Side Caching: The Silent Data Mover Now for the artifact that catches even experienced analysts off guard: Windows Offline Files  and its client-side caching (CSC) mechanism. Here's the scenario. An employee wants access to a sensitive network folder even when they're not connected to the company network — say, while working from home or traveling. Windows has a built-in feature for exactly this: offline files. When enabled, files from a network share get silently cached to the local machine at C:\Windows\CSC. From that point forward, they're available offline and remain on the local disk even after the network connection drops. From a forensics standpoint this is significant for two reasons. First, it means files that appear to belong on a network server may actually be sitting on a local workstation's hard drive — accessible, recoverable, and completely outside the normal chain of file access evidence. Second, it means a user could enable offline caching for a sensitive shared folder, wait for the sync, then disconnect and walk away with a local copy of everything — without ever explicitly copying a single file. The CSC flags recorded in each share's registry entry tell you exactly what caching behavior was configured. ------------------------------------------------------------------------------------------------------------ Putting the Two Pieces Together Shares and offline caching work as a system — and understanding their interaction reveals the full scope of potential data exposure. A share with CSCFlag = 16 or CSCFlag = 32 is quietly writing copies of every accessed file to C:\Windows\CSC. That means a network share that appears to live safely on a server is actually populating a local cache on whatever workstation connects to it with offline files enabled. The data has effectively moved from the network to the endpoint — and without any explicit copy action by the user. This has direct implications for several investigative scenarios: Unauthorized access claims : If someone argues they never had a local copy of a sensitive file, a populated CSC directory from a share with automatic caching enabled can directly contradict that claim. Exfiltration without explicit copying : A user who enables offline access to a sensitive share before a planned departure doesn't need to copy anything. The caching mechanism does it for them. And when they disconnect, the files are already local. Evidence recovery : Files cached in CSC may persist long after the share is removed or the network connection is severed. The cache directory becomes an independent source of evidence. ------------------------------------------------------------------------------------------------------------ The Accidental Share Problem One scenario worth calling out specifically because it comes up more than you'd expect: users who share their entire drive without realizing the consequences. Windows makes it surprisingly easy to right-click a folder, choose sharing options, and inadvertently expose far more than intended. Someone who wanted to share C:\Projects and accidentally configured sharing at C:\ has now granted network-level access to their entire filesystem — including system files, personal documents, cached credentials, and anything else on the drive. When this happens in an organizational context, and the machine is on a corporate network, the exposure window could be extensive. Any other machine on the network could have connected, browsed, and read any file on that drive — and unless detailed access logging was in place, there may be limited visibility into what was accessed. Documenting shares early, before evidence is potentially removed or altered, is a best practice that pays dividends throughout the investigation. -----------------------------------------------------Dean------------------------------------------

There's a category of forensic artifact that doesn't get the dramatic attention of malware persistence or network geolocation — but quietly delivers some of the most damning evidence in theft and intrusion cases. These are the artifacts that capture intent : what the user was searching for where they were navigating which files they were opening or saving. The registry keeps meticulous records of all three. And unlike many artifacts that require interpretation, these ones tend to speak for themselves. ------------------------------------------------------------------------------------------------------------ WordWheelQuery: A Window Into What They Were Looking For Every time a user types something into the Windows File Explorer search bar — or the Start Menu search in Windows 7 — that term gets quietly saved to a registry key called WordWheelQuery. It's been present since Windows 7 and has survived through every version since. The forensic value here is straightforward. If someone is searching for .rar files, they know compressed archives are present. If they're searching for a colleague's name, a project code word, or a folder path on a server, they're demonstrating prior knowledge of exactly what they were looking for. In data theft investigations, this key can be decisive. It's one thing to find a file copied to external media. It's another to show that, three minutes before the copy, the user searched for that exact filename. NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery The entries are stored in MRU order — most recent first — with the Last Write Time of the key anchoring the timestamp of the most recent search. Users can  clear this history through the Search Tools ribbon in File Explorer, so its absence on a suspicious machine is itself a data point worth noting. ------------------------------------------------------------------------------------------------------ TypedPaths: Proving Someone Knew Exactly Where to Go While WordWheelQuery captures searches, TypedPaths captures something subtly different and arguably more powerful: deliberate navigation. When a user manually types a path into the File Explorer address bar — rather than clicking through folder by folder — that path gets recorded in NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths Windows 10 and later stores the last 25 entries. What you'll find in here regularly: Network share paths  using UNC format (\\hostname\share) — revealing mapped or unmapped network locations the user navigated to directly External drive letters  (D:\, E:\) — potentially identifying removable media in use during the investigation window Hidden or deeply nested folders  that a casual user would never find by browsing IP address-based paths  that may correlate with specific network events in other logs If a path appears here, someone with access to that user account typed it or pasted it. Intent is essentially baked in. Common Dialog Keys: Cross-Application File Activity in One Place Now we step up to the most comprehensive of the three artifact families: the Common Dialog  keys. This is where Windows forensics gets genuinely elegant. Almost every Windows application — browsers, office suites, media tools, encryption software, forensic tools themselves — uses Microsoft's Common Dialog Box Library when presenting open and save file dialogs to the user. It's a shared system-level component. And because it's shared, all of that file interaction gets recorded in a single consistent location, regardless of which application triggered it. Think about what that means: instead of chasing application-specific file history across dozens of different registry locations, you get one unified view of nearly everything a user has opened or saved across their entire application ecosystem. OpenSavePidlMRU: Reading the File Extension Story  OpenSavePidlMRU answers what files The extension-based organization of OpenSavePidlMRU is one of those forensic design features that rewards careful analysis. At a glance you can see every file type  that's been touched through a dialog box — and certain extensions immediately flag areas of interest. A ps1 subkey tells you PowerShell scripts have been opened or executed through a dialog. A pst subkey means archived email files. A exe subkey is worth scrutinizing — running executables through the open dialog is atypical behavior. A dmp subkey could mean memory dumps. The * wildcard subkey deserves special attention because it cuts across all extensions — the last 20 files regardless of type. It's the broadest net, and often catches things that wouldn't appear in any specific extension subkey because the extension is unusual or absent entirely. LastVisitedPidlMRU: The Application Witness List LastVisitedPidlMRU answers which applications  — and that combination is powerful. Every application that's ever used a Windows common dialog to open or save a file leaves an entry here. Not the specific file, but the application executable name and the last folder it pointed to. The investigative implications: It's a roll call of every application that touched a file dialog, and the last place in the filesystem each one visited. For an analyst building a picture of user activity, it's as close to a behavioral profile as the registry gets. ------------------------------------------------------------------------------------------------------ A Word on the Taskbar Search Modern Windows muddies the waters slightly with the taskbar search dialog — originally Cortana, later decoupled into a standalone search component. This system-wide search capability touches far more than just local files: it queries the Windows search index, OneDrive, email, installed apps, and browser history simultaneously. Learn More about TaskbarSearch https://www.cyberengage.org/post/taskbar-featureusage-tracking-executed-applications Its registry footprint isn't as clean as WordWheelQuery, but items accessed through it do surface in standard Windows artifacts — the RecentDocs registry key, LNK files, Jump Lists, ShellBags, and browser history. The search itself gets cached in per-user AppData locations that vary by Windows version, but the results  of that search — the things the user actually clicked on — leave traces everywhere. The practical takeaway: don't assume a clean WordWheelQuery means no search activity occurred. The taskbar search operates in parallel, and its evidence trail just lives in different places. ------------------------------------------------------------------------------------------------------ Why These Three Artifacts Belong Together Search  reveals that a user was looking  for something TypedPaths  shows they knew where it was ComDlg32  proves they got to it and interacted with it . Used in isolation, each one tells a partial story. Used together, they reconstruct the full arc — from the moment a user started hunting for something, through their navigation to find it, all the way to the specific files they opened and where they ultimately saved them. ----------------------------------------Dean----------------------------------------------------------- Complete Series Below https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A   To Learn In deep check out below blog

If you could only look at one registry key to understand what a user has been doing on a machine, RecentDocs would be a strong contender for that slot. It's not the most dramatic artifact in Windows forensics. It doesn't catch malware or map network connections. What it does is something arguably more valuable in many investigations: it tells you, in meticulous order, exactly what files and folders a human being was interacting with . That word — human  — matters. Automated attacks don't open Word documents and browse through folder structures. When RecentDocs is full of activity, someone was sitting at that keyboard. ------------------------------------------------------------------------------------------------------------- What RecentDocs Actually Tracks The key lives at: NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs The parent key maintains a rolling list of the last 150 items opened of any type  — files, folders, and in Windows 10 and later, even newly created items before they're opened. Beneath it, a sprawling collection of child subkeys organizes everything by file extension. Each extension subkey tracks the last 20 items of that type, with a full MRU list recording the exact order in which they were opened. The Folder subkey gets special treatment — it tracks the last 30 folders accessed and stands alongside the extension subkeys as its own organized category. ------------------------------------------------------------------------------------------------------------- The Extension Subkeys Tell Their Own Story Before you even open the individual entries, simply seeing which extension subkeys exist under RecentDocs is informative . Subkeys only get created when a file of that type is accessed — so the presence of certain extensions is itself evidence. The extension inventory alone can tell you which applications were in use, what types of data were being accessed, and which areas of the filesystem to investigate next. ------------------------------------------------------------------------------------------------------------- Timestamps: The Complicated Part (And the Powerful Part) Here's where RecentDocs goes from useful to genuinely sophisticated — and where a lot of analysts leave value on the table by not understanding the timestamp mechanics fully. The raw data in RecentDocs is stored as binary, MRU lists are encoded, and timestamps don't work the way you might expect. Only registry keys have timestamps — individual values do not. So a key with 20 entries only has one timestamp: the Last Write Time, which reflects when the most recently used (MRU position 0) item was last interacted with. Registry Explorer's "Recent Documents" plugin handles all of this decoding automatically — but understanding what it's doing helps you interpret the results correctly. The Magic of MRU-Based Bracketing Here's where RecentDocs becomes more than just a file access log — it becomes a temporal reasoning engine. Even items without explicit timestamps carry investigative value because of their position in the MRU list. The MRU list is an ordered sequence: item 0 is the most recently accessed item 1 was accessed before that item 2 before that, and so on. Every item's position tells you its relationship to every other item's timestamp. Take the PDF in the example above Test3 .pdf. It has no timestamp of its own — it's not the most recently opened PDF, so it doesn't inherit the .pdf subkey's Last Write Time. But it sits between two items that do  have timestamps The result: even without a direct timestamp, you can say with confidence that PDF was opened somewhere between October 13 and October 15. In many investigations, a two-day bracket is more than sufficient to answer the question being asked. ------------------------------------------------------------------------------------------------------------- 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 . --------------------------------------------------------------------------------------------------------------------------- The Human Signal in RecentDocs There's one final observation worth making explicit. When you find rich, active RecentDocs data — documents opened, folders browsed, files saved — you're not just looking at file access history. You're looking at the footprint of a person  actively using a machine. Automated malware doesn't open Word documents to read them. Ransomware doesn't browse folder hierarchies through File Explorer before encrypting them — it operates programmatically. A busy RecentDocs key is, almost by definition, evidence of a human in the loop. ------------------------------------------Dean---------------------------------------------------- Check out complete Series Below: https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A

Two questions sit at the heart of almost every malware investigation: how did it survive a reboot?  And when did the machine actually go offline? The first question leads you into one of the most abused corners of the Windows operating system — autostart locations. The second leads you to a single registry value that quietly timestamps every clean shutdown the machine has ever had. Neither topic is glamorous. Both are essential. ------------------------------------------------------------------------------------------------------------- The Persistence Problem Here's the challenge with Windows autostart locations: there are a lot of them. Security researchers have catalogued well over 50 distinct places — called AutoStart Extension Points  or ASEPs — where a program can register itself to survive a reboot. A piece of malware only needs one  of them to work. The good news is that the most commonly abused ASEPs live in the registry, which at least consolidates the search. The most popular persistence locations on the planet are the Run keys  — a small family of registry entries whose entire purpose is to launch applications automatically when a user logs on. Notice that distinction: these keys fire at user logon , not at system boot. That's an important nuance when you're trying to understand the execution timeline of a compromised system. ------------------------------------------------------------------------------------------------------------- Reading the Run Keys: Normal vs. Suspicious When you pull up a Run key and see its contents, you're essentially looking at a list of everything that launches the moment a user signs into Windows. Most of it will be mundane — cloud storage clients, hardware utilities, update checkers. The skill is spotting the thing that doesn't belong. The services key is a harder problem. A well-used Windows system can have 500+ service entries. No analyst manually reads all of them — and attackers know this. Malicious services are often named to sound boring and official. What gives them away isn't the name: it's the executable path. Legitimate Windows services do not run from %TEMP% folders. They do not live in random subdirectories with names that don't correspond to their supposed function. The path is almost always the tell. ------------------------------------------------------------------------------------------------------------- Windows Services: Persistence with System Privileges Services are the second most common malware persistence mechanism in the wild — and arguably the more dangerous one. Unlike Run keys, which fire at user logon , services start at system boot, often before any user account is active , and run with elevated privileges in the background. The registry entry that governs all of this is: SYSTEM\\Services Every service and every device driver on the system has a subkey here. The key values tell you the service's display name, the path to its executable (ImagePath), its start type, the privileges it requires, and its dependencies. For persistence hunting, the two start values that matter are 0x02 (Automatic — starts at boot) 0x00 (Boot start driver — starts even earlier). The problem is volume. A heavily used Windows system can have 500 or more service entries. Manual review is impractical. The Registry Explorer Services plugin pulls all entries into a filterable table — filter for Start values of 0x02 and 0x00 , then scrutinize the ImagePath values for anything pointing outside of expected system directories. ------------------------------------------------------------------------------------------------------------- Shutdown Information: The Machine's Last Words Shift gears entirely. After the complexity of autostart analysis, this one is refreshingly simple — but it earns its place in every investigation. The registry records the last time the system shut down cleanly. This single timestamp, stored at: SYSTEM\\Control\Windows ...can answer questions that nothing else can quite answer as directly. How long has this machine been running? Was it powered on during the period being investigated? Did the user shut it down before handing it over — and if so, when? Does the shutdown time coincide suspiciously with an event you're investigating? ------------------------------------------------------------------------------------------------------------- Why Shutdown Time Matters More Than It Looks The Shimcache dependency is the one that makes shutdown time forensically critical beyond just confirming basic facts. Shimcache — the Application Compatibility Cache — is one of the most useful program execution artifacts in Windows forensics. It records applications that have been run on the system, and it's written to disk only when the machine shuts down cleanly. If the machine has been running for three weeks without a shutdown, Shimcache's registry entry is three weeks out of date. The most recent execution data lives only in memory. You need the shutdown time to know whether Shimcache is trustworthy, incomplete, or essentially useless for the period you care about . Similarly, when capturing a memory image from a live system, knowing how long the machine has been running tells you how far back in time that memory might stretch. A machine that booted this morning has shallow memory. A machine that's been running for a month has deep, rich volatile data that could be invaluable — if you capture it before the next reboot wipes it. ------------------------------------------------------------------------------------------------------------- Putting It Together Autostart locations and shutdown information seem like opposite ends of the spectrum — one is about things that persistently run, the other is about a single moment in time. But they're connected by the same underlying investigation logic: understanding the lifecycle of the machine. What was running on this system how did it survive reboots when was the machine last powered down — these questions together tell you whether you're looking at a healthy system, a compromised one, or a machine that someone tried to clean up in a hurry before handing it over. The registry will tell you. You just have to know where to look — and now you do. ------------------------------------------------------------------------------------------------------------- Full Series Below https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A