⚡ CE S1 Assistant So, Why Did I Build This? Let me be real with you — I built this tool for myself. That’s it. No grand master plan, no startup pitch deck. Just a guy who got tired of the same problem every single time he opened SentinelOne Deep Visibility. If you’ve ever used Deep Visibility, you know exactly what I’m talking about. You get an alert, you need to hunt across your endpoints fast , and you open that query box... and then you’re sitting there trying to remember the exact field name. Is it src.process.name or dns ? Does the operator use contains  or matches ? One wrong character and your query returns absolutely nothing. S1QL — SentinelOne’s query language — is powerful. Really powerful. But it’s also very specific. It takes months to get comfortable with the syntax, and even then you’re constantly checking the documentation for edge cases. I’d find myself spending more time formatting the query than actually thinking about the threat. So I thought: what if I could just describe what I’m looking for in plain English  and get a production-ready query back? No syntax memorisation. No documentation diving. Just say what you need and get a query you can copy straight into the console. That’s the CE S1 Assistant. That’s why it exists ------------------------------------------------------------------------------------------------------------- What Is It, Exactly? The CE S1 Assistant is a web-based tool that lives at https://s1copilot.onrender.com/ It does one job and it does it well: it helps security analysts write better SentinelOne Deep Visibility queries, faster. It has three main modes for generating queries: 1. Natural Language to S1QL  — You type what you want in plain English. The tool gives you a working S1QL query. Done. 2. Threat URL to IOC Hunt Query  — You paste a threat intelligence article URL. The tool reads the entire article, pulls out every IOC it can find, and builds a multi-layered detection query automatically. 3. Direct IOC Input  — You paste hashes, IPs, or domains directly. You get an exact-match detection query back. On top of query generation, the tool also has a live threat intelligence dashboard that pulls from eight industry feeds — so you have context before you even start hunting. But let me walk you through each feature properly. ------------------------------------------------------------------------------------------------------------- The Natural Language Query Generator This is the main event. The feature I use the most, and honestly the reason the whole tool exists. You type something like: “show me all unsigned processes that ran from AppData in the last hour”   and the tool generates a complete, valid Powerquery with the correct field names, operators, filters, and output columns. Or maybe you’re thinking bigger: “find ransomware behaviour on Windows endpoints” . Akira ransomware detection with behavior It handles that too. It knows what behaviours typically indicate ransomware — file encryption patterns, shadow copy deletion, ransom note creation — and builds a query that covers those angles. What makes this actually reliable and not just a party trick is that it’s built on a deep knowledge base of SentinelOne’s exact field schema — over 80 validated field names. It knows S1QL-specific operators. It understands platform differences — Windows paths vs macOS paths vs Linux paths. And it avoids the common PowerQuery pitfalls that trip people up. You can also throw IOCs into the natural language input — it’ll combine them with your behavioural description and give you a single query that covers everything. Super useful when you have partial intelligence and a hunch. ------------------------------------------------------------------------------------------------------------- Threat URL to IOC Hunt Query This is the feature that I’m honestly most proud of, and I think it’s what sets this tool apart from anything else out there. Here’s the scenario. A new threat report drops — maybe from CISA, maybe from a vendor blog, maybe from a researcher on Twitter. You read through it, you manually copy the IOCs into a spreadsheet, you format them into S1QL queries, you double-check the syntax... and 45 minutes later you finally have something you can run. With the CE S1 Assistant, you just paste the URL . That’s it. The tool fetches the article, reads every section including tables, code blocks, appendices, and footnotes, and extracts every confirmed IOC it can find: SHA256, SHA1, MD5 hashes IP addresses — C2 servers download servers. Domains and URLs. Malware-specific file paths. Process names and command line patterns. Even registry keys for Windows persistence. Then it builds a multi-layered IOC hunt query covering all detection angles: process hashes, file hashes, network connections, DNS requests, URL access, file path creation, and command line execution. Each block is commented so you know exactly what each section is catching. I tested it against the SparkRAT threat intelligence report from hunt.io , and the results were impressive — it correctly extracted 3 SHA256 hashes, 4 C2 IPs, 18 C2 domains, 6 malware-specific file paths, 4 process names, and 2 command line IOCs. It built a production-ready 7-block detection query with zero manual input from me. ------------------------------------------------------------------------------------------------------------- The Threat Intelligence Dashboard Before you hunt, you need context. What’s active right now? What CVEs are being exploited in the wild? What C2 infrastructure is live? The CE S1 Assistant pulls live threat intelligence from eight industry sources and surfaces it right in the dashboard: CISA KEV for known exploited vulnerabilities, AlienVault OTX for community threat reports, MalwareBazaar for malware samples, ThreatFox for IOCs from active threat actors, Feodo Tracker for botnet C2 infrastructure, URLhaus for malicious URLs, MITRE ATT&CK for technique mapping, IPsum + C2-Tracker for high-confidence malicious IPs. All feeds sync automatically every 24 hours, and you can trigger a manual sync any time. The part I really like is that every threat entry in the dashboard has a one-click “Generate Query”  button — so you see a threat, you click the button, and you’ve got a hunt query ready to go. I’m adding more feeds and working on integrating my own intelligence so I can connect it all together. ------------------------------------------------------------------------------------------------------------- The Query Library — 70 Prebuilt Queries Not every hunt starts from scratch. Sometimes you just need a solid starting point — a known-good query for a common scenario that you can tweak for your environment. The Query Library has 70 curated, validated S1QL queries covering the most common threat hunting scenarios across all major platforms. Windows stuff like credential access, lateral movement, and privilege escalation. macOS persistence via LaunchAgents, TCC bypass, keychain access. Linux cron persistence, reverse shells, rootkit indicators. Defence evasion techniques like PowerShell abuse, LOLBins, AMSI bypass. And exfiltration patterns like DNS exfil, cloud upload detection, and C2 beaconing. Every query is categorised, tagged, and ready to copy. If you’re just getting started with threat hunting in SentinelOne, this library alone will save you weeks. ------------------------------------------------------------------------------------------------------------- Custom Rule Generator (STAR Rules) Beyond ad-hoc hunting, SentinelOne has STAR rules — these are detection rules that run continuously and trigger responses in the console. you can also use them for hunting. They use a different syntax from Power Query, which means you need to learn yet another format. You can give it IOCs directly to CE S1 Assistant and it’ll create a custom rule, or you can use the same output for Deep Visibility hunting — your choice. ------------------------------------------------------------------------------------------------------------- Query History Every query you generate gets saved to the history log with full context — the original input, the generated query, MITRE ATT&CK technique tags, severity rating, token usage, and estimated cost. You can review, copy, and reuse past queries without regenerating them. It’s one of those features that sounds small until you’ve been using the tool for a week and you’re constantly going back to previous queries. ------------------------------------------------------------------------------------------------------------- Who Is This For? Like I said — I built this for myself first. Every time I needed to write a query, I was tired of digging through documentation to find the right field format. Now I just describe what I want and get a query back. But if you’re any of these people, it’ll probably help you too: Experienced threat hunters  — You know exactly what you’re looking for, but S1QL syntax slows you down. This lets you hunt at the speed of thought. Junior SOC analysts  — You understand threats conceptually, but you haven’t had time to master S1QL yet. Now you can generate queries on day one and learn from the output. Incident responders  — A new threat report drops and you need a detection query in minutes, not hours. Paste the URL, get the query, start hunting. ------------------------------------------------------------------------------------------------------------- What’s Coming Next I’m working on a query feedback system so analysts can report issues directly and I can fix things from the backend. There’s also a syntax validator in the works that will check query structure before you paste into SentinelOne. And I’m planning multi-instance sync so you can share query history and threat intel across deployments. I’ve got a lot of ideas. It’s going to keep getting better.   ------------------------------------------------------------------------------------------------------------- Want to Try It? The tool does have running costs, so I’m not leaving it wide open — but if you want to test it, just ping me on LinkedIn . I’ll create an account for you so you can give it a spin. I’ve got a lot of friends who use SentinelOne, and anyone who wants to try it is welcome. No catch, no sales pitch. I just want feedback from real analysts who use S1 every day. The tool is live at: https://s1copilot.onrender.com/   ------------------------------------------------------------------------------------------------------------- About Cyberengage So why name Cyberengage? Honestly, it because of my website — I was solving a problem for myself and figured other people might find it useful too. Cyberengage is my platform for practical knowledge. Not theoretical. Not 200-page whitepapers. Actual to information anyone can use to get start with Security today. The CE S1 Assistant is the first major one is my first project. If you want to follow along, check out https://www.cyberengage.org/ . And if you have ideas for tools you wish existed, I’m always listening. --------------------------------------------------Dean----------------------------------------------- Look, I'm not going to pretend this tool is perfect — no tool is. But I've worked hard to get it as close as possible. You might get false positives or queries that need tweaking. That's normal. You narrow those down, adjust the filters, and you're good. The goal was never to replace your judgment — it's to save you the 20 minutes you'd spend fighting syntax so you can focus on the actual hunt."

Okay, I know — another SentinelOne article. But hear me out. What I'm about to show you changed how you think about detection engineering, and I genuinely can't stop thinking about it. If you've been following this series, you already know I covered the Detection Center in the last article. https://www.cyberengage.org/post/sentinelone-detection-center-library-rules-emerging-threats-and-what-it-all-actually-means Go check that one out if you haven't — link at the top. But today? We're going somewhere slightly different. We're talking about Indicators — and specifically, why they might be one of the most underrated features SentinelOne quietly ships with every agent deployment ----------------------------------------------------------------------------------------------------------- Let's Start With What You Already Know If you've spent any time with SentinelOne, you know about Deep Visibility. That's the data lake where S1 stores everything the agent captures — every process creation, network connection, file event — retained for as long as your subscription allows. It's basically a time machine for your endpoints. You also know S1 has detection engines running under the hood. We touched on those into my SentinelOne series. But here's the thing I want to highlight today: those engines aren't just detecting threats — they're also tagging events with metadata. Specifically, they're attaching what SentinelOne calls Behavioral Indicators. ----------------------------------------------------------------------------------------------------------- So What? Why Should I Care? Here's the thing most people miss: you don't need a hash, a domain, or an IP address to write a detection rule. You can write a STAR Custom Rule using just an indicator name. I know what you're thinking — "that's going to fire everywhere, false positives galore." And yes, you'll need to tune it. But let me show you how powerful this actually is with a real-world example. That single line. That's it. No hashes, no IPs, no paths. Just an indicator name that SentinelOne's engine already stamps on suspicious events in Deep Visibility. ----------------------------------------------------------------------------------------------------------- How This Actually Caught an Infostealer This is where it gets real. A massive thank you to my friend Jeremy Jethro . He's the reason I'm writing this article. An alert triggered. On the surface it looked completely unremarkable — Visual Studio activity, something most analysts would glance at and close as a false positive. But the alert was triggered based on a behavioral indicator, not a signature . And Jeremy being Jeremy, he didn't just close it. He dug. What he found underneath was a full infostealer execution chain. Here's a sanitized summary of what the timeline looked like: The entire above chain — discovered because of one behavioral indicator that an analyst almost dismissed as a false positive. ----------------------------------------------------------------------------------------------------------- The Real Lesson Here SentinelOne — like every EDR — will miss detections sometimes. That's just reality. But here's the thing people get wrong: a missed detection doesn't mean missed data. Deep Visibility is capturing everything, every second, and the agent is silently tagging behavioral activity the whole time. Your job as a detection engineer or threat hunter isn't to wait for an alert to fire. It's to build rules that surface what the engines are already seeing . Behavioral indicator-based STAR rules are exactly how you do that. One note: there is a delay in STAR Custom Rule detection. I've written a full breakdown of that elsewhere but the delay doesn't mean you ignore it. It means you account for it. -----------------------------------------------------------------------------------------------------------

Okay let me be real with you for a second. Browser forensics manually? It's a pain. You're digging through SQLite databases, remembering artifact locations, writing queries — and if you're doing it with free tools, it only gets worse. I actually built a full series on how to do this manually if you want to go deep on it — link here: https://www.cyberengage.org/courses-1/introducing%3A-browser-forensics-%E2%80%93-your-ultimate-guide-to-manual-analysis But today? I found a tool that makes all of that dramatically simpler. And it pairs beautifully with KAPE, which if you know me, you know I love. ------------------------------------------------------------------------------------------------------- Step 1 — Collect Your Artifacts With KAPE Before the tool does anything, you need to actually collect the browser artifacts off the system. KAPE handles this perfectly. If you're running PowerShell: If you prefer the GUI, even easier — just tick WebBrowsers as your target. ------------------------------------------------------------------------------------------------------- Step 2 — Meet the Tool Drum roll... 🥁 https://github.com/acquiredsecurity/forensic-webhistory That's it. That's the tool. And I genuinely love it. What makes it special? You can run it on Windows, WSL, Linux, or Mac. Doesn't matter where the evidence came from — Mac, Windows, whatever — the tool just reads the SQLite files directly. Cross-platform by nature. ------------------------------------------------------------------------------------------------------- Running It on Windows Download the executable, run as Administrator, and you get this menu: Select 1 , point it at your KAPE output folder, choose where you want results saved, hit enter — done. About a minute later you have a clean Excel output. That's it. No SQL queries, no manual path hunting. Output! (Analyse all the output with my another favorite tool Timeline explorer) ------------------------------------------------------------------------------------------------------- What Browsers Does It Support? ------------------------------------------------------------------------------------------------------- Bonus — Parsing Mac Evidence on WSL This is where it gets cool. I had a Mac artifact set collected using UAC (Unix Artifact Collector) and I wanted to parse it on Windows via WSL2. Here's the exact command I ran: MAC output in excel ------------------------------------------------------------------------------------------------------- W hy I Actually Like This Tool Look, paid tools like Magnet AXIOM or Cellebrite make this trivial — but they cost money, sometimes a lot of it. This tool gives you clean Excel output, covers every major browser, runs cross-platform, and pairs with KAPE out of the box. For anyone doing DFIR on a budget or just learning the craft, this is genuinely one of the best free tools out there right now. Go try it. You'll get it immediately. ------------------------------------------------------------------------------------------------------- If this helped — share it, react, drop a comment. More coming. -----------------------------------------------Dean----------------------------------------------

Okay so if you've been following this SentinelOne series, you know we've covered a lot of ground. Complete Series: https://www.cyberengage.org/courses-1/mastering-sentinelone%3A-a-comprehensive-guide-to-deep-visibility%2C-threat-hunting%2C-and-advanced-querying%22 But this one is genuinely exciting — SentinelOne just dropped something that takes a big burden off security teams, especially those who don't have the time or expertise to write custom detection rules from scratch. It's called the Detection Center, and the headline feature is the Library tab — a collection of pre-built detection rules created by the SentinelOne research team that you can switch on immediately. No query writing. No logic to figure out. Just activate and go. Before we dive in, I actually researched more about this — things that weren't immediately obvious from the documentation. And Answers cleared up a lot of confusion, and I'm including everything that I learned throughout this article. So this isn't just a feature walkthrough — it's the feature walkthrough plus the answers you'd get if you spent 60 minutes researching more or asking support team. ----------------------------------------------------------------------------------------------------------- What Is the Detection Center? The Detection Center is the new unified home for all your detection rules — both the ones you write yourself and the ones SentinelOne's research team maintains. You get to it from the sidebar: click Detections . It has two tabs: Custom tab  — this is where your own rules live. Everything you've built, everything you're managing yourself. You can view, edit, create, and manage rules here. Library tab  — this is the new bit. Pre-built, advanced detection rules from the SentinelOne research team, ready to activate. The full-screen view shows you each rule's name, description, severity, MITRE tactics, data source, category, status, and when it last triggered an alert. One important thing to understand up front: the Detection Center is available in the Singularity Operations Center (SOC) interface only . If you're still on the legacy Management Console, you won't see the Library tab there. More on why that matters in a moment. ----------------------------------------------------------------------------------------------------------- The Question I Researched— Console Availability When I first saw that library rules were only in the SOC interface, my immediate question was: why?  And more importantly — if I enable rules in SOC, do they do anything if I'm still partly using the legacy console? Here's exactly what I found: ----------------------------------------------------------------------------------------------------------- How Library Rules Are Different From Your Existing Detection Engines This was probably the most important question I had. SentinelOne already has detection engines — behavioral AI, static AI, reputation — so what exactly do these library rules add ? The answer is that they're entirely separate. The engines run automatically on endpoint activity using SentinelOne's core AI. Library rules are query-based  — they look at your telemetry data (stored in Singularity Data Lake) and fire when a specific set of conditions is met. You're essentially telling the platform "alert me whenever X, Y, and Z happen together." They don't replace the engines. They sit alongside them and expand what you can detect — especially for scenarios the engines weren't built for, like cloud activity, identity events, or very specific behavioral patterns that require correlating multiple data points. ----------------------------------------------------------------------------------------------------------- The Three Categories of Library Rules Not all library rules behave the same way. SentinelOne has split them into three enablement categories, and understanding this is important before you start activating things. Auto enabled by default  — these are turned on across all environments automatically. You don't need to do anything. You can disable them if they're not right for you, and your opt-out choice will be remembered even after platform updates. Disabled by default  — available in the library but you have to manually switch them on. These are typically more specialised rules that don't make sense for every environment. Emergency detection  — this category is activated immediately in response to global outbreaks. If there's a major zero-day or widespread attack campaign happening, SentinelOne can push these out automatically. Example: Emergency detection ----------------------------------------------------------------------------------------------------------- Most Important Emerging Threat and Core Rule Labels Inside the library you'll see two label types on certain rules: Emerging Threat  and Core . Here's what they mean. Core   rules are rules that SentinelOne recommends for most environments — broadly applicable, well-tested detections. Emerging Threat  rules are specifically about evolving cyberattacks — newer tactics, active campaigns, things that are happening right now rather than established patterns. You can bulk-activate rules by label using the Automatic Detections by type  button in the top-right corner of the Detections dashboard. Click it, select the labels you want, and hit Save. When an alert is triggered by one of these labelled rules, the label appears next to the alert name in the Alerts page. One display note from the documentation: due to space constraints in the UAM drawer, only a single label is shown even if a rule has both. Emerging Threat takes display priority over Core. ----------------------------------------------------------------------------------------------------------- Activity Logs — What Gets Recorded When You Change Rules Every time you enable or disable Emerging Threat or Core rules at any scope level, an activity log entry is generated. This matters for audit trails and change management. ----------------------------------------------------------------------------------------------------------- My Question About EDR-Specific Rules Here's something that genuinely confused me when I first looked at the library. A lot of the rules are for CloudTrail, Okta, and other non-endpoint sources. So I wanted to know : is there a way to filter down to just the rules that are relevant to traditional EDR? Their answer was simple and useful: ----------------------------------------------------------------------------------------------------------- New Workflow Features — Alert Simulation and Multi-Instance View Two more features worth calling out quickly. Alert Simulation  lets you test a rule against recent ingested data before  activating it in your live environment. You can see what alerts would have fired without triggering any actual responses or mitigations. It's available for rules using Query Language 2.0. Rules with protected logic or scheduled intervals won't show the simulation option. Multi-instance view  lets you open multiple rules side-by-side in floating panels for comparison. You can resize panels, keep them minimised at the bottom of the screen, and copy details without losing your place in the main rule list. Example: ----------------------------------------------------------------------------------------------------------- Quick Reference ------------------------------------------------------Dean-------------------------------------------------- Why This Feature Is a Big Deal Here's my honest take on this — and the reason I wanted to write about it. Most security teams have at least a few people who are great at responding to incidents but don't have the time or background to sit down and write detection logic from scratch . Custom rules in any platform require you to understand the query language , know what telemetry fields to look for, understand what a "normal" baseline looks like, and then figure out how to express a threat pattern in code. That's a lot to ask. What SentinelOne has done with the Library is essentially say — we'll do that part for you. Their research team is tracking emerging threats full time. When a new attack pattern shows up in the wild, they can push a rule to your environment automatically. You don't have to read the threat intel report, understand the technique, write the query, test it, and deploy it. It's already there. For smaller teams, for analysts who are more blue team than threat hunter, and for organisations that want solid detection coverage without hiring a dedicated detection engineer — this is genuinely useful. The Emerging Threat category especially. The whole point is that SentinelOne's researchers are watching the threat landscape so you don't have to react from scratch every time something new hits. This is the kind of feature that makes a real difference — not just on paper, but on a Tuesday afternoon when something new is spreading and you already have coverage before you've even heard about it. ------------------------------------------------------Dean--------------------------------------------------

Dropbox presents significant challenges  for forensic investigations due to encrypted databases, limited endpoint logs, and obfuscated external IP s . However, with the right approach, investigators can extract valuable metadata, user activity records, and external sharing reports . 🚀 Key Topics Covered: ✅ Extracting Dropbox metadata from local databases ✅ Using SQLECmd to automate SQLite analysis ✅ Tracking user actions via cloud activity logs ✅ Investigating file sharing and external access -------------------------------------------------------------------------------------------------------- 1️⃣ Dropbox Local Artifacts: Databases & Metadata Files 🔍 Where Does Dropbox Store Metadata Locally? File/Database Location Purpose info.json %AppData%\Local\Dropbox\ Dropbox configuration & sync folder location .dropbox.cache %UserProfile%\Dropbox\ Cached & staged file versions aggregation.dbx %AppData%\Local\Dropbox\instance<#> Recent file updates (JSON format) home.db %AppData%\Local\Dropbox\instance<#> Tracks Dropbox file changes (Server File Journal) sync_history.db %AppData%\Local\Dropbox\instance<#> Upload/download activity nucleus.sqlite3 %AppData%\Local\Dropbox\instance<#>\sync List of local & cloud-only files 📌 Forensic Use: ✅ Identify Dropbox folder locations & linked accounts ✅ Recover deleted/staged files from .dropbox.cache ✅ Reconstruct file modification history using home.db -------------------------------------------------------------------------------------------------------- 2️⃣ Automating Dropbox Analysis with SQLECmd 🔍 What is SQLECmd? SQLECmd  is an open-source forensic tool created by Eric Zimmerman  to automate SQLite database parsing . It utilizes map files  to identify Dropbox, Google Drive, and other forensic databases , automatically extracting file activity, timestamps, and metadata . What I did? Used gkape to extract all dropbox related files: 📍 Example: Running SQLECmd on Dropbox Data SQLECmd.exe -d C:\Users\Akash's\Incident response Dropbox --csv . 📌 How It Works: 🔹 -d : Specifies the directory to scan (Dropbox data folder) 🔹 --csv . : Saves results as CSV files in the current directory 📌 Forensic Use: ✅ Quickly extract metadata from Dropbox SQLite databases ✅ Identify synced, modified, and deleted files ✅ Analyze file movement within Dropbox folders -------------------------------------------------------------------------------------------------------- 1️⃣ Dropbox Logging: Free vs. Business Tiers 🔍 Comparing Activity Logs Across Dropbox Tiers Feature Basic (Free) Dropbox Business File Add/Edit/Delete Logs ❌ No logs ✅ Yes File Download & Upload Logs ❌ No logs ✅ Yes User Login & Session History ✅ Limited ✅ Full IP & Geolocation External File Sharing Reports ❌ No ✅ Yes Export Logs to CSV ❌ No ✅ Yes API Access for Logs ❌ No ✅ Yes 📌 Forensic Use: ✅ Track file modifications & deletion history ✅ Identify suspicious logins based on IP & location ✅ Monitor shared links for data exfiltration -------------------------------------------------------------------------------------------------------- 2️⃣ Accessing Dropbox Logs via the Admin Console 🔍 Steps to Retrieve Logs: 1️⃣ Log in  to the Dropbox Admin Console 2️⃣ Navigate to Reports > Activity Logs 3️⃣ Use Filters  to narrow results by user, file, folder, or event type 4️⃣ Click "Create Report"  to export logs in CSV format 📌 Forensic Use: ✅ Track who accessed or modified sensitive files ✅ Identify suspicious external IP addresses ✅ Monitor deleted files & restoration attempts -------------------------------------------------------------------------------------------------------- 3️⃣ Investigating IP Addresses & Geolocation Data 🔍 Analyzing IP Logs for Unauthorized Access Dropbox logs user IP addresses and device locations , which can help track unauthorized logins . ⚠ Limitations:  Dropbox obfuscates some external IP addresses , making it difficult to identify non-employee access . 4️⃣ Tracking External File Sharing & Anonymous Links 🔍 Dropbox Business "External Sharing" Report Dropbox tracks files shared outside the organization , but free users lack visibility into external recipients . 5️⃣ Advanced Filtering for Dropbox Logs 🔍 Filtering Logs for Specific Investigations Dropbox allows filtering logs  by various criteria, improving forensic analysis.  Key Filters for Investigation Filter Use Case Date Range Identify activity before & after an incident User Track a specific employee's Dropbox usage File/Folder Name Find modifications to critical documents Event Type Focus on file downloads, sharing, or deletions ------------------------------------------------------------------------------------------------------------- Before leaving, I waana update that in forensics, not everything is a piece of cake—there are limitations. Same for Dropbox lets talk about limitation Understanding Dropbox Event Logging All Dropbox users, regardless of their plan, have access to basic event logging  through the "Events"  section. However, users with Business or Advanced Business  plans have access to more extensive logging , which is particularly valuable in forensic investigations. What Does Dropbox Log? Administrators of Advanced Business  plans can track detailed user activity , including: ✔ File-level events  – Adding, downloading, editing, moving, renaming, and deleting files. ✔ Sharing actions  – Shared folder creation, shared link creation, Paper doc sharing, and permission changes. ✔ Access tracking  – Internal and external interactions with shared files and folders. These logs can be exported in CSV format , allowing investigators to filter data more effectively and analyze additional fields, such as IP addresses . Logs can be retained for years , making them a valuable resource for forensic analysis. However, new event entries may take up to 24 hours  to appear. Limitations and Blind Spots in Dropbox Logging While Dropbox's cloud logging is valuable, it is important to recognize its limitations : 🔹 Limited endpoint visibility  – Actions performed on locally stored Dropbox files may not be logged . For example, if a user copies a file from the Dropbox folder to their desktop or an external USB device, Dropbox may not  record this activi ty. 🔹 Synchronization tracking challenges  – While Dropbox logs when an unauthorized devic e connects and authenticates, it does not always track what files were synchronized  to that device. 🔹 Difficulty reconstructing deleted files  – Dropbox logs make it challenging to determine what files were once in a folder  after they are deleted. However, Dropbox's versioning feature  can sometimes help retrieve previous versions of a file. Due to these blind spots, forensic investigators should not rely solely on cloud logs . Instead, combining cloud logs with endpoint forensic analysis   (such as examining sync databases and local metadata) provides a more complete picture. Best Practices for Dropbox Forensics Since breaches and data theft are inevitable , proactive measures are necessary: ✔ Test forensic scenarios  – Simulating real-world incidents can help determine the exact scope of logging available in your environment. ✔ Export and analyze logs regularly  – Using CSV exports allows deeper filtering and historical tracking. ✔ Correlate with endpoint forensics  – Combining Dropbox logs with local forensic evidence  (if available) can help bridge information gaps. While Dropbox logging isn't perfect , it is still a crucial tool  for digital investigations . By understanding its capabilities and limitations, forensic analysts can make informed decisions  when investigating incidents involving Dropbox. ------------------------------------------------------------------------------------------------------- Conclusion Dropbox forensics is a crucial aspect of modern investigations, as cloud storage plays a key role in how users store, access, and share files. By analyzing local sync folders, logs, SQLite databases, and API activity , forensic analysts can reconstruct file movements, modifications, deletions, and access history  with precision . As cloud storage becomes an integral part of personal and corporate data management, the ability to track and analyze Dropbox activity  is essential for digital forensics, cybersecurity, and incident response . Staying updated on Dropbox forensic techniques  ensures that investigators can effectively follow digital trails and uncover critical evidence. 🚀 Keep exploring, stay curious, and refine your forensic skills—because digital evidence is everywhere!  🔍 🎯 Next Up: Box Forensics – Investigating Cloud Storage Security  🚀 Complete Series Below: https://www.cyberengage.org/courses-1/mastering-cloud-storage-forensics%3A-google-drive%2C-onedrive%2C-dropbox-%26-box-investigation-techniques

Microsoft OneDrive  is the most widely used cloud storage service, thanks to its default integration in Windows  and its enterprise adoption via Microsoft 365 . Understanding OneDrive forensic artifacts  is crucial for investigations involving data exfiltration, insider threats, or deleted cloud files . We will cover: ✅ How to locate and analyze OneDrive data on a Windows system ✅ Key forensic artifacts, including logs, databases, and registry entries ✅ How to determine OneDrive activity, authentication, and file synchronization history ✅ How OneDrive’s new sync model affects forensic investigations ✅ Tracking cloud-only files & deleted data ✅ Using OneDrive’s forensic artifacts to recover missing evidence ---------------------------------------------------------------------------------------------------------- 1️⃣ Locating OneDrive Files on a Windows System By default, synced OneDrive files are stored in: %UserProfile%\OneDrive 💡 Important: If a user changes the default storage location , the original OneDrive folder remains empty . The true OneDrive folder location  can be found in the Windows registry . Registry Key to Identify OneDrive Folder Location NTUSER\Software\Microsoft\OneDrive\Accounts\Personal This key contains: UserFolder  → The actual OneDrive sync folder  location cid/UserCid  → A unique Microsoft Cloud ID UserEmail  → The email used for the Microsoft account LastSignInTime  → Last authentication timestamp (Unix epoch format) 💡 Why This Matters: If OneDrive is enabled , this registry key must exist . Investigators can track user activity  even if OneDrive files have been moved or deleted. ---------------------------------------------------------------------------------------------------------- 2️⃣ Analyzing OneDrive File Metadata & Sync Database OneDrive stores metadata and sync information  in: %UserProfile%\AppData\Local\Microsoft\OneDrive\settings This folder contains key artifacts, including: 📌 SyncEngineDatabase.db (Main OneDrive Database) Tracks both local and cloud-only files Lists file names, folder structure, and metadata Provides timestamps for file sync operations 💡 Why This Matters: Even cloud-only files  (not only stored locally) are recorded here . Investigators can track deleted or moved files  that no longer exist on the device. ---------------------------------------------------------------------------------------------------------- 3️⃣ OneDrive Logs: Tracking Uploads, Downloads, & File Changes OneDrive keeps detailed logs  of file sync activities  in: %UserProfile%\AppData\Local\Microsoft\OneDrive\logs These logs store up to 30 days  of data and record: ✅ File uploads & downloads ✅ File renames & deletions ✅ Shared file access events 💡 Forensic Insight: Log files can reveal file activity , even if the user deleted local copies . Timestamps  in .odl logs can correlate file transfers   with other system activity. ---------------------------------------------------------------------------------------------------------- 4️⃣ OneDrive for Business: Additional Registry Artifacts Users with OneDrive for Business (Microsoft 365)  will have a separate registry key: NTUSER\Software\Microsoft\OneDrive\Accounts\Business1 This key includes: UserFolder : Location of root of OneDrive local file storage UserEmail : Email tied to Microsoft cloud account LastSignInTime : Date and time of last authentication (Unix epoch time) ClientFirstSignInTimestamp : Time of first authentication of the account (Unix epoch time) SPOResourceID : SharePoint URL for OneDrive instance 💡 Why This Matters: Business OneDrive accounts store work-related data —a key forensic focus. The SPOResourceID  can link OneDrive for Business files  to a SharePoint instance . ---------------------------------------------------------------------------------------------------------- 5️⃣ Investigating Shared Files & Synced Data from Other Users OneDrive supports file sharing and folder synchronization across multiple accounts . Shared folders are tracked under: NTUSER\Software\Microsoft\OneDrive\Accounts\Personal\Tenants NTUSER\Software\Microsoft\OneDrive\Accounts\Business1\Tenants This key logs shared folders synced to OneDrive . It tracks files shared via Microsoft Teams & SharePoint . 💡 Forensic Insight: Shared folders may not be stored in the default OneDrive folder . Investigators should check all Tenant folders  to avoid missing critical evidence . ---------------------------------------------------------------------------------------------------------- 6️⃣ SyncEngines Key: Advanced OneDrive Tracking A final high-value artifact  for OneDrive investigations is: NTUSER\Software\SyncEngines\Providers\OneDrive It contains: MountPoint  → Local file storage location (useful for tracking shared folders) UrlNamespace  → Specifies whether the folder belongs to OneDrive, SharePoint, or Teams LastModifiedTime  → The last time the folder was updated 💡 Why This Matters: Identifies all folders being synced , even if they are not in the default OneDrive location . Correlates data across Microsoft cloud services  (OneDrive, Teams, SharePoint) . ---------------------------------------------------------------------------------------------------------- 7️⃣ Tracking OneDrive Web Access (Cloud-Only Activity) If a user accessed OneDrive through a web browser  (instead of the local app), artifacts may appear in: Browser History  (Edge, Chrome, Firefox) Windows Event Logs Cloud Access Logs (if available from Microsoft 365) OneDrive web access URLs look like this: https[:]/onedrive.live.com/?cid=310ff47e40c97767&id=310ff47e40c97767!145750 💡 Forensic Insight: The cid value  in the URL matches the UserCid in registry keys —helpful for tracking multiple accounts . The res id parameter  refers to specific files or folders  accessed via the web client. ---------------------------------------------------------------------------------------------------------- 🛑 Key Challenges in OneDrive Forensics 🚨 1. Cloud-Only Files May Not Be Stored Locally Files accessed via " Files on Demand"  may never be fully downloaded . Investigators must analyze metadata & sync logs  to track cloud-only data. 🚨 2. Remote Deletions Can Hide Evidence Files deleted in OneDrive sync across all devices . Investigators may need Volume Shadow Copies or Microsoft 365 logs  to recover data. 🚨 3. Personal & Business OneDrive Accounts Can Be Mixed Users often log into both accounts  on the same system. Check registry keys  to differentiate personal vs. business data . ---------------------------------------------------------------------------------------------------------- OneDrive as a Crucial Forensic Artifact Microsoft OneDrive leaves behind substantial forensic evidence , even for files that no longer exist locally . We will explore more about OneDrive  in the next article (Advanced OneDrive Forensics: Investigating Cloud-Only Files & Synchronization) , so stay tuned! See you in the next one. Complete Series Below: https://www.cyberengage.org/courses-1/mastering-cloud-storage-forensics%3A-google-drive%2C-onedrive%2C-dropbox-%26-box-investigation-techniques --------------------------------------------Dean-------------------------------------------------

Most people have never heard of it. But when someone opened a suspicious file, deleted emails to cover their tracks, or tried to access an encrypted document they weren't supposed to — Office quietly wrote it all down. --------------------------------------------------------------------------------------------------------- Wait, What Even Is OAlerts? Okay let me start with a question. You know when you're about to close a Word document and it hasn't been saved, and that little popup appears saying "Do you want to save changes to Document1?" — that annoying box that's interrupted everyone's day a thousand times? Right. Turns out every single time that box appears, Windows writes a note about it. Name of the file. Timestamp. What the message said. Everything. That's OAlerts.evtx in a nutshell. Every time Microsoft Office shows the user a dialog box — any application, any alert — the contents of that dialog get logged in a custom Windows Event Log file called OAlerts.evtx. It's been there since Office 2010 and most investigators completely miss it. 📁 Location: C:\Windows\System32\winevt\Logs\OAlerts.evtx You can open it directly in Windows Event Viewer — just search "event viewer" in the Start menu, navigate to Applications and Services Logs, and find OAlerts. Every single event in this log has the same Event ID: 300 . That's it. Just one ID. The application name and the message content sit inside the event description, which is the part worth reading. --------------------------------------------------------------------------------------------------------- Why Does This Matter Forensically? Here's the thing — most forensic artifacts tell you what files exist. Shellbags show you folders that were browsed. LNK files show you files that were opened. Jump Lists show recently accessed documents. These are all useful. But These artifacts do not  reliably show content changes . That gap is a real problem when you're trying to prove someone tampered with data. OAlerts fills that gap in a really specific way. Because the "unsaved changes" dialog only appears when there are unsaved changes, seeing that event in the log is evidence that the file was opened and modified. The name of the file is recorded verbatim in the log entry. That's far more than most artifacts give you. One more thing worth calling out: it doesn't matter where the file lives. Local drive, USB stick, network share — if Office shows a dialog about it, OAlerts records it. That means you can catch file activity on removable media that other artifacts might miss entirely. --------------------------------------------------------------------------------------------------------- The Scenarios You'll Actually Encounter Let's go through the real situations where OAlerts becomes useful. These aren't edge cases — I've ordered them by how often they come up in investigations. --------------------------------------------------------------------------------------------------------- Real Examples — Let's Look at Actual Events This is where it gets interesting. Let me show you three events you might encounter — the kind that show up in real investigations. Notice how the log records the dialog message word for word. Whatever Windows showed the user on screen is exactly what ends up in the log. Example 1 — Someone opened something they shouldn't have This one is a classic. Someone on the system had a document called " handles.xlsx " open in Word. They closed it without saving. Word showed the standard "save changes?" dialog — and OAlerts faithfully recorded the entire thing, including the filename. Now we know this document existed on this machine, was opened in Word, was modified (because unsaved changes existed), and the user interacted with it at this exact timestamp. Example 2 — Someone emptied their email trash Outlook is one of the most forensically opaque applications in the Office suite — there aren't many artifacts that track what a user actually did inside it. OAlerts is one of the few exceptions. When a user right-clicks their Deleted Items folder and chooses "Empty Folder", Outlook asks for confirmation first. That confirmation dialog — and the fact it was triggered — goes straight into OAlerts. Worth noting: OAlerts doesn't record which user account triggered the event. The log entry itself doesn't have user identity. But you can cross-reference it with Windows Security Event Log logon events (4624/4648) around the same timestamp to work out who was active on the machine at that moment. Example 3 — Wrong password on an encrypted document This one is particularly interesting for insider threat investigations. When someone tries to open a password-protected Office document and enters the wrong password, Word shows an error dialog. And yes — OAlerts records that too. You'll see the filename and a note that the password was incorrect. This could mean the document was encrypted and the person trying to open it wasn't supposed to have access. --------------------------------------------------------------------------------------------------------- At a Glance — Common Events You'll See Here's a quick reference of the most common scenarios you'll encounter in this log, what they look like in the event description, and what each one tells you forensically. -------------------------------------------------------------------------------------------------------- Connecting OAlerts to the Bigger Picture OAlerts doesn't tell you the whole story on its own — but it connects really well with other artifacts. Here's how I think about combining it with other evidence sources. Think of it this way: OAlerts tells you what happened (a specific file was modified, emails were deleted, a bad password was entered). The Security Event Log tells you who did i t (which account was logged in). LNK files and Jump Lists tell you where the file lived (the full path on disk). Together they build a timeline that's hard to dispute. --------------------------------------------------------------------------------------------------------- How to Collect It During an Investigation Collecting OAlerts.evtx is the same as collecting any other Windows event log. The file lives at C:\Windows\System32\winevt\Logs\OAlerts.evtx. On a live system you can copy it with administrative rights. On a forensic image you just navigate to that path within the image and extract it. For parsing, my Favorite options. Eric Zimmerman's EvtxECmd.exe will parse it cleanly into CSV and you can open it in Timeline Explorer — which means OAlerts events slot right into the same workflow as your other SRUM and event log data. Log Parser and PowerShell's Get-WinEvent both work too. --------------------------------------------------------------------------------------------------------- Quick Reference --------------------------------------------Dean----------------------------------------------------

Intro In previous articles we covered ESEDatabaseView for raw database exploration, and SrumECmd for fast command-line parsing. https://www.cyberengage.org/post/how-to-use-srumecmd-to-parse-and-analyze-srudb-dat-files https://www.cyberengage.org/post/examining-srum-with-esedatabaseview This article introduces a fourth approach: SRUM-DUMP v3. Version 3 is a significant redesign from 2.6. If you waana learn or see how version 2.6 works Check out below article https://www.cyberengage.org/post/making-sense-of-srum-data-with-srum_dump-tool The old single-dialog interface is gone. In its place is a three-step GUI wizard, a JSON configuration system, a "dirty words" feature for keyword highlighting, built-in Volume Shadow Copy support for locked live-system files, and full command-line support for automated workflows. If you used the old version and haven't upgraded, the new interface looks entirely different. ------------------------------------------------------------------------------------------------------- Section 1 — What Changed from 2.6 to 3.2 The 2.6 interface was a single dialog — you selected files, clicked OK, and got a spreadsheet. Fast and simple, but no opportunity to guide the analysis. Version 3 rebuilds the workflow around a three-step process that adds two important new concepts: the configuration file and dirty words. The configuration file (srum_dump_config.json) is generated after the tool's first pass through the database. It lists every process path, user SID, and network interface found — before the full analysis runs. This lets you see exactly what's in the database before committing to the full extraction. You can rename entries to be more readable, and flag specific strings for highlighting. The dirty words feature lets you define keywords that will be colour-coded in the output. Any string matching cmd.exe, powershell.exe, a specific malware filename, a suspect username, or a suspicious network name will be highlighted in the colour you specify. This means when you open the output spreadsheet, your points of interest are already visually flagged — you don't have to manually scan thousands of rows. The biggest operational change is locked file handling. SRUM-DUMP 3 can extract SRUDB.dat from a live system through Volume Shadow Copies without requiring manual esentutl repair first . And if the database is corrupt, there are now two ESE parsing engines to try — pyesedb and dissect — and switching between them is a single flag change. ------------------------------------------------------------------------------------------------------- Section 2 — The Three-Step GUI Wizard Download the prebuilt executable from the Releases page at github.com/MarkBaggett/srum-dump. No installation is required — just run the executable. The interface opens on a three-step wizard. Step 1 is file selection. You choose an empty output directory first, then select SRUDB.dat. On a live system you'll find it at C:\Windows\System32\sru\srudb.dat and administrative privileges are required. If those files are locked by the OS — which is normal on a running system — SRUM-DUMP will extract them through Volume Shadow Copies automatically. You don't need to manually copy or repair the database first. You can also optionally provide the SOFTWARE registry hive, which enables automatic resolution of interface LUIDs to human-readable SSID network names. Step 2 is configuration review. After the initial analysis pass, the tool generates srum_dump_config.json and opens it for editing. This is where SRUM-DUMP v3 fundamentally differs from version 2.6. Before the full extraction runs, you can see every process, user, and network in the database. You can rename entries to make them more readable, and you can define dirty words to highlight during analysis. Step 3 is execution. Click Confirm, then Continue. A progress dialog appears and the Close button is disabled until the analysis completes. The output — an Excel spreadsheet with one tab per SRUM table — is written to your output directory. Open it and your dirty word matches are already highlighted in the colours you defined. ------------------------------------------------------------------------------------------------------- Section 3 — The Configuration File and dirty_words The configuration file is the most powerful new feature in version 3. It's generated automatically after the first analysis pass and saved as srum_dump_config.json in your output directory. Think of it as a manifest — before the full extraction runs SRUM-DUMP has already identified every process path, user SID, and network interface in the database and listed them here. The dirty_words section is where you define keywords to colour-highlight in the output. Any string you add — a process name, a username, a network name — will be changed to the specified colour wherever it appears in the spreadsheet. "dirty_words": { "cmd.exe": "highlight-red", "powershell.exe": "highlight-yellow", "suspicious_process": "general-red-bold" } Available colours include highlight-red, highlight-yellow, and general-red-bold. Note that dirty words do have a processing cost — adding many of them will increase analysis time . Use them for your top suspects rather than broad filters. The strings section is also editable. Each AppID and UserID in the database is listed with its resolved string. If you know the username behind a SID, or want to flag a network with a label like "SuspectWifi", you can modify the strings here before the final run. String modifications don't carry the same performance cost as dirty words, so use them freely. A practical workflow: after the initial pass generates the config file, scan the process list for anything unusual before adding dirty words. If you're looking for a specific piece of malware, add its filename. If you know a suspect username, add that. If a particular network is under scrutiny, add that too. Then run the full analysis — the output will have your suspects pre-highlighted, saving significant manual review time on large datasets. ------------------------------------------------------------------------------------------------------- Section 4 — Command-Line Usage SRUM-DUMP 3 includes full command-line support, making it suitable for scripted workflows, automated collection pipelines, and integration with tools like KAPE. Every option available in the GUI is also available as a CLI flag. The --NO_CONFIRM flag (-q) skips the configuration review dialog, which is what you want for automated processing. The --ESE_ENGINE flag is particularly useful when dealing with corrupt databases — if the default pyesedb engine fails or produces incomplete output, switching to dissect sometimes recovers data the other engine cannot. The --OUTPUT_FORMAT flag lets you choose CSV instead of XLS, which is useful when piping output into other tools. All flags use double-dash for long form and single-dash for short form. The input file flag is --SRUM_INFILE or -i. Output directory is --OUT_DIR or -o. ------------------------------------------------------------------------------------------------------- Section 5 — Reading the Output: Three Key Tables The Excel spreadsheet output contains one tab per SRUM table. The three most important for investigation are Network Connectivity Usage, Network Data Usage, and Application Resource Usage. Network Connectivity Usage The Network Connectivity Usage table documents when the system connected to each network, how long each connection lasted, and which wireless interface was used. This is one of the best tables for establishing the physical location of a computer during a given time window. Each row represents a SRUM entry. The timestamp column shows when the SRUM entry was recorded — typically at each hour boundary. The network interface column tells you the protocol used — Wireless 802.11 for WiFi. The network name column shows the resolved SSID if a SOFTWARE hive was provided. The connected time column shows how long that network had been connected at the time of the SRUM entry. The connect start time column shows when the connection originally began. One important interpretation note: you will frequently see the same network appearing across two SRUM entries with the same ConnectStartTime. This is not two separate connections — it's a single connection spanning across two recording periods. When you see this pattern, take the ConnectStartTime as the beginning of the connection and the longest ConnectedTime value as the total duration. Adding the two time values together would overstate the connection length. Additionally, if two consecutive SRUM entries are more than 60 minutes apart (plus or minus 10 minutes), a system shutdown or hibernate almost certainly occurred during that gap. SRUM entries are typically recorded every hour, so a gap larger than that is meaningful. ------------------------------------------------------------------------------------------------------- Network Data Usage The Network Data Usage table records which specific applications were using each network during each SRUM recording period. Where the Connectivity table tells you which networks the system was connected to and when, this table tells you what was happening on those networks at the application level. Each row shows an application path, the user SID responsible for running it, the network it communicated on, and the total bytes sent and received since the last SRUM entry. The application path is the full executable path, already resolved from AppID by the tool. This table is particularly useful for identifying unusual data volumes. If you see a process transferring large amounts of data on a network that wouldn't normally have that traffic, or a process you wouldn't expect to be making network calls at all, those are your investigative leads. Filter by the AppId column to isolate specific applications across all recording periods and see their full network activity history. One precision note: the byte counts represent raw data at the protocol level and include protocol overhead and compressed data. They may not match exactly to a file size you're trying to account for, but they are reliable for identifying relative volumes and patterns. ------------------------------------------------------------------------------------------------------- Application Resource Usage The Application Resource Usage table is the broadest of the three — it records all applications active during each SRUM recording period, not just those using the network. This makes it the primary table for evidence of application execution. Each row records the full executable path, the user SID, the volume and directory, CPU cycle time for foreground and background processing, memory working set size, and foreground and background bytes read and written to disk. The timestamp represents the end of the 60-minute window during which that application was active. For a forensic analyst, the most immediately useful fields are the application path, the user SID, and the timestamp. Together these establish what ran, under whose account, and during what hour. Cross-referencing with the Network Data Usage table for the same time window shows whether that application was also making network connections. The CPU and disk I/O fields require more research before they can be relied upon for definitive conclusions — the forensic community is still developing best practices for interpreting them. The execution evidence they provide, however, is solid. ------------------------------------------------------------------------------------------------------- Conclusion + Quick Reference SRUM-DUMP 3 takes what was already a capable forensic tool and adds the investigative workflow it was always missing. The configuration file gives you a preview of what's in the database before you commit to the full extraction. Dirty words mean your suspects are flagged before you open the spreadsheet. Volume Shadow Copy support removes the manual locked-file problem from the process entirely. The three key tables remain the same as in version 2.6 — Network Connectivity Usage for location and connection timeline, Network Data Usage for application-level bandwidth and exfiltration indicators, and Application Resource Usage for comprehensive execution evidence. SRUM-DUMP is available free. It is the fourth tool in this series covering SRUM analysis, alongside ESEDatabaseView, SrumECmd, and the broader raw database exploration approaches documented in earlier articles. ----------------------------------------------------Dean---------------------------------------------------- Check Out series Link below: https://www.cyberengage.org/courses-1/srum%3A-unveiling-insights-for-digital-investigations

Intro The Windows operating system maintains various logs and databases for performance monitoring, user activity tracking, and resource usage statistics. One such database is the SRUDB.dat file — System Resource Usage Databas e. For forensic analysis, performance troubleshooting, and security auditing, parsing and analyzing this database can provide valuable insights. Eric Zimmerman's tool SrumECmd (currently v0.5.0.1) is designed to facilitate extraction and analysis of data from SRUDB.dat. It parses the database, optionally cross-references the SOFTWARE registry hive to resolve network names, and outputs clean CSV files ready for analysis in Timeline Explorer. One underappreciated forensic advantage: SrumECmd can surface evidence of applications that no longer exist on disk. Because SRUM records execution data independently of whether the executable is still present, deleted malware or removed tools still leave traces in the database. If it ran, SRUM recorded it. Section 1 — Prerequisites Before you start, ensure you have the following: SrumECmd — Download from Eric Zimmerman's official toolkit at ericzimmerman.github.io. Use the .NET 6 or Net 9version. Extract to a convenient location such as C:\Tools\ZimmermanTools\. No installation required. SRUDB.dat — Located at C:\Windows\System32\sru\SRUDB.dat. On a live running system this file is locked by Windows — you cannot copy it with File Explorer. Use a forensic imager or live triage tool. Always work on copies, never originals. SOFTWARE hive — Located at C:\Windows\System32\config\SOFTWARE. This is optional but strongly recommended. Without it, L2ProfileId values in the network tables remain as raw numbers and network names won't be resolved. Collect it at the same time as SRUDB.dat. KAPE (Optional) — Available free for non-commercial use from Kroll at kroll.com. Automates the entire collection and parsing workflow and handles locked file access on live systems. Section 2 — Running SrumECmd: Verified Command Syntax There are two primary modes — file mode (-f) and directory mode (-d) . Use -f when you know the exact path to your copied SRUDB.dat. Use -d when pointing at a folder, which is the mode used with KAPE — it recursively scans the directory and locates both SRUDB.dat and the SOFTWARE hive automatically. You only need one or the other, not both. In either case, --csv is required and must be a full path in double quotes. The -r flag for the SOFTWARE hive is optional but strongly recommended for any network investigation — without it, you'll have unresolved numeric network IDs throughout your output. Open the command prompt as Administrator before running. Both modes are shown below with exact syntax taken from the official README. Section 3 — Dirty Database: Official Repair Process When you run SrumECmd against a SRUDB.dat copied from a live machine, you will almost certainly encounter this error: "Error processing file! Message: Object reference not set to an instance of an object." This means the database is dirty — it wasn't cleanly shut down before you copied it. This is the norm in incident response, not an exception. The fix is a two-command esentutl repair process. Section 4 — Output Files and Data Retention After a successful run, navigate to your output directory . You'll find several CSV files — one per SRUM table parsed . Open them in Timeline Explorer for filtering, date ranges, and column pivoting. Data retention is not uniform across tables. Application and process data is kept for approximately 30 days. Network usage data is retained for approximately 60 days. This difference matters for your collection timeline — network evidence may extend twice as far back as application evidence, so don't assume they share the same window. The application resource usage CSV is particularly valuable for malware hunting. SRUM records application execution independently of whether the file still exists on disk. Deleted executables still appear with their full path, the user SID that ran them, and execution timestamps. This is frequently the only remaining evidence of tools that were run and then cleaned up. Section 5 — KAPE Integration (Corrected Syntax) The correct KAPE syntax uses two separate flags: --tdest for where collected raw files are saved, and --mdest for where parsed module output is written. .\kape.exe --tsource C: --tdest "F:\Output for testing" --target SRUM --gui Additionally, there is a second KAPE module worth knowing about: PowerShell_SrumECmd_SRUM-RepairAndParse. This module uses a PowerShell script (SRUM-Repair.ps1) to automatically handle the dirty state repair and then run SrumECmd in a single step. This is particularly useful when you know your source database is likely dirty and you want to automate the entire collect → repair → parse workflow. Section 6 — Correlating with Other Windows Artifacts SrumECmd CSV output becomes significantly more valuable when you correlate it against other Windows artifacts in Timeline Explorer. No single artifact tells the whole stor y — building a reliable timeline means cross-referencing multiple sources. Prefetch is the most natural first check. If AppResourceUseInfo shows an executable running at a specific time, Prefetch should confirm the same execution. Discrepancies between the two are worth investigating — if SRUM has it but Prefetch doesn't, the executable may have been run in a way that bypasses Prefetch tracking. UserAssist in the registry records interactive application launches via Explorer . If SRUM shows execution but UserAssist has no record, the application was likely launched programmatically rather than by the user clicking on it directly — relevant for distinguishing manual from automated actions. Event Logs (specifically logon events 4624 and 4634) let you confirm which user accounts were active during time windows that show up in SRUM. Combining these with the UserId field in SRUM output builds a strong attribution chain. Browser history and web artifacts explain the destination of high-volume network transfers recorded in SRUM network tables. If SRUM shows a browser process sending 800MB outbound, browser history tells you where it went. Conclusion + Quick Reference Eric Zimmerman's SrumECmd is a powerful tool for parsing and analyzing SRUDB.dat files, providing detailed insights into system resource usage and user activity. Whether you use it standalone or integrate it with KAPE for automated workflows, SrumECmd can significantly enhance your forensic and troubleshooting capabilities. --------------------------------------------Dean--------------------------------------------------

Updated on 25 Feb, 2026 Intro In this article on SRUM we covered the basics — what the database is, why it matters for digital forensics, and a few real-world cases where it changed everything. But if you're doing serious incident response or forensic analysis, the basics only take you so far. The deeper you go into SRUM, the more useful it becomes — and the more edge cases you run into. What does SRUM actually track? Where does the data live before it's written to the database? What changed between Windows 8 and Windows 11? Why do all your SRUM entries have the same timestamp — and what does that actually mean? And what do you do when the database file comes back corrupted? This article answers all of those questions. Let's get into the technical side of SRUM. System Resource Usage Monitor (SRUM), a powerful tool that has become a game-changer in digital forensic investigations. Section 1 — What SRUM Actually Records (All Four Categories) SRUM doesn't just log one thing — it maintains four distinct categories of data, each tracked separately and each telling a different part of the story. Understanding what lives in each category is key to knowing which one to focus on during an investigation. The most valuable for most investigations are the three big ones : what applications ran (and who ran them), what happened on the network, and how the system connected to networks . Energy usage rounds things out and is often overlooked, but it has its own unique value — especially when you need to prove whether a device was powered on and active during a specific window of time. Section 1.1 - Accessing and Managing SRUM Data Users can get a glimpse of SRUM data through the Task Manager's "App history" and "Details" tabs, showcasing performance statistics and approximately 30 days of historical data. However, a mere click on "Delete usage history" doesn't erase SRUM data immediately, requiring further investigation into data retention and purging policies. Section 2 — Where the Data Lives and When It Gets Written This is one of the most important technical details to get right — and one that trips up a lot of analysts on their first few SRUM investigations. SRUM doesn't write data instantly. It batches everything and flushes it out on a schedule . In Windows 8 and 8.1 , SRUM performance data was first staged in the Windows registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, and then transferred into the SRUDB.dat database approximately once per hour , or when the system properly rebooted or shut down . Think of the registry as the short-term buffer. Windows 10 and 11  changed this. Data is still written to SRUDB.dat every 60 minutes, but the registry staging step is largely gone. The SOFTWARE registry is now only referenced to look up the names of the SRUM database tables — the actual pre-write buffer doesn't live there anymore. There's also an important quirk discovered in Windows 10 Version 2004 and carried through Windows 11: SRUDB.dat is not always written on shutdown. Testing showed that if a system is shut down twice within 10-minute intervals, data may not be flushed until the third reboot — specifically, once the system has been running for more than 60 minutes since the last SRUM entry. This matters a lot in live forensics scenarios where you're racing against a reboot. Section 3 — How Long Does SRUM Keep Data? The standard answer you'll hear is that SRUM keeps about 30 days of data — and that's largely true for most tables. But the full picture is more nuanced, and there's one major exception that's incredibly useful. For most SRUM tables, data is retained for 30 days under normal operation .  It's not uncommon to find 60 days worth of historical records though  — Windows doesn't always purge aggressively. Data beyond 60 days is typically gone. One important operational note: if a system is powered off for an extended period (weeks), when it boots back up, SRUM may immediately purge anything older than 30 days. So the clock on that older data can run out fast when a device comes back online. The exception is the Energy Usage LT table — that "LT" stands for Long-Term. This table operates on a completely different retention schedule. In Some cases, the Energy Usage LT table has contained data going back more than four years. The trade-off is that it only tracks high-level information: whether the system was running on AC or DC power, and for how long. But in the right case, four years of "was this laptop plugged in or on battery at this time" data can be surprisingly powerful. There's also one more lifeline worth knowing about: SRUM is one of the artifacts that gets captured inside Volume Shadow Copies . If shadow copies are available on the system, you can potentially pull historical versions of the SRUDB.dat database from earlier points in time — effectively extending your forensic window even further. Section 4 — Dealing With a Dirty or Corrupted SRUM Database Here's a practical reality of incident response: most of the time, systems don't get cleanly shut down before investigators get to them. Someone pulls a power cable, a system crashes, or the machine is seized while running. This means the SRUDB.dat file you're working with may be in a "dirty" state — the ESE database wasn't properly closed and the file could be partially corrupted. The good news is Windows has a built-in tool for exactly this situation: esentutl.exe . This utility handles defragmentation, recovery, integrity checking, data dumping, and repair of ESE databases. It's already on the machine — you just need to know the right commands. There are two important rules when using esentutl to repair a SRUM database. First: always run the repair on the same version of Windows as the system the dirty database came from. ESE database formats have version differences, and repairing a Windows 11 database on a Windows 10 machine (or vice versa) can make things worse. Second: always check the database header first before attempting repair — this confirms it's actually dirty before you do anything to it. If deleted records have been removed from the SRUM database, there's also a recovery path worth knowing about. A utility called EseCarve can potentially recover deleted entries from the ESE database file through carving techniques — the same general approach used for file carving during traditional forensics. Section 5 — SRUM Extensions: The Table GUIDs Explained Under the registry key  SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, there are three subkeys: Extensions, Parameters, and Telemetry. The Extensions subkeys are particularly useful for analysts because they map directly to the tables inside the SRUDB.dat database — each GUID corresponds to a specific table and tells you what kind of data to expect there. In Windows 10 (from version 1803 onwards) and Windows 11, there are nine extension subkeys. Not all of them have equal forensic value — the research community consistently finds that the three most valuable tables are the Network Connectivity Usage Monitor, the Network Data Usage Monitor, and the Application Resource Usage Provider.  These are the ones you should prioritize in an investigation. Windows 11 made only one change to the table structure: the Energy Usage Provider table gained two additional columns — "Battery Count" and "Battery Charge Limit." Neither has proven particularly useful in analysis so far, but it's worth knowing they're there. The SRUM extension subkeys have also evolved across Windows versions, particularly the Energy Estimation Provider which changed its GUID three times between Windows 10 versions 1511, 1607, and 1803. If you're analyzing systems across different Windows versions, you need to be aware that the same table may be stored under different GUIDs depending on the OS version. Section 6 — How SRUM Evolved Across Windows Versions SRUM has been in constant evolution since it first appeared in Windows 8. For forensic analysts working across multiple systems running different versions of Windows, understanding these changes is genuinely important — what you find in SRUDB.dat on a Windows 8 machine looks different from what you'll find on a Windows 11 system, and the tools and techniques need to account for that. Conclusion SRUM is one of those artifacts that rewards the analyst who takes the time to understand it properly. The basics are straightforward — but once you dig into the write timing behavior, the table structure, the version differences, and the database repair workflow, it becomes a genuinely powerful tool in your arsenal.

Intro In this article on SRUM we covered the basics — what the database is, why it matters for digital forensics, and a few real-world cases where it changed everything. But if you're doing serious incident response or forensic analysis, the basics only take you so far. The deeper you go into SRUM, the more useful it becomes — and the more edge cases you run into. What does SRUM actually track? Where does the data live before it's written to the database? What changed between Windows 8 and Windows 11? Why do all your SRUM entries have the same timestamp — and what does that actually mean? And what do you do when the database file comes back corrupted? This article answers all of those questions. Let's get into the technical side of SRUM. System Resource Usage Monitor (SRUM), a powerful tool that has become a game-changer in digital forensic investigations. Section 1 — What SRUM Actually Records (All Four Categories) SRUM doesn't just log one thing — it maintains four distinct categories of data, each tracked separately and each telling a different part of the story. Understanding what lives in each category is key to knowing which one to focus on during an investigation. The most valuable for most investigations are the three big ones : what applications ran (and who ran them), what happened on the network, and how the system connected to networks . Energy usage rounds things out and is often overlooked, but it has its own unique value — especially when you need to prove whether a device was powered on and active during a specific window of time. Section 1.1 - Accessing and Managing SRUM Data Users can get a glimpse of SRUM data through the Task Manager's "App history" and "Details" tabs, showcasing performance statistics and approximately 30 days of historical data. However, a mere click on "Delete usage history" doesn't erase SRUM data immediately, requiring further investigation into data retention and purging policies. Section 2 — Where the Data Lives and When It Gets Written This is one of the most important technical details to get right — and one that trips up a lot of analysts on their first few SRUM investigations. SRUM doesn't write data instantly. It batches everything and flushes it out on a schedule . In Windows 8 and 8.1 , SRUM performance data was first staged in the Windows registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, and then transferred into the SRUDB.dat database approximately once per hour , or when the system properly rebooted or shut down . Think of the registry as the short-term buffer. Windows 10 and 11 changed this. Data is still written to SRUDB.dat every 60 minutes, but the registry staging step is largely gone. The SOFTWARE registry is now only referenced to look up the names of the SRUM database tables — the actual pre-write buffer doesn't live there anymore. There's also an important quirk discovered in Windows 10 Version 2004 and carried through Windows 11: SRUDB.dat is not always written on shutdown. Testing showed that if a system is shut down twice within 10-minute intervals, data may not be flushed until the third reboot — specifically, once the system has been running for more than 60 minutes since the last SRUM entry. This matters a lot in live forensics scenarios where you're racing against a reboot. Section 3 — How Long Does SRUM Keep Data? The standard answer you'll hear is that SRUM keeps about 30 days of data — and that's largely true for most tables. But the full picture is more nuanced, and there's one major exception that's incredibly useful. For most SRUM tables, data is retained for 30 days under normal operation . It's not uncommon to find 60 days worth of historical records though — Windows doesn't always purge aggressively. Data beyond 60 days is typically gone. One important operational note: if a system is powered off for an extended period (weeks), when it boots back up, SRUM may immediately purge anything older than 30 days. So the clock on that older data can run out fast when a device comes back online. The exception is the Energy Usage LT table — that "LT" stands for Long-Term. This table operates on a completely different retention schedule. In Some cases, the Energy Usage LT table has contained data going back more than four years. The trade-off is that it only tracks high-level information: whether the system was running on AC or DC power, and for how long. But in the right case, four years of "was this laptop plugged in or on battery at this time" data can be surprisingly powerful. There's also one more lifeline worth knowing about: SRUM is one of the artifacts that gets captured inside Volume Shadow Copies . If shadow copies are available on the system, you can potentially pull historical versions of the SRUDB.dat database from earlier points in time — effectively extending your forensic window even further. Section 4 — Dealing With a Dirty or Corrupted SRUM Database Here's a practical reality of incident response: most of the time, systems don't get cleanly shut down before investigators get to them. Someone pulls a power cable, a system crashes, or the machine is seized while running. This means the SRUDB.dat file you're working with may be in a "dirty" state — the ESE database wasn't properly closed and the file could be partially corrupted. The good news is Windows has a built-in tool for exactly this situation: esentutl.exe . This utility handles defragmentation, recovery, integrity checking, data dumping, and repair of ESE databases. It's already on the machine — you just need to know the right commands. There are two important rules when using esentutl to repair a SRUM database. First: always run the repair on the same version of Windows as the system the dirty database came from. ESE database formats have version differences, and repairing a Windows 11 database on a Windows 10 machine (or vice versa) can make things worse. Second: always check the database header first before attempting repair — this confirms it's actually dirty before you do anything to it. If deleted records have been removed from the SRUM database, there's also a recovery path worth knowing about. A utility called EseCarve can potentially recover deleted entries from the ESE database file through carving techniques — the same general approach used for file carving during traditional forensics. Section 5 — SRUM Extensions: The Table GUIDs Explained Under the registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, there are three subkeys: Extensions, Parameters, and Telemetry. The Extensions subkeys are particularly useful for analysts because they map directly to the tables inside the SRUDB.dat database — each GUID corresponds to a specific table and tells you what kind of data to expect there. In Windows 10 (from version 1803 onwards) and Windows 11, there are nine extension subkeys. Not all of them have equal forensic value — the research community consistently finds that the three most valuable tables are the Network Connectivity Usage Monitor, the Network Data Usage Monitor, and the Application Resource Usage Provider. These are the ones you should prioritize in an investigation. Windows 11 made only one change to the table structure: the Energy Usage Provider table gained two additional columns — "Battery Count" and "Battery Charge Limit." Neither has proven particularly useful in analysis so far, but it's worth knowing they're there. The SRUM extension subkeys have also evolved across Windows versions, particularly the Energy Estimation Provider which changed its GUID three times between Windows 10 versions 1511, 1607, and 1803. If you're analyzing systems across different Windows versions, you need to be aware that the same table may be stored under different GUIDs depending on the OS version. Section 6 — How SRUM Evolved Across Windows Versions SRUM has been in constant evolution since it first appeared in Windows 8. For forensic analysts working across multiple systems running different versions of Windows, understanding these changes is genuinely important — what you find in SRUDB.dat on a Windows 8 machine looks different from what you'll find on a Windows 11 system, and the tools and techniques need to account for that. Conclusion SRUM is one of those artifacts that rewards the analyst who takes the time to understand it properly. The basics are straightforward — but once you dig into the write timing behavior, the table structure, the version differences, and the database repair workflow, it becomes a genuinely powerful tool in your arsenal. ---------------------------------------------------Dean------------------------------------------------

Updated on 26 Feb, 2026 If you waana know more about SRUM do checkout my previous articles! https://www.cyberengage.org/post/srum-the-digital-detective-in-windows Intro You've heard about SRUM. You know it tracks application usage, network activity, and energy data going back 30 days. But knowing it exists and actually getting useful evidence out of it are two different things. In this article we're going to walk through the whole process from scratch We're using ESEDatabaseView by NirSoft because it's free, doesn't require installation, and gives you direct access to every table in the raw database. It's the best tool for understanding what SRUM actually contains before you move on to automated parsers. Section 1 — The Full Workflow at a Glance Before we go step by step, here's the full picture. There are six stages to a SRUM analysis using ESEDatabaseView. Each one feeds into the next, and skipping any of them — especially the repair check — can cause problems further down the line. Section 2 — Step 1 & 2: Collect the Files and Check for Dirty State The SRUM database lives at C:\Windows\System32\sru\SRUDB.dat . On a live running system, Windows has this file locked — you can't just browse to it and copy it with File Explorer. You'll need either a forensic imaging tool or Kape, a live triage script, or a tool like SRUM-DUMP that handles the locked file access for you. You also need a second file: the SOFTWARE registry hive at C:\Windows\System32\config\SOFTWARE You'll need this later to resolve network names from the L2ProfileId values you'll find in the database. Grab both at the same time. Once you have your copies, the very first thing to do before opening ESEDatabaseView is check whether the database was closed cleanly. ESE databases can end up in a "dirty" state if the system was powered off abruptly, crashed, or was seized while running — which happens a lot in real incident response. If you try to open a dirty database in ESEDatabaseView, you'll either get an error or see incomplete, unreliable data. Check first, always. Section 3 — Step 3: Opening SRUDB.dat in ESEDatabaseView Download ESEDatabaseView from NirSoft — it's a small portable executable, no installation needed. Run it as administrator. To open the database: File → Open → navigate to your SRUDB.dat copy → click Open. The tool will load the database and show you a table browser. By default it opens to a system table called MSysObjects — this is just the database's internal index of all its own tables and you don't need to worry about it. What you do want to look at is the combo box just below the toolbar, which lists every table in the database. Click on it and you'll see all the tables available — typically 16 in a modern Windows 10 or 11 SRUDB.dat. Each table has a GUID as its name. Most of them won't mean anything at first glance, but you'll quickly learn the three or four that matter. The column headers in each table are the field names, and you can click any header to sort by that column — useful when you're trying to find entries for a specific time window or a specific application. One thing to keep in mind as a beginner: the data in some fields looks like raw numbers or index values. That's intentional — the database stores references, not human-readable values. Part of what we're going to cover is exactly how to decode those references into something meaningful. Section 4 — Step 4: Reading the Network Data Usage Table Select {973F5D5C-1D90-4944-BE8E-24B94231A174} from the table dropdown — this is the Network Data Usage Monitor, and it's usually where you start. Each row in this table represents one application's network activity during one recorded hour. The columns you'll immediately notice are things like AppID, UserId, BytesSent, BytesRecvd, InterfaceLuid, and L2ProfileId. Some of these are immediately meaningful — BytesSent and BytesRecvd are exactly what they sound like. Others need decoding. AppID is just a number — it's an index that points to another table. UserId is a numeric reference too. L2ProfileId is a number that refers to a specific Wi-Fi or network profile. InterfaceLuid encodes the type of network interface (Wi-Fi, Ethernet, or something like Point-to-Point Protocol). Don't be put off by the raw numbers. The next few steps show you exactly how to decode each one into something human-readable. Think of this table as the hub — everything else connects back to it. Section 5 — Step 5: Correlating Fields Across Tables This is the step where everything comes together. You have two things to resolve from the network table: what application AppID 3621actually is, and what network L2ProfileId 268435458 actually refers to. Here's how to do both. To decode an AppID: switch to the SruDbIdMapTable in the table dropdown . Find the row where IdIndex equals your AppID — in this case 3621. The IdBlob column in that row contains a Unicode string (UTF-16 Little Endian) with the full path to the executable. That's your application. If you see C:\Windows\SysWOW64\audiodg.exe, you now know exactly what was generating that network traffic. To decode an L2ProfileId : this one requires leaving ESEDatabaseView and opening the SOFTWARE registry hive. Open it in Registry Explorer (or regedit if you're working on a live system), navigate to SOFTWARE\Microsoft\WlanSvc\Interfaces\ find the GUID that has a Profiles subkey, and browse the profile entries until you find one whose ProfileIndex value matches your L2ProfileId. Then expand that profile → MetaData → look at the Channel Hints value. That hex value decodes to the human-readable network name — the actual Wi-Fi SSID. Once you have both pieces, go back to your original network table row and you can now read the full picture: audiodg transferred inbound and outbound on the [Network name] network at [Tim and date], under user account ID 2275. Section 6 — Step 6: Export and Build Your Timeline Once you've done your correlation work, the last step is getting the data out of ESEDatabaseView into a format you can actually work with and report from. In ESEDatabaseView, go to File → Export Current Table. You can export as a comma-delimited text file (CSV) or tab-delimited. Export the tables you've been working with — at minimum the Network Data Usage table and the SruDbIdMapTable. Then open them in Excel or your preferred spreadsheet tool. In Excel, you can do the AppID resolution yourself using VLOOKUP — put the SruDbIdMapTable on one sheet, use VLOOKUP to pull the IdBlob (executable path) into the network table using AppID as the key. Do the same for your network name resolutions. Now every row in your network table has a human-readable application name and a human-readable network name instead of raw index numbers. --------------------------------------------------------Dean--------------------------------------------