A huge thank you to my dearest friend Jeremy Jethro, who created this comprehensive script and the Detection rule in Sentinel one . Hi everyone, If you've been following the cybersecurity landscape lately, you've probably heard whispers about OpenClaw  (also known as Clawbot or Moltbot) . And if you're in IT security, you're likely dealing with requests to detect and block it right now. --------------------------------------------------------------------------------------------------------- What is OpenClaw/Clawbot? OpenClaw is an AI-powered autonomous agent that runs on employees' machines. Think of it as an AI assistant that can interact with your computer, execute commands, access files, and perform actions on behalf of users. While it might sound useful in theory, it's become a significant security concern for organizations worldwide. The agent runs as a persistent background process, often integrating with various services and APIs, and has the ability to authenticate with external platforms like Google, Slack, and Discord. From a security perspective, this creates multiple risk vectors: Unauthorized data access  - The agent can potentially access sensitive files and communications Shadow IT concerns  - Users installing it without IT approval Compliance violations  - Automated actions that bypass security controls Data exfiltration risks  - The agent's ability to send data to external services Organizations are particularly concerned because OpenClaw operates with broad permissions and can persist on systems even after users think they've removed it. --------------------------------------------------------------------------------------------------------- My SentinelOne Detection Journey As you all know, I'm a huge SentinelOne  fan. I've created a complete article series on leveraging SentinelOne for advanced threat detection - if you want to check out that series, https://www.cyberengage.org/courses-1/mastering-sentinelone%3A-a-comprehensive-guide-to-deep-visibility%2C-threat-hunting%2C-and-advanced-querying%22 Given my experience with SentinelOne, I naturally started working on custom detection rules for OpenClaw. And let me tell you, this one has been challenging. The Detection Challenge: It's Not That Simple Here's where things get complicated. We're facing some serious challenges with blocking OpenClaw for several clients. The core issue is that OpenClaw uses a node process , and this is where the limitations kick in. If we issue a quarantine command in SentinelOne, it will remove node - which could break other legitimate applications that depend on it. This isn't like blocking a standalone malicious executable using Sentinel One. This is a dependency issue that could have widespread impact on production systems. The Persistence Problem Here's the really frustrating part: Even after users uninstall OpenClaw, the claw process remains in startup and continues attempting to authenticate and run via script. I've confirmed this across multiple endpoints. Users go through the uninstall process, think they're done, and the process just keeps running in the background, trying to authenticate and execute. The script is typically located at: /opt/homebrew/bin/node /opt/homebrew/lib/node_modules/clawbot/dist/entry.js --------------------------------------------------------------------------------------------------------- Star custom rule which you can use for Detection in Sentinel one (event.type = 'Process Creation' and (((src.process.cmdline contains "clawd" || tgt.process.cmdline contains "clawd" || osSrc.process.cmdline contains "clawd") OR (src.process.cmdline contains "openclaw" || tgt.process.cmdline contains "openclaw" || osSrc.process.cmdline contains "openclaw") OR (src.process.cmdline contains "moltbot" || tgt.process.cmdline contains "moltbot" || osSrc.process.cmdline contains "moltbot"))) OR ((src.process.image.path contains ".clawdbot/" || src.process.parent.image.path contains ".clawdbot/" || task.path contains ".clawdbot/" || tgt.file.path contains ".clawdbot/" || tgt.file.oldPath contains ".clawdbot/" || tgt.process.image.path contains ".clawdbot/" || module.path contains ".clawdbot/" || osSrc.process.activeContent.path contains ".clawdbot/" || osSrc.process.image.path contains ".clawdbot/" || osSrc.process.parent.image.path contains ".clawdbot/" || src.process.activeContent.path contains ".clawdbot/" || tgt.process.activeContent.path contains ".clawdbot/")) OR (src.process.parent.publisher = "" or osSrc.process.parent.publisher "")) --------------------------------------------------------------------------------------------------------- Current Detection and Remediation Approach What We Can Do in SentinelOne I've created a custom rule to detect OpenClaw installations and processes. The good news: We can detect it . The bad news: Automated quarantine is risky . For alerts like OpenClaw.dmg, We can issue a quarantine command to remove the installer. However, for active installations where OpenClaw is already running as part of the node ecosystem, the quarantine action will: Disrupt the running process NOT fully remove it Potentially break other node-dependent applications --------------------------------------------------------------------------------------------------------- The Manual Removal Path Because of these limitations, use a script to manually remove OpenClaw from their endpoints via MDM (Mobile Device Management). Important finding:   Even if users have removed Clawdbot manually, you must ensure they: Check the launchd process  - The agent registers itself as a launch daemon Remove the plist file from launchd  - This is what makes it persistent across reboots Remove the entry/script from Homebrew  - Otherwise it will remain installed The plist files are typically found at locations like: ~/Library/LaunchAgents/bot.molt.gateway.plist ~/Library/LaunchAgents/com.openclaw.gateway.plist ~/Library/LaunchAgents/com.clawdbot.gateway.plist ~/Library/LaunchAgents/com.moltbot.gateway.plist --------------------------------------------------------------------------------------------------------- The Client Landscape For MSSP every clients want to know about OpenClaw, and a significant percentage want to block it immediately. The requests are coming in fast, and the pressure is on. I can tell its possible to block it, but as I mentioned, the way the quarantine action happens means it will disrupt the running process but not remove it cleanly. --------------------------------------------------------------------------------------------------------- The Removal Script I'm sharing the removal script developed for OpenClaw remediation. This script handles everything - killing processes, removing applications, cleaning up LaunchAgents, removing user data, and removing CLI binaries and Homebrew installations. Note:  I'm still in the testing phase with some of the SentinelOne quarantine approaches, but this script has been working reliably for manual removal. Just convert this txt file into script --------------------------------------------------------------------------------------------------------- Security Reminder If OpenClaw was connected to external services, users should manually revoke OAuth tokens at: Google : https://myaccount.google.com/permissions Slack : https://slack.com/apps/manage Discord : User Settings > Authorized Apps --------------------------------------------------------------------------------------------------------- What's Next? I'm continuing to refine the SentinelOne detection rules and exploring safer quarantine approaches that won't impact legitimate node processes. If you're dealing with OpenClaw in your environment, I'd love to hear about your approach. Stay secure --------------------------------------------------Dean------------------------------------------------------

Let’s talk about one of the most underestimated  data exfil paths in Google Workspace. Not malware. Not OAuth abuse. Not a compromised token. Just… Google Takeout . Most people think of Takeout as a harmless “download my data” feature. And to be fair, that was  the original idea. But from a security and forensics perspective, Takeout is a built-in data export mechanism  that works surprisingly well — maybe too  well. What Is Google Takeout (Really)? Google Takeout, also called “Download Your Data” , allows a user to export all  the data associated with their Google account into an archive. This includes: Gmail Google Drive Calendar Contacts Sites And many other Workspace services Originally, Takeout existed to make Google feel more transparent and user-friendly.“Your data belongs to you — take it with you.” For example: Moving from a free Gmail account to Google Workspace Leaving an organization Personal backups All valid use cases. The problem? Takeout is enabled by default. You can disable it if wanted Even for: New organizations Enterprise licenses Security-conscious environments ------------------------------------------------------------------------------------------------------------- Why Takeout Is a Risk in Enterprises Here’s where the threat model changes. In Google Workspace: Any user can export their own  data Group Owners can export entire group content , including email Data can be exported outside Google’s ecosystem That last point matters a lot. Because Takeout doesn’t just download data into Google Drive — it can push data directly to: Dropbox OneDrive Box Other third-party cloud storage providers From an investigation standpoint, that’s terrifying. Once data leaves Workspace and lands in a third-party cloud: You may have zero visibility You may have zero access You may not even know what  was exported ------------------------------------------------------------------------------------------------------------- What a Takeout Export Looks Like for a User From the user’s perspective, the process is almost boringly simple. They go to: https://takeout.google.com/ From there: They select which services they want to export Choose how the export should be packaged (single archive or multiple ZIP files) Choose how the data should be delivered Most users stick with the default: Email notification with a download link But again — exporting to external storage  is just a few clicks away. ------------------------------------------------------------------------------------------------------------- Timing Matters: Takeout Is Not Instant One thing that helps defenders (a little) is that Takeout isn’t immediate. Exports are processed in the background. The time depends on: How many services are selected How much data exists in each service Users can monitor progress in “Manage your exports” , where they’ll also see a history of previous exports. From an IR perspective, this delay gives you a narrow window: To detect To respond To disable access before completion But only if you’re looking. ------------------------------------------------------------------------------------------------------------- What Actually Gets Logged (And What Doesn’t) This is where things get subtle. Google Workspace has a dedicated Takeout Audit Log . That’s good news. The log records: Which user initiated a Takeout export When it started Which services were included The IP address used When the export finished packaging What it does not  log: Whether the user downloaded the data Whether the data was accessed after packaging Whether data was successfully imported into a third-party cloud Once you see the “export completed”  event, you should assume: The data is gone. Especially if the destination was external storage. ------------------------------------------------------------------------------------------------------------- Important Forensics Gotcha: No API Access Here’s a big one that catches teams off guard. Takeout Audit Logs are NOT available via the Google Workspace API. That means: If you rely only on API-based log collection If your SIEM pipeline pulls Workspace logs via API You will miss Takeout activity entirely . This is one of the few highly forensically relevant logs that requires: Manual Admin Console access Or native Workspace log review The IP address in this log becomes extremely valuable, because it’s often the only reliable pivot point to correlate: Login events OAuth activity Drive access Suspicious sessions ------------------------------------------------------------------------------------------------------------- Where the Data Goes After Packaging Once Takeout finishes building the archive, users can: Download it directly Access it via Google Drive Or let it be pushed to third-party storage If the archive lands in Google Drive: Access to the ZIP files is logged in Drive Audit Logs If it goes to external storage: Logging ends at “export completed” At that point, Workspace visibility stops. ------------------------------------------------------------------------------------------------------------- Customer Takeout: When Admins Export Everything Now let’s talk about the nuclear option . Google Workspace also supports Customer Takeout , which allows a Super Admin  to export all data in the organization . This includes: User data Vault data Data under legal hold Data subject to retention rules This is powerful — and dangerous. https://support.google.com/a/answer/14339894?visit_id=01769771249424-8980970382637730314&rd=1 ------------------------------------------------------------------------------------------------------------- Restrictions (And Why They Exist) Google doesn’t let just anyone do this. To perform Customer Takeout: You must be a Super Admin MFA must be enabled Workspace must be older than 30 days Organization must have less than 1000 users These restrictions exist for good reason — but if a threat actor compromises an admin account that meets these conditions, Customer Takeout becomes a single-click mass exfiltration tool . ------------------------------------------------------------------------------------------------------------- The Big Picture: Why Takeout Matters in DFIR Takeout isn’t flashy. It doesn’t trigger AV alerts. It doesn’t bypass MFA. It doesn’t exploit anything. And that’s exactly why it works. From an attacker’s perspective: It’s legitimate It’s built-in It’s trusted It’s quiet From a defender’s perspective: Logging is limited API visibility is missing Exfil can be complete before alarms go off ------------------------------------------------------------------------------------------------------------- Final Thoughts If you’re defending or investigating Google Workspace environments, Takeout needs to be part of your mental threat model. Not because it’s malicious by design — but because it doesn’t need to be . All it requires is: Access Time And a user (or admin) clicking a few buttons ------------------------------------------------Dean-------------------------------------------------------

As you guys remember, I have created a complete series on Velociraptor. If you didn't check it out, do check it out - link below. https://www.cyberengage.org/courses-1/mastering-velociraptor%3A-a-comprehensive-guide-to-incident-response-and-digital-forensics Now, why am I here again? Because I recently tried to install Velociraptor with the latest version on my laptop and ran into some issues. Well, not exactly "issues" - I'd say it's more like modifications in how things work now. ------------------------------------------------------------------------------------------------------------ What Seems to be Changed in the Latest Version? Issue #1: Client Config No Longer Auto-Generated Earlier, when you generated the server config file, the client config file used to get automatically generated too. That doesn't happen anymore! So now you need to manually generate the client config file using this command: velociraptor-v0.75.1-windows-amd64.exe --config server.config.yaml config client > client.config.yaml This is only for Windows. I'll let you know if something changes for Linux in future articles. Issue #2: Windows Service Doesn't Work Properly Now here's the bigger problem I faced. I'm not sure why, but on my laptop I could not run Velociraptor as a Windows service properly. What happened was: I installed Velociraptor as a service ✅ The service showed "RUNNING" status ✅ But when I closed the terminal, the console stopped working ❌ Browser showed "Site not reachable" ❌ I checked a lot, tried to find solutions everywhere, but didn't find any proper fix. The built-in service install command just wasn't working the way it should. So I came up with another solution that works perfectly for both server and client ! The Solution: Task Scheduler + VBScript Method Instead of fighting with Windows Services, we're going to use Task Scheduler  with VBScript . This method: ✅ Runs Velociraptor completely hidden (no terminal window) ✅ Starts automatically on boot/login ✅ Works reliably every single time ✅ Easy to set up and manage Let me show you how to set up both server and client. Part 1: Setting Up Velociraptor SERVER Step 1: Generate Server Config (if you haven't already) cd C:\Users\YourUsername\Downloads velociraptor-v0.75.1-windows-amd64.exe config generate -i If you want to see what next in first step, Check out above above article Follow the prompts to create your server.config.yaml file. Step 2: Create VBScript to Run Server Hidden Open Notepad and create a new file: notepad start-velociraptor-server-hidden.vbs Paste this code: Set WshShell = CreateObject("WScript.Shell") WshShell.Run "cmd /c cd C:\Users\\Downloads && velociraptor-v0.75.1-windows-amd64.exe --config server.config.yaml frontend", 0, False Important:  Replace C:\Users\YourUsername\Downloads with your actual path! Save and close Notepad. Step 3: Set Up Task Scheduler for Server Now let's make it auto-start: Press Windows Key + R , type taskschd.msc, and press Enter Click "Create Basic Task"  on the right side Name:  Velociraptor Server Description:  Runs Velociraptor server on loginClick Next Trigger:  Select "When I log on" Click Next Action:  Select "Start a program" Click Next Program/script:  Browse and select your VBS file: C:\Users\YourUsername\Downloads\start-velociraptor-server-hidden.vbs Click Next Check "Open the Properties dialog"  and click Finish In the Properties dialog: Go to "General"  tab Check "Run with highest privileges" Go to "Settings"  tab Uncheck  "Stop the task if it runs longer than" Click OK Step 4: Test Your Server You can manually start the task to test it: schtasks /run /tn "Velociraptor Server" Wait 10-15 seconds, then open your browser and go to: https:// : You should see the Velociraptor login page! No terminal window anywhere - it's running completely hidden in the background. ----------------------------------------------------------------------------------------------------- Part 2: Setting Up Velociraptor CLIENT Step 1: Generate Client Config From your server machine, generate the client config: cd C:\Users\YourUsername\Downloads velociraptor-v0.75.1-windows-amd64.exe --config server.config.yaml config client > client.config.yaml Copy this client.config.yaml file to the client machine (the laptop/computer you want to monitor). Step 2: Create VBScript to Run Client Hidden On the client machine , open Notepad: notepad start-velociraptor-client-hidden.vbs Paste this code: Set WshShell = CreateObject("WScript.Shell") WshShell.Run "cmd /c cd C:\Users\YourUsername\Downloads && velociraptor-v0.75.1-windows-amd64.exe --config client.config.yaml client", 0, False Important:  Replace the path with your actual path! Save and close. Step 3: Set Up Task Scheduler for Client This is slightly different from the server because we want the client to run even before anyone logs in : Press Windows Key + R , type taskschd.msc, and press Enter Click "Create Basic Task" Name:  Velociraptor Client Description:  Runs Velociraptor client on system startupClick Next Trigger:  Select "When the computer starts"  ⚠️ (Important!)Click Next Action:  Select "Start a program" Click Next Program/script:  Browse and select your VBS file: C:\Users\YourUsername\Downloads\start-velociraptor-client-hidden.vbs Click Next Check "Open the Properties dialog"  and click Finish In the Properties dialog: Go to "General"  tab Select "Run whether user is logged on or not"  ⚠️ (Important!) Check "Run with highest privileges" Check "Hidden" Go to "Settings"  tab Uncheck  "Stop the task if it runs longer than" Click OK Enter your Windows password  when prompted Step 4: Test Your Client Manually start the client task: schtasks /run /tn "Velociraptor Client" Wait about 30 seconds, then check your Velociraptor server web interface. You should see the new client appear in your client list! ----------------------------------------------------------------------------------------------------- Quick Command Line Method (For Advanced Users) If you prefer using command line instead of the GUI, here are the commands: For Server: schtasks /create /tn "Velociraptor Server" /tr "C:\Path\To\start-velociraptor-server-hidden.vbs" /sc onlogon /rl highest For Client: schtasks /create /tn "Velociraptor Client" /tr "C:\Path\To\start-velociraptor-client-hidden.vbs" /sc onstart /ru SYSTEM /rl highest ----------------------------------------------------------------------------------------------------- Why This Method is Better Let me break down why I prefer this method over the built-in Windows Service: It actually works!  - No more "site not reachable" issues Completely hidden  - No annoying terminal windows Auto-starts reliably  - Works every time after reboot Easy to manage  - Use Task Scheduler GUI to start/stop/disable Works for both server and client  - One consistent method Server vs Client Differences Feature Server Client Trigger When I log on When computer starts Run as Current user SYSTEM account Purpose Run when you're working Run always, even offline The client setup ensures it: ✅ Runs even before anyone logs in ✅ Keeps running if user logs out ✅ Survives reboots automatically ✅ Keeps trying to reconnect even when offline ----------------------------------------------------------------------------------------------------- Want to stop Velociraptor? Open Task Scheduler Find the task (Velociraptor Server or Client) Right-click → Disable Want to completely remove it? # Stop and delete the scheduled tasks schtasks /end /tn "Velociraptor Server" schtasks /delete /tn "Velociraptor Server" /f schtasks /end /tn "Velociraptor Client" schtasks /delete /tn "Velociraptor Client" /f # Kill any running processes taskkill /F /IM velociraptor-v0.75.1-windows-amd64.exe ----------------------------------------------------------------------------------------------------- Final Thoughts Look, I know the official documentation says to use service install, but in my experience on Windows, it just doesn't work reliably. The Task Scheduler method might seem like a workaround, but honestly, it's more reliable and easier to troubleshoot. I've been running Velociraptor this way for a while now, and it's been rock solid. No issues, no headaches, just works! If you guys have any questions or run into any issues, drop a comment below. I'm always happy to help! And if this helped you, don't forget to check out my complete Velociraptor series for more tips and tricks! https://www.cyberengage.org/courses-1/mastering-velociraptor%3A-a-comprehensive-guide-to-incident-response-and-digital-forensics Happy hunting! 🦖 ----------------------------------------------Dean---------------------------------------------------

Velociraptor is a powerful tool for incident response and digital forensics, capable of collecting and analyzing data from multiple endpoints. In this guide, I’ll walk you through the setup of Velociraptor in a home lab environment using one main server (which will be my personal laptop) and three client machines: one Windows 10 system, one Windows Server, and an Ubuntu 22.04 version. Important Note:  This setup is intended for forensic analysis in a home lab, not for production environments. If you're deploying Velociraptor in production, you should enable additional security features like SSO and TLS as per the official documentation. Prerequisites for Setting Up Velociraptor Before we dive into the installation process, here are a few things to keep in mind: I’ll be using one laptop as the server (where I will run the GUI and collect data) and another laptop for the three clients. Different executables are required for Windows and Ubuntu , but you can use the same client.config.yaml file for configuration across these systems. Ensure that your server and client machines can ping each other. If not, you might need to create a rule in Windows Defender to allow ICMP (ping) traffic. In my case, I set up my laptop as the server and made sure all clients could ping me and vice versa. I highly recommend installing WSL (Windows Subsystem for Linux) , as it simplifies several steps in the process, such as signature verification. If you’re deploying in production, remember to go through the official documentation to enable SSO and TLS. Now, let's get started with the installation! Download and Verify Velociraptor First, download the latest release of Velociraptor from the GitHub Releases page . Make sure you also download the .sig file for signature verification . This step is crucial because it ensures the integrity of the executable and verifies that it’s from the official Velociraptor source. To verify the signature, follow these steps ( in WSL) : gpg --verify velociraptor-v0.72.4-windows-amd64.exe.sig gpg --search-keys 0572F28B4EF19A043F4CBBE0B22A7FB19CB6CFA1 Press 1 to import the signature. It’s important to do this to ensure that the file you’re downloading is legitimate and hasn’t been tampered with. Step-by-Step Velociraptor Installation Step 1: Generate Configuration Files Once you've verified the executable, proceed with generating the configuration files. In the Windows command prompt, execute: velociraptor-v0.72.4-windows-amd64.exe -h To generate the configuration files, use: velociraptor-v0.72.4-windows-amd64.exe config generate -i This will prompt you to specify several details, including the datastore directory, SSL options, and frontend settings. Here’s what I used for my server setup: Datastore directory: E:\Velociraptor SSL: Self-Signed SSL Frontend DNS name: localhost Frontend port: 8000 GUI port: 8889 WebSocket comms: Yes Registry writeback files: Yes DynDNS : None GUI User: admin (enter password) Path of log directory : E:\Velociraptor\Logs (Make sure log directory is there if not create one) Velociraptor will then generate two files: server.config.yaml (for the server) client.config.yaml (for the clients) During testing, it appears that a few changes have been made. If only the server YAML file is generated and not the client YAML file, please run the following command to generate the client YAML file Step 2: Configure the Server After generating the configuration files, you’ll need to start the server. In the command prompt, run: velociraptor-v0.72.4-windows-amd64.exe --config server.config.yaml gui This command will open the Velociraptor GUI in your default browser. If it doesn’t open automatically, navigate to https://127.0.0.1:8889/ manually. Enter your admin credentials (username and password) to log in. Important:  Keep the command prompt open while the GUI is running. If you close the command prompt, Velociraptor will stop working, and you’ll need to restart the service. Step 3: Run Velociraptor as a Service T o avoid manually starting Velociraptor every time, I recommend running it as a service. This way, even if you close the command prompt, Velociraptor will continue running in the background. To install Velociraptor as a service, use the following command: velociraptor-v0.72.4-windows-amd64.exe --config server.config.yaml service install You can then go to the Windows Services app and ensure that the Velociraptor service is set to start automatically. Step 4: Set Up Client Configuration Now that the server is running, we’ll configure the clients to connect to the server. Before that you’ll need to modify the client.config.yaml file to include the server’s IP address so the clients can connect Note: As for me I am running Server in local host. I will not change the IP in configuration file but if you running server on any other do change it. Setting Up Velociraptor Client on Windows For Windows, you can use the same Velociraptor executable that you used for the server setup. The key difference is that instead of using the server.config.yaml, you’ll need to use the client.config.yaml file generated during the server configuration process . Step 1: Running the Velociraptor Client Use the following command to run Velociraptor as a client on Windows: velociraptor-v0.72.4-windows-amd64.exe --config client.config.yaml client -v This will configure Velociraptor to act as a client and start sending forensic data to the server. Step 2: Running Velociraptor as a Service If you want to make the client persistent (so that Velociraptor automatically runs on startup), you can install it as a service. The command to do this is: velociraptor-v0.72.4-windows-amd64.exe --config client.config.yaml service install By running this, Velociraptor will be set up as a Windows service. Although this step is optional, it can be helpful for p ersistence in environments where continuous monitoring is required. Setting Up Velociraptor Client on Ubuntu For Ubuntu , the process is slightly different since the Velociraptor executable for Linux needs to be downloaded and permissions adjusted before it can be run. Follow these steps for the setup: Step 1: Download the Linux Version of Velociraptor Head over to the Velociraptor GitHub releases page  and download the appropriate AMD64 version for Linux. Step 2: Make the Velociraptor Executable Once downloaded, you need to make sure the file has execution permissions. Check if it does using: ls -lha If it doesn’t, modify the permissions with: sudo chmod +x velociraptor-v0.72.4-linux-amd64 Step 3: Running the Velociraptor Client Now that the file is executable, run Velociraptor as a client using the command below (with the correct config file): sudo ./velociraptor-v0.72.4-linux-amd64 --config client.config.yaml client -v Common Error Fix: Directory Creation You may encounter an error when running Velociraptor because certain directories needed for the writeback functionality may not exist . Don’t worry—this is an easy fix. The error message will specify which directories are missing. For example, i n my case, the error indicated that writeback permission was missing. I resolved this by creating the required file and directory: sudo touch /etc/velociraptor.writeback.yaml sudo chown : /etc/velociraptor.writeback.yaml After creating the necessary directories or files, run the Velociraptor client command again, and it should configure successfully. Step 4: Running Velociraptor as a Service on Ubuntu Like in Windows, you can also make Velociraptor persistent on Ubuntu by running it as a service. Follow these steps: 1. Create a Service File sudo nano /etc/systemd/system/velociraptor.service 2. Add the Following Content [Unit] Description=Velociraptor Client Service After=network.target [Service] ExecStart=/path/to/velociraptor-v0.72.4-linux-amd64 --config /path/to/your/client.config.yaml client Restart=always User= [Install] WantedBy=multi-user.target Make sure to replace  and the paths with your actual user and file locations. 3. Reload Systemd sudo systemctl daemon-reload 4. Enable and Start the Service sudo systemctl enable velociraptor sudo systemctl start velociraptor Step 5: Verify the Service Status You can verify that the service is running correctly with the following command: sudo systemctl status velociraptor Conclusion T hat's it! You’ve successfully configured Velociraptor clients on both Windows  and Ubuntu  systems . Whether you decide to run Velociraptor manually or set it up as a service, you now have the flexibility to collect forensic data from your client machines and analyze it through the Velociraptor server. In the next section, we'll explore the Velociraptor GUI interface , diving into how you can manage clients, run hunts, and collect forensic data from the comfort of the web interface. Akash Patel

Now let’s talk about Email Log Search , because this is one of the most commonly used  (and misunderstood) tools when you’re investigating phishing, mailbox compromise, or suspicious inbound email. If a user reports: “I got a weird email” This is usually where you end up first. First thing to understand: the 30‑day rule Google stores email transaction logs  differently depending on how old the email is. This affects what you can search , how you can search , and what results you’ll get . Think of it as two different worlds: Emails within the last 30 days This is the "easy mode." ✅ No strict search parameters required ✅ You can search: Sender Recipient IP address Message ID Google Groups email Results limited to 1000 messages  (screen + CSV export) Near real-time (usually minutes, sometimes up to 24 hours lag) This is where you do fast phishing triage . Emails older than 30 days This is where things get restrictive. ❌ You cannot  search Google Group email ❌ You must  search using: Gmail recipient or Message ID ✅ No limit on historical depth (can go back years) Still limited to 1000 results per search Only post‑delivery details  are available Full delivery history is gone In other words: you can  search forever—but only if you already know exactly what you’re looking for . ------------------------------------------------------------------------------------------------------- Where Email Log Search lives now Google recently moved and upgraded the interface. You’ll now find it under: Admin Console → [|||]→ Reporting→ Email Log Search This newer interface gives you: Better filtering Faster searches Cleaner drill-down into message details If you already have a Message ID , always use it. It’s the fastest and cleanest way to get results. ------------------------------------------------------------------------------------------------------- What Email Transaction Logs actually show you Email logs tell you about mail flow , not mailbox content. You can see: Inbound and outbound messages SMTP path details Sender IP addresses Delivery status Whether the message was: Delivered Quarantined Rejected In the recipient details, you can also see the current state of the email  inside the mailbox. That’s extremely useful when: A phishing email was delivered Some users opened it Others haven’t yet This helps you decide whether to pull the email from inboxes immediately . ------------------------------------------------------------------------------------------------------- Using Email Log Search for phishing investigations This is one of the strongest use cases. Typical workflow: User reports a phishing email You grab: Message ID Sender address Sender IP Search Email Log Search Identify: How many users received it Whether variations were used If multiple emails came from the same SMTP server Even if the attacker rotated sender addresses, the IP often stays the same , which makes correlation easier. Limitation: this method is most effective within 30 days  of delivery. ------------------------------------------------------------------------------------------------------- Quarantined and blocked email (the invisible stuff) Here’s a really important thing many admins miss: Some emails never reach user mailboxes at all . Google’s Gmail gateway evaluates messages before  they enter Workspace storage. If an email is blocked at this stage: ❌ It will not  appear in Vault ❌ It will not  appear in Quarantine ❌ It cannot be recovered It will only  appear in Email Log Search . Attachment-based blocking Gmail automatically blocks certain attachment types, including: Executables Scripts Certain archive contents This also applies when: The file is inside a ZIP The ZIP is not password-protected Google will even attempt to brute-force common ZIP password s  like: infected malware If it can open the archive and finds a blocked file type, the email is rejected. No notification is sent to: The user The admin The sender Email Log Search is the only  place you’ll ever see it. ------------------------------------------------------------------------------------------------------- Why this matters during investigations During IR, you’re often asked: “Did anyone receive this email?” “Was it delivered or blocked?” “Can we retrieve it?” Email Log Search helps you answer all three —but you must understand its limits. Once Gmail blocks an email at the gateway: It never becomes evidence you can collect. You can only prove that it was blocked . ------------------------------------------------------------------------------------------------------- Final takeaway Email Log Search is: Excellent for phishing response Powerful for mail flow analysis Extremely time-sensitive But it is not  a mailbox forensics tool. Think of it as your email traffic CCTV —it tells you what passed through the door , not what’s stored inside the room. Used correctly, it’s one of the most valuable tools in Google Workspace investigations. ------------------------------------------Dean--------------------------------------------------------

Enough theory. Now let’s actually touch NetFlow data . If you’re doing DFIR, threat hunting, or even basic network investigations, one toolkit you must  be comfortable with is the nfdump suite. This suite gives you three extremely important tools: nfcapd – the collector nfpcapd – the pcap-to-NetFlow converter nfdump – the analysis engine ----------------------------------------------------------------------------------------------------------- nfcapd: The NetFlow Collector (Where Everything Starts) nfcapd is a daemon, not a one-time command. Its job is simple: listen on a UDP port receive NetFlow data from trusted exporters (routers, firewalls, switches) write that data to disk in a compact binary format It supports: NetFlow v5, v7, v9 IPFIX sFlow So regardless of vendor or flow standard, nfcapd usually has you covered. How Much Storage Do You Actually Need? This is one of the first questions everyone asks. A rough rule of thumb: ~1 MB of NetFlow data for every 2 GB of network traffic Is this perfect? No. Is it useful for planning? Yes. Your actual numbers will depend on: number of flows traffic patterns sampling exporter behavior But it’s a good starting point when designing storage. How nfcapd Stores Data (And Why It Matters) When nfcapd writes flow data, it uses a very clean naming scheme: nfcapd.YYYYMMDDhhmm Example: nfcapd.201302262305 Why this matters: files sort naturally by time no database needed easy scripting easy forensic timelines By default, nfcapd rotates files every 5 minutes. That means: 288 files per exporter per day predictable storage growth easy time slicing during investigations ----------------------------------------------------------------------------------------------------------- Bonus Feature: Flow Forwarding (-R Option) One very underrated feature of nfcapd is flow forwarding. You can collect NetFlow and forward it to another collector at the same time. Example scenario: local collection for DFIR central collection for SOC visibility Example command: nfcapd -p 1025 -w -D -R 10.0.0.1/1025 \ -n router,10.0.0.2,/var/local/flows/router1 Command breakdown: nfcapd - NetFlow capture daemon -p 1025 - Listen on port 1025 for incoming NetFlow packets -w - Align file rotation to the next interval (e.g., start at the top of the hour) -D - Run as a daemon (background process) -R 10.0.0.1/ 1025   - Act as a repeater/forwarder: send received flows to IP 10.0.0.1 on port 1025 -n router,10.0.0.2,/var/local/flows/routerlogs - Define an identification string: router - Identifier name for this source 10.0.0.2 - Expected source IP address /var/local/flows/routerlogs - Directory where flow files will be stored In summary: This command starts a NetFlow collector that listens on port 1025, stores flow data from router at 10.0.0.2 into /var/local/flows/routerlogs , and simultaneously forwards the data to another collector at 10.0.0.1/1025 . It runs in the background as a daemon. This is extremely useful in larger environments. nfpcapd: Turning PCAPs into NetFlow Now this is where DFIR people should pay attention. nfpcapd lets you: take a pcap file  and convert it into NetFlow-style records Why does this matter? Because parsing large pcaps is: slow CPU-heavy painful at scale NetFlow-based analysis is orders of magnitude faster. So the smart workflow is: Convert pcap → NetFlow Hunt quickly using NetFlow Go back to full pcap only where needed Example: nfpcapd -r bigFlows.pcap -l /mnt/c/Users/Akash/Downloads/ This step alone can save hours or days in an investigation. ----------------------------------------------------------------------------------------------------------- nfdump: Where the Real Analysis Happens Once flows are collected (or converted), this is where we start asking questions. nfdump is a command-line NetFlow analysis tool. It: reads nfcapd binary files applies filters summarizes results responds very fast — even on huge datasets Important point: nfdump does not magically find “bad traffic” Its power comes from: how you ask questions how you refine hypotheses how you chain queries together This is investigative work, not alert-driven work. ----------------------------------------------------------------------------------------------------------- Reading NetFlow Data with nfdump You can read: a single file or an entire directory tree Reading a Single File nfdump -r /mnt/c/Users/Akash/Downloads/nfcapd.201302262305 This reads: flows from one exporter for a specific 5-minute window Perfect for targeted investigations. Reading a Directory (Much More Common) nfdump -R /mnt/c/Users/Akash/Downloads/test/ This tells nfdump: recursively walk the directory read all  NetFlow files inside This is how you analyze: days weeks months of traffic ----------------------------------------------------------------------------------------------------------- Building Real Investigative Queries Let’s look at a realistic example. Goal: Find internal systems that accessed internet web servers without using the corporate proxy. Conditions: traffic passed through internet-facing router destination ports 80 or 443 exclude proxy IP 172.0.1.1 specific 24-hour window show only top 10 systems Command: nfdump -R /mnt/c/Users/Akash/Downloads/test/ \ -t '2026/01/12.12:00:00-2026/01/13.12:00:00' \ -c 10 'proto tcp and (dst port 80 or dst port 443) and not src host 172.0.1.1' This is classic NetFlow hunting: scoped fast hypothesis-driven From here, you pivot: which hosts? how often? how much data? where did they connect? ----------------------------------------------------------------------------------------------------------- line Output (Default, Lightweight) This is the default view and the one you’ll see most often when you’re doing quick scoping. It shows: start and end time source and destination IPs ports protocol bytes and packets Example: nfdump -R /mnt/c/Users/Akash/Downloads/test -o line host 172.16.128.169 This is perfect when you’re asking: “Is this IP even talking on my network?” Fast. Minimal. No noise. ----------------------------------------------------------------------------------------------------------- 2. long Output (Adds TCP Flags) The long format builds on line and adds: TCP flags Type of Service (ToS) Example: nfdump -R /mnt/c/Users/Akash/Downloads/test -o long 'proto tcp and port 445' Why this matters: TCP flags tell a story SYN-only traffic looks very different from established sessions RST storms, half-open connections, or scanning behavior start to stand out Important reminder: Each line is unidirectional. A normal bidirectional conversation: client → server server → client …will always appear as two separate flow records. This trips people up early on. ----------------------------------------------------------------------------------------------------------- 3. extended Output (Adds Statistics) This is where things get interesting. The extended format adds derived values , calculated at query time: packets per second bits per second bytes per packet Example: nfdump -R /mnt/c/Users/Akash/Downloads/test -o extended 'proto tcp and port 445' These values help you distinguish: interactive shells (low & slow) file transfers (fast ramp-up, steady throughput) dormant C2 channels (tiny but persistent) None of this data is stored explicitly — it’s derived — but it’s incredibly useful for behavioral analysis. ----------------------------------------------------------------------------------------------------------- IPv6 Note (Important but Often Missed) nfdump fully supports IPv6 , but truncates addresses by default for readability. If you want full IPv6 visibility, use: line6 long6 extended6 Same formats — just IPv6-aware. ----------------------------------------------------------------------------------------------------------- Practical Hunt: Finding Patient Zero Using NetFlow Now let’s do real hunting , not theory. Goal: Identify internal hosts communicating with this C2 Step 1: First Hits of the Day Start with a known NetFlow file Ask: “Who talked to this IP first today?” nfdump -R /mnt/c/Users/Akash/Downloads/test -O tstart -c 5 'proto tcp and dst port 8014 and host 172.16.128.169 We see the first hit  into the day. That’s early — but maybe not early enough. Step 2: Expand the Time Window (Overnight) If the first hit isn’t at the beginning of the capture window, that’s a signal. So we expand: (overnight window) nfdump -R /mnt/c/Users/Akash/Downloads/test -t '2013/02/26.23:00:00-2013/02/26.23:10:60' -O tstart -c 1 'proto tcp and dst port 8014 and host 172.16.128.169' Step 3: What Else Did Patient Zero Do? Now we pivot. Same time window, but focus on the internal host itself: nfdump -R /mnt/c/Users/Akash/Downloads/test -t '2013/02/26.23:00:00-2013/02/26.23:10:60' -O tstart 'host 172.16.128.169' This answers: what happened before C2? was there a download? was there lateral movement? did anything precede the UDP traffic? Step 4: Infrastructure Expansion Using ASN Analysis 172.16.128.169 Using WHOIS: whois 172.16.128.169 | grep AS Step 5: Hunt the “Internet Neighborhood” If the attacker uses one provider, they may use more infrastructure in the same ASN. So we ask: “Who talked to this ASN all month?” nfdump -q -R /mnt/c/Users/Akash/Downloads/test -o 'fmt:$sa $da' 'dst as 36351' | sort | uniq What this gives you $sa → source IP (internal) $da → destination IP (external) Deduplicated list of unique communications Viewing Minimal Samples for Orientation Sometimes you just want a quick sanity check : nfdump -R mnt/c/Users/Akash/Downloads/test -t '2013/02/26.23:00:00-2013/02/26.23:10:60' -O tstart -c 1 Or inspecting a single file: nfdump -r mnt/c/Users/Akash/Downloads/test/nfcapd.201302262305 -O tstart -c 5 These commands are underrated — they help you: Validate time ranges Confirm exporter behavior Avoid wrong assumptions early ------------------------------------------------------------------------------------------------------------ Why Aggregation Changes Everything Because flows are split across files, one real-world connection may appear as many records. By default, nfdump aggregates using five key values: Source IP Destination IP Protocol Source Port Destination Port Flows sharing these values are merged into a single logical event . Detecting Port Scanning with Custom Aggregation Port scanners behave differently: Source port changes constantly Target port stays fixed nfdump -q -R mnt/c/Users/Akash/Downloads/test -O bytes -A srcip, proto, dstport -o 'fmt: $sa -> $pr $dp $byt $fl' This answers: Who is consuming the most bandwidth Which protocol and port How many flows were involved Great for: Data exfiltration hunting Rogue services Abnormal internal behavior Using “TopN” Statistics for Threat Hunting Most engineers use TopN for bandwidth. Investigators use it differently. Syntax -s statistic[:p][/orderby] Example nfdump -R /mnt/c/Users/Akash/Downloads/test/ -s ip/bytes -s dstport:p/bytes -n 5 Why this matters Identify staging systems (high outbound bytes) Detect scanners (high flow counts) Separate TCP vs UDP behavior with :p TopN becomes powerful only when driven by intelligence, not curiosity. ------------------------------------------------------------------------------------------------------------ Final Thoughts nfdump isn’t flashy. It doesn’t decrypt payloads. It doesn’t show malware strings. But when used correctly, it tells you: Who talked For how long How often And how much data moved In real investigations, that context is often enough to confirm compromise, scope incidents, and prioritize response. ----------------------------------------------Dean-------------------------------------------------------

Let’s talk about where NetFlow either becomes incredibly powerful… or painfully slow. Most NetFlow analysis are done on GUI: browser-based or thin clients that are basically a browser wrapped with authentication, branding, and access control Nothing wrong with that — in fact, it makes a lot of sense. In most deployments, the GUI or console is hosted close to the storage laye r  or on the same system entirely. That design choice is intentional. When analysts start querying months or years of NetFlow data, you do not  want that traffic flying across the network. Keeping compute, storage, and analysis close together reduces latency and prevents unnecessary network load. ------------------------------------------------------------------------------------------------------------- Performance: The Real Bottleneck Nobody Plans For In commercial NetFlow products, the number of concurrent users is usually limited by: hardware capacity performance thresholds licensing In open-source setups, licensing disappears — but performance absolutely does not. Here’s the reality: Even a handful of analysts clicking around dashboards can place massive load on the system. Drilling down into NetFlow data is extremely I/O-intensive. Multiple users querying long time ranges at the same time can quickly: saturate disk I/O spike CPU usage increase memory pressure and even introduce network congestion Out of all NetFlow components — exporter, collector, storage, analysis —the GUI or analysis console is by far the most resource-hungry. And historical searches make it worse. ------------------------------------------------------------------------------------------------------------- Storage Is Not Optional — It’s the Strategy Long-term NetFlow analysis only works if all records remain available locally to the analysis server. That means: ever-growing storage constant monitoring planned scaling Storage decisions are usually dictated by the analysis software itself. Most tools manage their own storage backend because the UI, queries, and analyst workflows depend on it. This isn’t something you “figure out later” .If storage is under-provisioned, performance will  suffer — and data will  be lost. ------------------------------------------------------------------------------------------------------------- Network Teams vs DFIR Teams: Very Different Needs This is where things get interesting. Network Engineering Teams They usually care about: near real-time NetFlow bandwidth usage link saturation uptime and performance For them, recent data (days or weeks) is the priority. Long-term historical NetFlow? Rarely critical. DFIR & Security Teams Completely different mindset. Incident responders want: maximum retention historical visibility the ability to look back in time Why? Because breach discovery is slow. That’s why security teams often deploy their own NetFlow infrastructure, separate from network engineering. It allows: long-term retention forensic-grade investigations zero impact on production network tooling With this model, security teams can identify: command-and-control traffic beaconing behavior suspicious outbound communications …even months or years after the initial compromise. Most IT departments simply cannot afford to retain data at that scale — but security teams often must. ------------------------------------------------------------------------------------------------------------- How NetFlow Data Is Stored (And Why It Matters) There’s no single standard here. Commercial tools usually rely on databases Open-source tools often use: binary formats ASCII formats or search-optimized document stores Some tools allow multiple formats to coexist so the same dataset can be analyzed with different tools. File-based storage has one big advantage: accessibility If the data is stored as files, organizations can: reuse the data analyze it with multiple tools adapt as requirements change For some teams, the choice of NetFlow platform is driven less by dashboards and more by how easily the data can be reused later. ------------------------------------------------------------------------------------------------------------- NetFlow Is Powerful — But Not Magic Let’s be honest. NetFlow does not contain payloads. There is no content. That means analysts often operate on reasonable assumptions , not absolute proof. Example: Seeing TCP/80 traffic does not  guarantee HTTP. Without PCAP, proxy logs, or host artifacts, that conclusion is still a hypothesis. But in incident response, educated hypotheses are normal — as long as we constantly look for evidence that disproves them. This is where correlation matters: IDS alerts proxy logs endpoint telemetry protocol errors NetFlow rarely works alone. ------------------------------------------------------------------------------------------------------------- Baselines Turn Guesswork into Hunting One way to reduce uncertainty is baselining. If: 95% of engineering traffic normally goes to 20 autonomous systems and a new AS suddenly appears in the top traffic list That’s worth investigating. Same idea for: known botnet infrastructure traffic redirection services suspicious hosting providers Even without payloads, patterns matter. ------------------------------------------------------------------------------------------------------------- In a perfect world, we’d answer questions like: Did the attacker exfiltrate data? What tools were transferred? Which credentials were used? How long was access maintained? Who was behind the attack? In reality, limited data retention, encryption, and undocumented protocols make that difficult. NetFlow won’t answer everything. But combined with: protocol knowledge baselines timing analysis throughput patterns directionality …it allows analysts to make informed, defensible conclusions even when full packet capture is unavailable. ------------------------------------------------------------------------------------------------------------- Final Thought Yes, there’s a lot of theory here. And that’s intentional. Because the next article will be practical: So…tie your seatbelts — we’re about to get hands-on. ----------------------------------------------Dean----------------------------------------------------------

I’ll be honest. For a long time, I never really gave NetFlow  the priority it deserves. PCAP was always the gold standard in my head. If you want to know what really  happened on the network, you go straight to packet capture. End of story. But after reading more, testing more, and actually thinking about scale, cost, and real-world SOC/DFIR constraints, my opinion changed. Today, I want to talk about why NetFlow matters , when it actually makes your job easier, and why full PCAP is not always the right answer — especially in enterprise environments. ------------------------------------------------------------------------------------------------------------- Why Full PCAP Sounds Great… But Breaks in Reality Yes, full packet capture is still the holy grail of network analysis. But the moment you move into a large corporate environment, things start to fall apart. Here’s why PCAP doesn’t scale well: Privacy laws (As I am currently in EU I can see this problem): In many regions (especially parts of the EU), capturing full packet content can be legally problematic — even on corporate networks. Modern network volume : Network speeds are insane compared to a few years ago, and modern operating systems generate massive amounts of traffic. Duplicate packets everywhere : If you capture traffic at multiple points (internet gateway, internal segments, regional links), you often store the same packets multiple times . Storage costs explode fast. Deep analysis is expensive : Parsing huge PCAP datasets requires powerful servers, fast storage, and enterprise-grade tooling — none of this is cheap. Global environments are painful : If your capture points are spread across Europe, APAC, and North America, centralizing that data for analysis means serious bandwidth costs. Budget reality : Some companies won’t blink at a million-dollar project. Most organizations simply can’t afford it. Encrypted traffic changed the game : With TLS everywhere, perfect forward secrecy, and certificate pinning, full payload retention is often useless. You’re storing a lot of data with very little analytical value. This is where NetFlow quietly becomes extremely powerful. ------------------------------------------------------------------------------------------------------------- So What Exactly Is NetFlow? A NetFlow record is basically a statistical summary of network traffic observed at a specific point in the network. Instead of storing packet content, NetFlow groups packets into a flow based on shared attributes, such as: source IP destination IP protocol source port destination port These grouped packets become a flow record that tells you what talked to what , when , and how much data moved . You don’t see the payload —but you see the story of the connection. A Simple Example (No Wireshark Needed) Let’s say a user opens a browser and connects to a website. The client uses a high TCP port (above 1023) The server listens on TCP 443 A TCP session is established A NetFlow sensor watching this link will notice: when the connection started which IP talked to which IP which ports were used how much data moved in each direction when the communication stopped Important detail:👉 NetFlow is unidirectional So one browser session usually becomes two flow records: client → server server → client NetFlow doesn’t care about “client” or “server” roles — only sender and receiver. ------------------------------------------------------------------------------------------------------------- NetFlow + Encrypted Traffic = Perfect Match Encrypted traffic is where NetFlow really shines. If TLS interception is not enabled: full PCAP gives you encrypted blobs payload analysis becomes almost useless disk usage goes through the roof NetFlow doesn’t care about encryption. It records: who connected when how often how much data moved That’s often exactly what you need for: command-and-control detection beaconing analysis lateral movement data exfiltration investigations ------------------------------------------------------------------------------------------------------------- Why DFIR and Threat Hunting Love NetFlow Another underrated benefit: retention. Because NetFlow data is: small content-free privacy-friendly Organizations often retain it for long periods of time. This means: you can apply new threat intelligence  to old data you can hunt retroactively you can validate attacker dwell time This is what real threat hunting looks like. ------------------------------------------------------------------------------------------------------------- A Quick Word on NetFlow History (Because It Matters) NetFlow was originally developed by Cisco back in 1996 , not for security, but to optimize routing performance. Over time, it evolved into a powerful traffic visibility mechanism. Key points: NetFlow v5 is still widely used (IPv4 only, unidirectional, old design) NetFlow v9 introduced flexibility and extensibility The IETF standardized this as IPFIX (sometimes called NetFlow v10) Today : Cisco supports v5 and v9 Most vendors support v5, v9, and IPFIX VMware ESX can export IPFIX Cloud providers have their own equivalents Examples : AWS VPC Flow Logs Azure NSG Flow Logs Google VPC Flow Logs Zeek conn.log (very similar concept) ------------------------------------------------------------------------------------------------------------- One Important Caveat: Sampling Matters Before using NetFlow for investigations, you must know: Where it’s enabled : If only certain interfaces export flows, blind spots exist. Whether it’s sampled or not Standard NetFlow tracks every packet Sampled NetFlow tracks every n  packets Sampled NetFlow: under-represents data volume is not suitable for forensic accuracy still useful for trends and visibility This distinction is critical. ------------------------------------------------------------------------------------------------------------- Now you know why  NetFlow matters, let’s talk about how it actually works in practice  To build a NetFlow monitoring setup, you really only need four core components. The Four Building Blocks of NetFlow Think of NetFlow like a pipeline. Exporter This is the device that creates NetFlow records . Usually this is: a router a firewall a Layer 3 / Layer 4 switch But it doesn’t have to be limited to that. Anything that can observe traffic and summarize it can act as an exporter. Collector The collector is where all those flow records land. It receives NetFlow data from: one exporter or dozens of exporters This is where visibility starts to come together. Storage Collectors don’t just receive data — they store it. This storage needs to be: indexed searchable optimized for time-based queries NetFlow records are small, but over time they add up, and that’s actually a good thing — historical data is gold for investigations. Analysis Console This is where you  sit. It could be: a web UI a thin client a CLI tool This is where you ask questions like: “Who talked to this IP?” “When did this start?” “How much data moved?” “Is this normal?” ------------------------------------------------------------------------------------------------------------- One Box or Many? Both Are Valid In labs, training environments, or testing setups: exporter collector storage analysis can all live on one Linux system . In real environments, it’s usually different. A more common setup looks like this: routers and firewalls export NetFlow flows go to a centralized collector/storage system analysts access data via browser or CLI Simple. Scalable. Effective. ------------------------------------------------------------------------------------------------------------- Plan NetFlow Early — You’ll Thank Yourself Later One thing I’ve learned the hard way: NetFlow is much easier to deploy before the network design is finalized. Yes, NetFlow records are small —but like all behavioral data, their real value is time. The longer you retain them, the more powerful they become. Exporters Are Not Just Routers We often picture a router when we think about NetFlow exporters — and that’s fair. But exporters can also be: firewalls L3/L4 switches dedicated probes even endpoints (in some cases) Exporting from every  endpoint usually isn’t practical. However, during an incident? Running a probe on a tap or SPAN port can give tactical visibility exactly where you need it. ------------------------------------------------------------------------------------------------------------- Why NetFlow Uses UDP (And Why That’s Not as Bad as It Sounds) By default, NetFlow uses UDP  to send flow data from exporter to collector. At first glance, this sounds scary: “UDP is unreliable!” But there are solid reasons for this choice. Why UDP works well here: Very low protocol overhead Minimal CPU and memory usage Scales well on high-speed links Easy to send data to multiple collectors at once That last point is important. Security teams and network teams can: receive the same flows from the same exporters without duplication overhead What About Reliability? Some platforms support SCTP ( Stream Control Transmission Protocol) instead of UDP. With SCTP: collectors confirm receipt exporters can retransmit if needed data loss risk is reduced On very large or fast links, exporters may also send interim flow updates before a flow ends. That way, even if something is lost, you still have partial visibility. ------------------------------------------------------------------------------------------------------------- Where You Place Exporters Matters (A Lot) This is where NetFlow design becomes interesting. You don’t need NetFlow everywhere . You need it in the right places. For example: capturing at the firewall gives you internet visibility capturing one hop behind the firewall gives you internal east–west traffic capturing at core switches shows workstation-to-workstation movement That subtle difference can completely change what you can detect. Attackers Love a Three things— So Should You Attackers usually operate around these three things: Internet Administrator workstations Critical data systems If you design NetFlow around these things, you gain massive visibility. This is how you catch: lateral movement credential abuse staging before exfiltration ------------------------------------------------------------------------------------------------------------- Full Packet Capture Still Has a Role In some segments — especially small, high-risk ones —full packet capture still makes sense. For example: R&D networks sensitive server limited user groups But even then: NetFlow should support PCAP, not replace it. PCAP gives detail. NetFlow gives context and speed. ------------------------------------------------------------------------------------------------------------- A Practical Way to Think About Design If you’re involved in NetFlow planning, these steps help keep things realistic: Identify critical data Not everything matters equally. Find what actually needs protection. Map the network You’d be surprised how many organizations don’t have a complete network map. If you don’t know: where data lives how it moves who accesses it You can’t protect it properly. Find choke points Where do multiple networks join? Where does traffic have  to pass? Those are perfect NetFlow locations. Identify data “centers of gravity” Not just “domain controllers” or “file servers”. Think: source code repositories admin systems finance platforms executive devices DNS servers These are attacker magnets. Combine NetFlow and PCAP smartly NetFlow at high-volume locations PCAP at critical choke points Centralized analysis Sensible retention policies If storage is tight, even a basic Linux box with large disks can do the job when configured properly. ------------------------------------------------------------------------------------------------------------- Final Thought (For This Section) NetFlow isn’t flashy. It doesn’t show payloads. It doesn’t decode protocols. But it gives you speed, scale, and historical visibility —three things every SOC and DFIR team desperately needs. We will continue further in next article! Next Article : Where NetFlow Either Shines or Struggles -------------------------------------------Dean-------------------------------------------------------------

If you’ve been following my work for a while, you already know this —I’ve written an entire series on SentinelOne. (If you haven’t read it yet, I’ll drop the link below — go check it out.) https://www.cyberengage.org/courses-1/mastering-sentinelone%3A-a-comprehensive-guide-to-deep-visibility%2C-threat-hunting%2C-and-advanced-querying%22 Recently, I also wrote about Dropzone AI  and how AI is changing SOC capabilities, and yes, potentially even affecting SOC jobs. https://www.cyberengage.org/courses-1/dropzone-ai But today, I want to talk about something slightly different . This is not a new shiny tool . This is not something extra you need to buy and integrate . This is something SentinelOne quietly did that changed how SOCs operate — at least in the EDR world . I’m talking about SentinelOne Vigilance MDR . ---------------------------------------------------------------------------------------------------------- This Isn’t “Just Another MDR” Before we go deeper, let me clarify one thing. When people hear Vigilance , they often think only about MDR .But Vigilance actually includes: Vigilance MDR Vigilance DFIR Today, I’m not focusing on Vigilance DFIR.That deserves its own deep dive. This article is about 24×7 Vigilance MDR —and more importantly, how it changes day-to-day SOC life, not just how it looks on a slide deck. I’ll also walk through real-world examples later — how investigations look, how alerts are handled, and how much work never even reaches your SOC. ---------------------------------------------------------------------------------------------------------- The Reality: Threats Are Growing Faster Than SOCs Let’s be honest for a moment. Threats today aren’t just increasing — they’re: faster, broader, and more complex. At the same time, there’s a global shortage of experienced cybersecurity professionals. Most SOCs I’ve seen are struggling with: alert fatigue, limited night coverage, junior analysts forced to make senior-level decisions, and too much time spent on “Is this even real?” This is exactly why security teams started leaning toward managed threat services, backed by strong automation. And this is where SentinelOne made a smart move. ---------------------------------------------------------------------------------------------------------- What Vigilance MDR Actually Is Vigilance MDR is a 24×7 Managed Detection and Response servic e  designed to extend  SentinelOne’s autonomous platform — not replace your SOC. Here’s the key idea: Let the platform detect and act fast, let expert humans validate, investigate, and respond —and let your SOC focus on what actually matters. Vigilance Respond allows organizations to offload threat investigation and response to SentinelOne’s own global security experts. Not outsourced. Not third-party. Actual SentinelOne analysts. ---------------------------------------------------------------------------------------------------------- Speed Matters — and This Is Where It Gets Interesting (As per Sentinel One offical documents) But Reality is little different One stat that usually makes SOC teams pause: On average, incidents are resolved in 20 minutes or less. That’s not because someone is clicking faster. It’s because: Storyline™ technology already correlates activity, threats are prioritized before humans even touch them, and analysts work with full endpoint context , not raw alerts. By the time something is escalated to you, it’s usually: real, validated, and already partially or fully contained. ---------------------------------------------------------------------------------------------------------- Everything documents like — service descriptions, MTTR numbers, dashboards —that’s mostly what SentinelOne already documents very well. And honestly? Their documentation is solid. If you want to know: how to configure Vigilance, how to enable MDR, how to set policies, SentinelOne Community already covers this well, so I won’t repeat it here. What I do  want to talk about is: how Vigilance MDR behaves in real life, how it feels when you’re actually running a SOC, and where it helps — and where it still needs humans. ---------------------------------------------------------------------------------------------------------- Vigilance Service Levels (Quick Context) Just for context, SentinelOne offers Vigilance in multiple service levels: Vigilance MDR 24×7×365 MDR for endpoints and cloud workloads with a low-friction experience. Vigilance MDR + DFIR Adds forensic investigations, major incident response, and advisory services. Singularity™ MDR Goes beyond endpoints, includes Wayfinder Threat Hunting and a named Threat Advisor. Singularity™ MDR + DFIR Combines extended MDR coverage with full DFIR expertise. Today, I’m focusing only on Vigilance MDR (24×7) .No DFIR deep dive here — that’s a separate topic. ---------------------------------------------------------------------------------------------------------- One Important Thing People Miss About Vigilance MDR Here’s something Vigilance MDR does NOT work on custom rules you create (like STAR rules). It only works on: alerts generated by SentinelOne detections, alerts that appear under Threats   in the platform. There are  a few edge cases, but in general: Threat tab → Vigilance analyzes Alert tab → Vigilance Does not Analyze If you’re confused about the difference between Threats  and Alerts , check my previous articles — I’ve already broken that down in detail. ---------------------------------------------------------------------------------------------------------- What Changes When You Enable Vigilance MDR Once Vigilance MDR is enabled, you’ll notice a few things immediately: Threat Services Tab You get a new Threat Services  section where Vigilance is configured and managed. Escalation Contacts You define: primary contact secondary contact If Vigilance needs clarification or follow-up, they actually reach out  — via email or phone. This isn’t a silent MDR. Response Policy (This Is Important) This is one feature I genuinely like. Not every alert gets: killed, quarantined, or remediated blindly. Sometimes: an alert is suspicious, SentinelOne marks it as true positive, but Vigilance does not automatically remediate . Instead, they add context and say: “Review this and take necessary action.” Why this matters: Decisions are made based on context , not just automation. And honestly — this is how security should  work. ---------------------------------------------------------------------------------------------------------- MDR Dashboard: Where You Actually See the Value Now let’s talk about the MDR Dashboard  (available in the Singularity Operations Center). This dashboard gives scope-level visibility  into: alerts handled by MDR, alerts outside MDR scope (As i said early Custom rule not handled by Vigilance) true positives vs false positives, incidents created, mitigation actions taken, MTTR and SLO performance. This is where you visually  see: “Okay… Vigilance really did close that many alerts  for us.” Severity ---------------------------------------------------------------------------------------------------------- Real-World Examples (This Is the Important Part) Now let’s move away from theory. Example 1: False Positive — File Unquarantined In this case: file was detected, process was killed, file was quarantined automatically. Vigilance MDR investigated the activity, confirmed it was a false positive, and unquarantined the file. If you look at the timeline: behavior is clear, no malicious intent, clean execution chain. Honestly — any experienced analyst would agree with this decision. This is Vigilance MDR working perfectly. Example 2: False Positive — File NOT Unquarantined Now this one is interesting. Even though: the alert could be considered a false positive, I personally also see it as low risk, I still would not want the file unquarantined. And Vigilance MDR did exactly that: they marked it as false positive, but did not  restore the file. Why? Because restoring it could still introduce unnecessary risk. This is where human judgment matters —and Vigilance MDR respects that. Small But Important Detail: Auto-Exclusions In my setup: I intentionally did not  enable auto-exclusions. I wanted: the power to stay in my hands. Yes, Vigilance MDR can automate exclusions —but I prefer manual control, especially in sensitive environments. True Positive Examples Example 3: True Positive (Static Detection) Clear malicious activity. Static detection. No ambiguity. Vigilance MDR validated it and handled it properly. Example 4: True Positive With Remediation + Email Follow-Up This is where Vigilance MDR really shines. After remediation: they sent a detailed email , including deep visibility analysis, execution chain, and recommended next steps . Not just: “We fixed it.” But: “Here’s what happened, why it matters, and what you should do next.” That email alone can save analysts hours of investigation time. ---------------------------------------------------------------------------------------------------------- The Honest Part: Where Vigilance MDR Isn’t Perfect Now let’s be honest — because no tool is perfect. Delays Happen I’ve noticed: sometimes a delay of 2 hours, occasionally even 3 hours, between: alert creation, investigation, remediation, and reporting. Why? Because dynamic alerts take time. Static alerts are fast — automation kicks in quickly. Dynamic behavior-based alerts? They need: correlation, timeline analysis, human validation. And that takes time. ---------------------------------------------------------------------------------------------------------- Final Thought (For Now) My honest take? Vigilance MDR is really good . It dramatically reduces alert fatigue . It keeps dashboards clean. It improves SOC sanity. But: You still need an analyst behind the table. Vigilance MDR doesn’t replace humans. It makes humans more effective. --------------------------------------------------Dean----------------------------------------------------

By now, if you’ve followed the previous articles in this series, you should be very comfortable with: Creating timelines using Plaso / Log2Timeline Running Plaso on Windows and Ubuntu Creating timelines for Linux systems Understanding how timelines help reconstruct attacker activity If you haven’t read those yet, you can find them here: Creating a Timeline for Linux with fls, mactime, and Plaso (Log2Timeline) https://www.cyberengage.org/post/creating-a-timeline-for-linux-triage-with-fls-mactime-and-plaso-log2timeline Running Plaso / Log2Timeline on Windows https://www.cyberengage.org/post/running-plaso-log2timeline-on-windows A Deep Dive into Plaso / Log2Timeline Forensic Tools on Linux https://www.cyberengage.org/post/a-deep-dive-into-plaso-log2timeline-forensic-tools At this point, you may already feel confident—maybe even like an expert—when it comes to building timelines. 👉 Case studies are where timelines truly start to make sense. So yes… we’re doing case studies 😄Because learning again (and differently) is never a bad thing. Let’s get started. --------------------------------------------------------------------------------------------------------- Case Study 1: Web Server Intrusion (Triage-Based Timeline) Scenario You receive an alert about suspicious activity on a production web server. Time is critical, and you have limited context. Instead of waiting for a full disk image, you collect a triage package from the system: Windows Event Logs IIS web server logs Master File Table (MFT) parsed separately Your goal: Validate the alert Understand what happened Identify suspicious activity quickly Step 1: Parse Triage Artifacts (Event Logs + IIS Logs) We begin by creating a focused timeline  using only the most relevant artifacts. log2timeline.py --timezone 'EST' \ --parsers 'winevtx,winiis' \ --storage-file output.plaso \ /cases/IIS_Triage Why this matters: winevtx captures Windows event activity winiis captures HTTP requests, errors, and access patterns This keeps processing fast and noise low during early investigation Step 2: Add Full MFT Metadata Next, we append full filesystem metadata extracted using MFTEcmd. (If you want to learn how to create body file using mftecmd check out above articles) log2timeline.py --parsers 'mactime' \ --storage-file output.plaso \ /cases/IIS_mftecmd.body This step deserves special attention. Step 3: Filter and Build the Super Timeline Finally, we sort, filter, and export the timeline for analysis. psort.py --output-time-zone 'UTC' \ -o l2tcsv \ -w supertimeline.csv \ out.plaso \ "date > datetime('2023-01-01T00:00:00') AND date < datetime('2023-01-27T00:00:00')" This produces a filtered super timeline that: Focuses only on the incident window Is ready for tools like Timeline Explorer Can be quickly reviewed for attacker activity ------------------------------------------------------------------------------------------------------------- Case Study 2: Full Disk Super Timeline Scenario Now imagine a different situation. Instead of triage data, you have: A full disk image (E01, raw disk, or cloud snapshot) More time A need for deep historical analysis Your goal: Build a comprehensive super timeline Preserve complete file system metadata Still keep processing efficient Step 1: Parse Disk Image Using a Filter File log2timeline.py --timezone 'UTC' \ -f filter_windows.yaml \ --parsers 'win7,!filestat' \ --storage-file out.plaso \ /cases/cdrive/disk.E01 What’s happening here: win7 loads default Windows artifact parsers !filestat disables filesystem parsing (we’ll handle it separately) filter_windows.yaml  limits parsing to high-value system artifacts (This is an Filter file) https://github.com/log2timeline/plaso/tree/main/plaso/data Why not use Plaso’s filestat parser? Plaso’s filesystem parser only records metadata for files it actively parses .In this case, we parsed only logs , not the entire disk. By parsing the MFT separately with MFTEcmd and importing it using the mactime parser, we gain: Full file system visibility Creation, modification, access, and entry timestamps Metadata for files not directly parsed by Plaso This is a powerful technique when: You’re working with triage images Full disk images are unavailable or unnecessary Speed matters You’ll see this approach repeatedly in advanced investigations. This avoids wasting time on hundreds of thousands of irrelevant files. Step 2: Append Full MFT Metadata log2timeline.py --parsers 'mactime' \ --storage-file out.plaso \ /cases/mftecmd.body Even with a full disk image, we: Do not parse every file (thanks to the filter file) Still want c omplete filesystem visibility Appending the MFT provides: Full file coverage Accurate timestamps File size and metadata context Many Like me prefer MFTEcmd outpu t  over Plaso’s native filestat format for filesystem analysis. Step 3: Filter and Export the Timeline psort.py --output-time-zone 'UTC' \ -o l2tcsv \ -w supertimeline.csv \ out.plaso \ "date > datetime('2026-01-01T00:00:00') AND date < datetime('2026-01-27T00:00:00')" You now have a true super timeline combining: Logs Registry artifacts File system activity User actions System events All aligned chronologically. ------------------------------------------------------------------------------------------------------------- Key Takeaways Timelines are not one-size-fits-all Triage timelines prioritize speed and signal Full disk timelines prioritize depth and completeness Appending MFT data via MFTEcmd + mactime is an extremely effective technique Filter files help control noise without sacrificing context If there’s one thing to remember: A good timeline doesn’t show everything  — it shows the right things, in the right order. -------------------------------------------------------------------------------------------------------------

Last Article on Memory analysis using MemProcFS Cached Files in MemProcFS The Windows operating system caches a large number of files in memory. This includes: Frequently used system artifacts such as registry hives, Prefetch files, and the $MFT Memory-mapped files like executables and DLLs Recently accessed user files such as Word documents, PDFs, and log files Files opened from removable media (USB) or even encrypted containers All of these cached items are tracked in memory using data structures called File_Objects. Processes reference these File_Objects through: their process handle table their Virtual Address Descriptor (VAD) tree Memory forensics tools can enumerate these structures and use the embedded metadata to reconstruct and extract cached files. Cached File Recovery in MemProcFS In MemProcFS, cached files are exposed as individual files within the virtual filesystem. You can either: copy them out for offline analysis, or analyze them directly from the mounted drive. Cached files are represented under the files folder for each process, and MemProcFS provides three complementary method s  to recover them: 1. handles Recovers cached files by following process handles that reference File_Objects. 2. modules Recovers .exe, .dll, and .sys  files using: the Process Environment Block (PEB) PE header information 3. vads Attempts file reconstruction using VAD tree mappings , which is especially useful for memory-mapped files. Together, these three methods provide one of the most powerful and comprehensive cached-file recovery capabilities available in memory forensics tools. Forensic File Reconstruction (M:\forensic\files) When MemProcFS is run with forensic options enabled, it goes a step further. It: enumerates all recoverable File_Objects reconstructs them into a virtualized filesystem Instead of pivoting through a specific process, you can search globally using: M:\forensic\csv\files.csv You can then access recovered files via: M:\forensic\files\ROOT\ These files can be: copied out opened directly (hex editor, Office apps, image viewers, etc.) I mporta nt caveat : Memory is not guaranteed to be complete. Files may be: partially paged out corrupted or incomplete Viewers that tolerate corruption are preferred. NTFS Forensics from Memory The M:\forensic\ntfs folder allows analysts to investigate the entire file system structure. Behind the scenes, MemProcFS: locates the NTFS Master File Table ($MFT) virtualizes it into a browsable file hierarchy This lets you explore the file system as it existed on the original machine , even from memory alone. Timeline Analysis MemProcFS also generates timelines: Text timelines: M:\forensic\timeline\ CSV timelines: M:\forensic\csv\ The timeline_ntfs.csv  file contains file system events, while other timelines focus on different in-memory artifacts. CSV timelines can be immediately opened in tools like Timeline Explorer for filtering and correlation. Registry Artifacts from Memory The M:\registry  folder exposes memory-resident registry data. You can: browse keys and values directly export reconstructed hives from: M:\registry\hive_files Exported hives are often partial or corrupted, so direct navigation is frequently the better option. Services and Scheduled Tasks Services and scheduled tasks are heavily abused by attackers for: persistence execution lateral movement MemProcFS exposes this data in two ways: Virtualized View M:\sys\services M:\sys\tasks CSV View M:\forensic\csv\ These views include: start type (AUTO_START is commonly abused) full executable paths and arguments timestamps associated users Pro Tip Most services and tasks should run under system accounts . Anything running under a user context  deserves closer inspection. ------------------------------------------------------------------------------------------------------------ Final Thoughts Being able to extract: cached files NTFS metadata registry keys services and tasks directly from memory  can be a game changer during investigations. ------------------------------------------------Dean-------------------------------------------------------- MemProcFS turns memory analysis from a purely command-line exercise into an interactive forensic workflow, dramatically reducing investigation time and increasing visibility. Don't forget to check out complete Memory forensic Series Link below https://www.cyberengage.org/courses-1/mastering-memory-forensics%3A-in-depth-analysis-with-volatility-and-advanced-tools

One of the most exciting upgrades to MemProcFS is the native integration of YARA signature scanning. By combining the power of YARA-based detection with deep memory inspection, MemProcFS makes it surprisingly easy to detect even highly stealthy malware variants. When enabled, YARA hits are surfaced a t the very top of the FindEvil output, which is exactly where they belong—since these detections often act as the starting point for deeper analysis. Expanded Coverage: Processes and  File Objects Initially, YARA scanning focused on process memory, but it has now expanded to include file objects as well. This significantly improves detection of threats such as: Malicious loaded drivers Vulnerable or abused kernel drivers File-backed malware hiding in memory Enabling YARA Scanning in MemProcFS MemProcFS with the Elastic Security open-source YARA ruleset, which contains 1,000+ high-quality rules capable of detecting multiple variants of some of the most common malware families seen in the wild. To use these rules, you must accept the Elastic license: MemProcFS.exe -device <.img> -forensic 1 -license-accept-elastic-license-2-0 Important: Enabling YARA scanning will delay the availability of forensic results. This is expected—YARA scanning is resource-intensive, especially on large memory images. Be patient; results typically appear after several minutes. Understanding YARA Output in MemProcFS Once scanning completes, YARA results are integrated directly into the forensic output: Primary results: M:\forensic\csv\findevil.csv Detailed YARA output: M:\forensic\csv\yara.csv Within findevil.csv, YARA detections appear under multiple YR_* categories. Each hit includes a description pulled directly from the YARA rule , which is extremely useful when: Investigating false positives Reviewing how a rule works Searching for rule context online Each hit is cross-referenced using an index number  (e.g., [0]) that maps directly to detailed entries in yara.csv. When “Too Many Hits” Is Actually Normal You may sometimes see an unexpectedly high number of YARA hits for a single process. This is completely normal. Antivirus and security tools often match against malware signatures by design. For this reason, some processes—such as MsMpEng.exe (Microsoft Defender)—are excluded by default. Using Your Own YARA Rules If you prefer to use a custom YARA ruleset, MemProcFS supports this via: -forensic-yara-rules You can point it to: A single YARA rule A YARA rule index file Custom rule results are stored separately in: M:\forensic\yara\ Key files include: match-count.txt  – total number of matches result.txt  – detailed hit information (including process context) What Comes After Detection? Finding suspicious memory regions naturally raises the question: “What do I do next?” Because false positives are common at the memory level, further validation is often required. That said, sometimes the evidence speaks for itself. For example: svchost.exe running from the wrong directory Incorrect parent process Clear signs of process hollowing In cases like this, you may already have enough proof of compromise. When deeper analysis is required, memory forensics truly shines—allowing you to investigate far beyond what traditional endpoint tools can provide. Dumping and Recovering Suspicious Memory As you investigate, document everything, including: Process names and PIDs Virtual memory addresses VAD path information MemProcFS conveniently includes all of this in the findevil output. To recover suspicious artifacts: Navigate into the process directory Open the files folder Review subfolders created from: Handles Loaded modules (EXEs, DLLs, drivers) Extracted VAD pages Investigating Injected Code The vmemd folder is especially valuable when dealing with injected shellcode or memory-only payloads. Files here appear as: *.vvmem These memory segments can be: Copied out for offline analysis Opened directly in a hex editor Your goal is to locate memory regions matching suspicious virtual addresses or object names—such as a previously identified hollowed DLL. Handling False Positives Like a Pro Memory forensics is never simple. Some activity looks malicious but is completely normal, while real malware often tries to blend in. MemProcFS findevil output—much like Volatility’s malfind—can generate many false positives. A classic example is PE_PATCHED , which is notorious for false alerts due to: .NET Just-In-Time (JIT) compilation Runtime code modifications Web browsers and PowerShell behavior SysWOW64 (32-bit) components on 64-bit systems Processes such as: PowerShell Outlook Browsers msiexec.exe should always be reviewed carefully—but not blindly assumed malicious. ******************************************************************************************************************** Baseline Is Everything One of the best practices in memory forensics is to run tools like malfind and findevil against a known-good baseline image. This helps you understand what “normal” looks like for a given OS version and dramatically reduces investigation time during real incidents.' ******************************************************************************************************************** Before We Continue: Important Note on Memory Object Extraction Before we jump into the next part, there’s an important note. The next topic focuses on extracting memory objects , and I’ve already written a dedicated article on this: “Extracting Memory Objects with MemProcFS / Volatility 3 / Bstrings: A Practical Guide” If you’re interested in a comparison across tools, feel free to check out that article using the link below. https://www.cyberengage.org/post/extracting-memory-objects-with-memprocfs-volatility3-bstrings-a-practical-guide However, in this series we’re focusing purely on MemProcFS. That means some concepts will be repeated. But honestly—revisiting fundamentals isn’t a bad thing at all (learning twice never hurts 😄). Extracting Memory Objects in MemProcFS MemProcFS makes memory object extraction extremely straightforward. Memory objects are exposed as individual files inside a virtual filesystem , allowing you to either: copy them out for offline analysis, or analyze them directly in place. The biggest challenge is not extraction itself—it’s knowing where to look. Common Memory Object Locations in MemProcFS Paths: M:\\vmemd M:\\heaps M:\\minidump\minidump.dmp Executables and DLLs < Image-mapped memory> M:\\modules\\pefile.dll M:\\files\ (modules | vads) Drivers M:\name\System-4\modules\\pefile.dll Cached and Forensic Files M:\forensic\files M:\forensic\ntfs Registry, Services, and Tasks M:\registry M:\sys\services M:\sys\tasks Understanding the Process Folder Structure Most process-related artifacts live under the process directory, which can be accessed by: Process name: M:\name\Move Mouse.exe-16032\ PID: M:\pid\16032 Both paths are cross-linked and contain identical data. Once inside a process folder, you’ll find several key subfolders: vmemd : Useful for tracking specific memory regions (for example, those flagged by FindEvil). heaps : A powerful location for searching private memory heaps, where processes store most of their runtime data. minidump : Provides a compact but practical view of process memory, including stack, heap, executable, and loaded DLLs. modules : Contains loaded DLLs and the process executable, each represented as a pefile.dll Why MemProcFS Is So Powerful for Extraction One of the most unique aspects of MemProcFS is that it virtualizes memory into a navigable filesystem. This means you can: open memory sections in a hex editor, extract strings directly, upload hashes or files to VirusTotal, load DLLs into disassemblers, or run static analysis tools like PEStudio. In many cases, you don’t even need to copy the file out. That said, when running antivirus scans, it’s often safer to make a local copy to avoid quarantine issues. If a tool fails to open a MemProcFS virtual file, a good troubleshooting step is to copy it locally and retry. Executables, DLLs, and Drivers in Memory Executable-related artifacts appear in multiple locations, but the closest representation of a PE file is: pefile.dll You’ll find this under the modules folder of the owning process. Keep in mind: Memory-loaded executables will never be bit-for-bit identical  to their on-disk versions. Modifications during load time are normal. If you don’t see a process under M:\name or M:\pid, it may have already exited. You can force MemProcFS to build folders for terminated processes by setting: M:\config\config_process_show_terminated.txt = 1 This is disabled by default because exited processes may have incomplete or corrupted data. Extracting Drivers Most drivers run under the System  process. You’ll find them here: M:\name\System-4\modules\ or M:\pid\4\modules\ Each driver folder contains a pefile.dll representing the driver in memory. Some graphics-related drivers (Win32k) may appear under csrss.exe, but these are rarely useful in investigations. Process Code vs Process Data Process memory generally falls into two broad categories: 1. Code This closely resembles the original executable and loaded modules. Volatility: windows.pslist --dump MemProcFS: M:\\modules\\pefile.dll This is useful for: IOC generation reverse engineering validating legitimate vs malicious code 2. Data This includes: heaps stacks private memory injected buffers runtime artifacts This is where you may find: command lines typed input PowerShell scripts malware configuration data DGA output MemProcFS Memory Dump Options MemProcFS provides several representations: pefile.dll  – closest PE-style reconstruction memory.vmem  – represents all  possible process address space (often enormous and impractical) minidump.dmp  – the most usable option for quick analysis The minidump  contains: stack heap executable loaded DLLs …but it misses many private memory regions. It’s ideal for a first pass, while Volatility’s memmap remains the better choice for exhaustive analysis. --------------------------------------------------------------------------------------------------------- “Thanks for reading, and join me in the next article as we continue this journey.” -------------------------------------------------------Dean-------------------------------------------- Happy new year to everyone!!, See ya next year