Search Results

In this new series, we'll be diving deep into investigation and forensics within Google Workspace (the Google ecosystem). So tighten your seatbelt—let's go! When diving into cloud forensics—especially in Google Workspace—there’s a lot more to unravel than just user credentials or login timestamps. One of the most overlooked but crucial areas  is how permissions  are managed within the environment. let's break down two key building blocks of Google Workspace that matter a lot  when you're investigating suspicious account behavior or responding to an incident: 👉 Organizational Units (OUs) 👉 Groups Why OUs and Groups Matter in Forensics Google Workspace has its own authentication and identity system, sure—but when you're trying to understand how  and why  a user had access to certain data or features, you need to look beyond just login logs. That’s where Organizational Units (OUs)  and Groups  come in. T hese two are the backbone of how permissions are structured and managed in Workspace. And guess what? They can be used independently , so knowing how each works is essential for tracing how permissions are applied—or misapplied. ---------------------------------------------------------------------------------------------------------- Organizational Units (OUs): Think Department Bins Let’s start with Organizational Units . Think of them like folders or containers that you put users into based on department, location, or job role. Every user account must belong to one—and only one—OU. From an investigation perspective, this helps narrow things down: If you know the user’s OU, you don’t have to search other units. Also, OUs can be nested —meaning you can have child units inside parent ones. So a user could be in a sub-OU deep in the hierarchy, but they’ll still inherit permissions from the OUs above them. T his inheritance  is something to watch closely during an investigation. Forensic Tip: OU Inheritance Can Create Hidden Access If a user is in a deeply nested OU, don’t forget to trace all the inherited settings and permissions. You might find that access was granted not directly , but from higher up the chain ---------------------------------------------------------------------------------------------------------- One User, Many Groups — And Even More Permissions Unlike OUs where a user can only belong to one , a single u ser account in Google Workspace can be part of multiple groups  at the same time. But here’s where things get interesting—and complicated: Groups can contain other groups. So if User A is in Group X, and Group X is inside Group Y, then User A indirectly inherits all permissions from Group Y too. This is what we call inherited groups , and it’s an important concept for anyone doing incident response or auditing permissions. Forensic Insight: Inherited Groups = Inherited Risk Let’s say you have a group called "IT Users" . It’s a member of both the "Log Access"  and "Vault Access"  groups. That means everyone in IT Users also inherits access to logs and vault data—even if that wasn’t the original intention. This kind of setup is handy for streamlining permissions—but it can also accidentally over-provision users , which is something DFIR teams always need to watch out for. Using Groups Smartly Groups aren’t just for permissions. You can also use them for: Feature access control Mailing lists Managing shared resources (like calendars, drives, etc.) Think of it like Microsoft’s Security Groups and Distribution Groups in Active Directory. In large organizations, using groups makes onboarding and permissioning way easier . You can just drop a new user into the right group and boom—they’ve got the correct access in seconds. But this simplicity can be dangerous if you don’t track what each group actually allows . Real-World Use: Google Drive Sharing Groups Imagine this : You’ve got three groups set up for Google Drive sharing: Internal Sharing Only Sharing to Trusted Domains Open Sharing (Anyone outside the org) During a data breach, it’s so much easier  to identify which group allowed risky sharing if these types of groups are clearly defined. You could simply yank a user out of the “Open Sharing” group, and the exfiltration risk goes down instantly . This logic applies not just to Drive—but to all services in Google Workspace. Group Roles: Owner, Manager, Member Every group in Workspace has three roles : Owner : Full control—can add/remove members, change settings, etc. Manager : Can manage members, sometimes limited in changing settings Member : Just a regular part of the group Forensics Tip: The group owner isn’t always an IT admin . It could be a team lead, project manager, or anyone else. That means non-IT staff could be controlling access to sensitive groups , so always check who owns what . Using Admin Console to Inspect Groups Google makes it a bit easier to investigate with features like Inspect Groups , available in the Admin Console. With this, you can: See all groups assigned to a user Know whether group membership is direct  or inherited Check which users belong to a specific group For example:You might find that Akash is directly added to the “Vault Access” group but indirectly added to the “IT Users” group through another group membership. That tells you how permissions were layered  onto Akash's account. Feature Alert: Only in Enterprise Plus or Cloud Identity Premium Here’s the catch: This level of detail—especially Inspect Groups  and dynamic visibility—requires either: Enterprise Plus edition of Google Workspace , or The Cloud Identity Premium Edition add-on If you’re in a budget-conscious environment, the add-on  gives you solid forensic capabilities without needing the full Enterprise tier . ---------------------------------------------------------------------------------------------------------- Final Thoughts: Groups = Power and Risk Groups are incredibly powerful, but also easy to overlook during forensic reviews. Always: Map direct vs inherited  permissions Watch for non-admin group owners Audit who’s in which group  and why Use features like Inspect Groups  if your license supports it Getting this right can help you detect, contain, and respond to incidents faster and smarter . ----------------------------------------------Dean----------------------------------------------------- Stay with me—things are going to get more interesting in the upcoming articles!

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

If you’ve been following my Memory Analysis series, you may remember that I previously covered the initial investigation steps in detail in the article: “Step-by-Step Guide to Uncovering Threats with Volatility: A Beginner’s Memory Forensics Walkthrough” https://www.cyberengage.org/post/step-by-step-guide-to-uncovering-threats-with-volatility-a-beginner-s-memory-forensics-walkthrough Volatility is one of my favorite memory forensics tools. I genuinely love working with it—it makes complex investigations much easier and provides incredible visibility into system memory. However, Volatility is not the only powerful tool available. Another tool I frequently use and really enjoy is MemProcFS. It’s an excellent memory forensics framework that approaches investigations in a more interactive and intuitive way by exposing memory artifacts through a virtual file system. So, rather than repeating the Volatility workflow: If you want to learn or revisit memory investigation using Volatility , I recommend checking out the article linked above. If you want to see how to perform a similar investigation using MemProcFS , stay with me—I’ll guide you through it step by step. Before we begin, if you’re not familiar with MemProcFS or MemProcFS Analyzer, I strongly recommend reading the following article first: 👉 https://www.cyberengage.org/post/memprocfs-memprocfs-analyzer-comprehensive-analysis-guide With that covered, let’s get started. MemProcFS Overview MemProcFS dynamically performs symbol table lookups from Microsoft servers to correctly identify the memory image profile. For best results, it’s recommended to use a system with active Internet connectivity. The -device argument specifies the path to the memory image. MemProcFS.exe -device C:\Users\Akash\Downloads\laptop.raw -forensic 1 -license-accept-elastic-license-2.0 Optionally, you can also provide paths to pagefile.sys and swapfile.sys using the -pagefile[0|1] parameters. This is considered a best practice, as MemProcFS supports pagefile parsing and can decompress compressed memory regions, which are common in Windows 10 and Windows 11 systems. These capabilities are particularly impressive and are one of the main reasons MemProcFS often extracts more forensic artifacts from memory than many other tools. On Windows systems, the default mount point is the M:  drive. This can be changed using the -mount option, which is also required when running MemProcFS on Linux to specify a mount path. An additional useful option is -forensic. This flag automatically triggers forensic plugins such as: findevil ntfs timeline While these plugins are more resource-intensive, they often complete faster than expected and immediately generate valuable forensic data. Once MemProcFS is running, keep the terminal open and navigate to the mounted drive to begin analysis. Exploring Processes with MemProcFS Once mounted, analyzing memory artifacts is as simple as browsing a file system. For example, process information can be reviewed via: M:\sys\proc\proc.txt This file provides a parent/child process tree view , similar to the windows.pstree output in Volatility. In addition to familiar information, MemProcFS includes extra details such as: The user account  running the process A flag column  indicating potential anomalies Common Process Flags 32  – 32-bit process running on a 64-bit system E  – Process not found in the EPROCESS list (possible unlinking or memory corruption) T  – Terminated process U  – User-level (non-system) process *  – Process running from a non-standard path You’ll often notice multiple output files in directories of interest. For instance, proc-v.txt provides a more verbose process listing, including full paths and command-line arguments While this format is slightly harder to read as a tree, it’s extremely valuable for deeper analysis. Processes can also be investigated directly by name or PID , which we’ll look at shortly. Deep-Diving into a Process Unlike Volatility, which relies on separate plugins to extract process details, MemProcFS consolidates all related artifacts into structured folders. For example, after identifying a suspicious process named Move Mouse.exe with PID 16032 , we can navigate to: M:\name\Move Mouse.exe-16032 Within this directory: win-cmdline.txt shows the full command line from the process PEB The token folder provides information about the security context and privileges The handles folder lists open handles The modules folder contains loaded DLLs and the process image As you explore these directories, you’ll not only see metadata but often reconstructed artifacts themselves. For instance, each DLL folder under modules includes a pefile.dll file, which attempts to reconstruct the original DLL directly from memory. These files can be opened in a hex editor, disassembler, or submitted to a sandbox for further analysis. Network Artifact Analysis Identifying network activity using MemProcFS is equally straightforward. Under: M:\sys\net you’ll find: netstat.txt – traditional network connection view netstat-v.txt – extended view with full process paths Since these are plain text files, they’re easy to search and filter. For example, you can quickly scan for known malicious IP addresses or suspicious process names using standard command-line tools like grep. ------------------------------------------------------------------------------------------------------------- Now that we understand process memory layout and behavior, we can move on to one of the most important stages of memory analysis: Identifying code injection artifacts using MemProcFS. MemProcFS currently centralizes its detection logic into a single, powerful plugin called findevil. This plugin is not enabled by default and must be activated in one of the following ways: Launch MemProcFS with the -forensic command-line argument, or -forensic 1 -license-accept-elastic-license-2.0 Write the value 1 into the file: M:\forensic\forensic_enable.txt It’s important to note that findevil only works on Windows 10 and newer systems , as this limitation helps reduce false positives caused by older memory management behaviors. Once enabled, MemProcFS generates a report at: M:\forensic\findevil.txt This report flags suspicious memory locations using a set of well-defined indicators, which we’ll break down below. Process-Level Anomaly Detections The first group of findevil detections focuses on process irregularities, many of which should already feel familiar from earlier stages of memory analysis: PROC_NOLINK : Indicates a process that is missing from the EPROCESS doubly-linked list. This may be caused by normal termination, memory corruption, or malicious unlinking (DKOM). PROC_PARENT : Flags deviations from expected parent-child relationships for known system processes. PROC_USER : Detects system-named processes running under incorrect or unexpected user tokens. These flags help establish early suspicion  before diving deeper into memory-page analysis. Memory Page Injection Indicators The next—and arguably most powerful—set of detections focuses on suspicious memory page properties. Understanding how Windows maps memory is crucial for interpreting these flags correctly. PE_INJECT : What it means: A memory region contains a valid PE header (EXE or DLL), but was not loaded from disk. NOIMAGE_RWX : RWX memory pages that are not  backed by image-mapped files. What it means: Memory pages have Read + Write + Execute permissions AND They are not backed by an image file Why this is bad: Legitimate code should never be RWX RWX memory allows: Writing shellcode Executing it immediately NOIMAGE_RX : RX memory pages outside image-mapped memory. What it means: Memory pages are Executable (RX) but not image-mapped Why suspicious: Code is executing But it didn’t come from a loaded EXE or DLL Less severe than RWX, but still suspicious: Malware may write code, then change permissions to RX Used to evade RWX detection PRIVATE_RWX : RWX permissions inside private memory regions (heap or stack). What it means: RWX memory inside private memory(heap or stack) Why this matters: Heap/stack are meant for data, not code RWX heap/stack almost always indicates: Shellcode execution Exploit payloads Memory injection PRIVATE_RX : RX permissions inside private memory. What it means: Executable memory (RX)inside private memory (heap or stack) Why suspicious: Code running from heap/stack is abnormal Often used after: Shellcode is written Permissions changed from RW → RX ------------------------------------------------------------------------------------------------------------ Indicator Executable Writable Image-Mapped Risk PE_INJECT ✅ varies ❌ High NOIMAGE_RWX ✅ ✅ ❌ Very High NOIMAGE_RX ✅ ❌ ❌ High PRIVATE_RWX ✅ ✅ ❌ Very High PRIVATE_RX ✅ ❌ ❌ Medium–High ------------------------------------------------------------------------------------------------------------ These detections are extremely valuable because injecting code is easy, but placing it correctly with legitimate characteristics is very hard. As a result, multiple detections often trigger on the same malicious memory region. For example: A PE header (MZ) located in an RX page outside image-mapped memory would trigger both PE_INJECT and NOIMAGE_RX. While false positives still exist, these detections represent a major improvement over Volatility’s malfind, particularly when layered together. Detection of Manipulated Memory Structures Beyond raw injection detection, findevil also identifies manipulated memory structures, which are often used in more advanced attacks. PEB_MASQ : Detects Process Environment Block masquerading, where malware alters the process name or file path in the PEB. PE_NOLINK : Identifies DLLs with valid PE headers present in the VAD but missing from the PEB module lists—very similar in concept to Volatility’s ldrmodules. While false positives exist, including pagefile data significantly reduces noise. PE_PATCHED : Flags executable pages that were modified after being loaded. This is common in: Advanced process hollowing AMSI bypasses In-memory patching This detection relies on page table entries (PTEs)—specifically prototype PTEs—which track modified image pages. While extremely powerful, this detection can be noisy on systems using: SysWOW64 (32-bit code on 64-bit systems) JIT compilers (e.g., .NET and PowerShell) Expect noise—but also expect ground-truth accuracy. ------------------------------------------------------------------------------------------------------------ What’s Next? In the next article, we’ll continue: Stay tuned—this is where the investigation gets really interesting

Modern Windows rootkits assume that analysts will: enumerate drivers using linked lists trust Windows APIs rely on “normal” system views Volatility 3’s windows.drivermodule plugin was built specifically to break that assumption. What windows.drivermodule Actually Does This plugin performs cross-view analysis for drivers , similar in spirit to: psxview → processes svcdiff → services But focused entirely on kernel drivers . Step 1: Memory Scanning Scans memory for structures associated with: DRIVER_OBJECT related kernel metadata This is a ground truth scan, independent of Windows-maintained lists Step 2: Linked-List Enumeration Enumerates drivers via: the kernel linked list used by Windows APIs This is what the OS claims  is loaded Step 3: Cross-Comparison Compares: scanned driver objects API-visible drivers Any mismatch is flagged If memory says a driver exists but Windows denies it → rootkit territory Metadata Anomaly Detection Rootkits don’t just unlink drivers — they tamper with metadata to frustrate analysis. The plugin checks for anomalies such as: Base address = 0x0 Image size = 0 bytes Missing or inconsistent path information Why Rootkits Do This Makes dumping harder Breaks naïve tools Confuses analysts looking for valid PE structures Ironically, these manipulations make the driver more suspicious, not less. Known Exceptions vs Real Red Flags Some legitimate Windows components: behave oddly violate “normal” expectations would otherwise cause false positives The plugin accounts for this by: maintaining a list of known exceptions marking them explicitly How to Interpret the Output Known Exception = True Likely benign Still reviewable, but lower priority Known Exception = False Not explained by normal OS behavior High-confidence rootkit indicator Must be investigated This dramatically reduces analyst noise. Why This Plugin Is So Effective Andrew Case (Volatility core developer) demonstrated that: windows.drivermodule detected every modern Windows rootkit sample they tested even samples that: successfully hid from driver lists avoided traditional modscan detection manipulated metadata to evade dumping This makes it one of the strongest rootkit detection plugins in Volatility 3. ----------------------------------------------------------------------------------------------------- Hidden Services: The Other Half of the Story Kernel drivers rarely load themselves magically. They are commonly loaded via: Windows Services set to: auto-start boot-start system-start Rootkits often hide both: the driver the service that loads it windows.svcdiff — Detecting Hidden Services The windows.svcdiff plugin performs cross-view analysis for services, similar to psxview and drivermodule. How It Works It compares: services listed by: services.exe (what Windows reports) services discovered via: memory scanning What It Finds services that: exist in memory are not visible to the OS are likely unlinked or hidden These hidden services are frequently: used to load malicious drivers responsible for persistence part of kernel rootkit infrastructure ------------------------------------------------------------------------------------- Putting It All Together: Rootkit Detection Workflow A practical Volatility 3 rootkit triage looks like this: windows.psxview Look for hidden processes windows.drivermodule Identify hidden or metadata-manipulated drivers windows.svcdiff Find hidden services used for persistence windows.ssdt Check for hooks pointing into suspicious drivers windows.modules / windows.modscan Correlate linked vs scanned driver data Dump and analyze Extract drivers and services for deeper analysis Each plugin reinforces the others. ------------------------------------------------------------------------------------ Why Cross-View Analysis Is So Powerful Rootkits can: hide from one view manipulate one data structure But hiding consistently from: linked lists memory scans metadata checks service tables …is extremely difficult. Volatility’s philosophy is: “Trust nothing. Compare everything.” ------------------------------------------------------------------------------------------ Key Takeaways windows.drivermodule is purpose-built for modern Windows rootkits It detects: hidden drivers unlinked drivers metadata manipulation Known exceptions are filtered for you Unknown discrepancies are high-value findings Rootkits often rely on hidden services , detectable via windows.svcdiff Cross-view analysis remains one of the most reliable rootkit detection techniques ------------------------------------Dean---------------------------------------------------

Drivers are the cleanest way for malware to own a Windows system. Once malicious code executes as a driver: it runs in kernel mode it can hook system calls it can hide processes, files, and registry keys it can tamper with security tools This is why rootkits almost always involve drivers. How Windows Tracks Drivers Windows maintains multiple views of loaded drivers, just like it does with processes. Rootkits exploit this. 1. The Linked List (Normal View) Tracks currently loaded drivers Used by: OS components administrative tools many security products 2. Raw Memory (Reality View) Driver code and data may still exist in memory: even if unlinked even if unloaded even if hidden via DKOM Volatility gives us tools for both perspectives . Key Volatility Plugins for Driver Analysis modules (Volatility 2) / windows.modules (Volatility 3) Reads the official kernel linked list of loaded drivers Shows: driver name base address size file path (if available) This is your high-level, trusted view  — and therefore the first thing rootkits lie to . If a driver is not here, it does not  mean it was never loaded. modscan (Volatility 2) / windows.modscan (Volatility 3) Scans memory for: driver pool tags remnants of DRIVER_OBJECT structures Can find: hidden drivers unlinked drivers unloaded drivers partially overwritten drivers This is the low-level truth . If something appears in modscan but not modules: strong rootkit indicator Why modscan Is Critical Modern rootkits: unlink their drivers from the kernel list overwrite list pointers erase file-backed references But: pool memory still contains artifacts code pages still exist data structures are rarely perfectly cleaned modscan catches what modules misses. windows.devicetree — Seeing Driver Relationships The devicetree plugin provides a structural view: how drivers are layered which drivers attach to which devices unexpected filters or middlemen This is especially useful for: keyboard filter rootkits disk filter rootkits network stack manipulation Unexpected drivers in the middle of known driver chains are highly suspicious. Driver Analysis Should Never Be Done Alone Kernel rootkits rarely stop at “just being loaded.” They usually: hook SSDT hook IRP handlers register callbacks manipulate processes and registry So the real power comes from correlation: suspicious driver in modscan SSDT entries pointing into that driver hidden processes revealed via psxview These findings reinforce each other. -------------------------------------------------------------------------------------------- Narrowing Down Suspicious Drivers When faced with hundreds of drivers: 1. Known-Good Comparison Compare against: a clean system same OS version and patch level Use projects like: Vanilla Windows Reference  (Andrew Rathbun) ( https://github.com/AndrewRathbun/VanillaWindowsReference ) This quickly eliminates the noise. 2. Reputable Research Search only reliable sources: Microsoft documentation vendor driver references well-known malware research blogs Ignore forums and random blog posts. 3. Dump and Analyze If doubt remains: extract the driver scan with: AV engines known IOCs perform: static analysis reverse engineering Dumping a Suspicious Driver Once identified: Volatility 2 moddump -b -D output_dir Volatility 3 windows.modules --dump This allows: string analysis signature checks RE IOC extraction What To Do After Finding a Malicious Driver Don’t stop at identification. Next steps: search SSDT for hooks into the driver look for callbacks registered by it identify persistence mechanisms: services registry entries boot loaders correlate with: hidden processes network artifacts filesystem anomalies The driver is the control center . -------------------------------------------------------------------------------------------- Key Takeaways Kernel drivers = rootkit backbone modules shows what Windows admits modscan shows what memory remembers Differences between them matter Known-good baselining is incredibly powerful Rootkits rarely clean up perfectly Correlation beats single-plugin analysis every time -------------------------------------Dean---------------------------------------------

If SSDT hooking shows you how rootkits control behavior psxview shows you how they hide existence. This plugin is one of the most important tools for rootkit detection in memory. What psxview Really Does psxview is a compound plugin. It doesn’t invent new data — it compares existing views of processes gathered using different kernel mechanisms . Why this matters: Windows tracks processes in multiple places : linked lists PID tables thread structures user-session data desktop objects A rootkit can hide from one of these. Hiding from all of them is extremely difficult. This is the core idea behind cross-view analysis. Cross-View Analysis Cross-view analysis means: Ask Windows for process information the normal way  (high-level) Independently discover processes using low-level structures Compare the results If something exists in one view but not another: someone is lying Rootkits usually lie to the high-level views. What psxview Compares psxview runs multiple plugins and builds a comparison table. Here’s what each source represents: High-Level View pslist Reads the active process doubly linked list Easiest place for DKOM rootkits to hide This is your baseline “normal” view Low-Level & Alternate Views psscan Scans memory for raw EPROCESS structures Finds terminated, hidden, and orphaned processes thrdproc(scan) Reconstructs processes via thread parent PIDs Very hard to fully clean up pspcid Uses the kernel PspCid table (PID tracking) Another place attackers forget to clean csrss csrss.exe holds handles to user processes Only valid for processes started after  csrss session Groups processes by logon session deskthrd Maps processes via desktop-attached threads How to Read psxview Output Each process gets a row. Each detection method gets a column. True  → process found via that method False  → process not found via that method What you’re looking for: Inconsistencies Especially: False in pslist True everywhere else That’s rootkit territory. Legitimate “False” Values Not every False means malware. Some examples that are expected behavior: System , smss.exe, csrss.exe Started before csrss tracking exists Will show False under csrss, session, deskthrd Terminated processes psscan may find leftover EPROCESS structures Other views show no references Real-World Example: FU Rootkit The FU rootkit uses Direct Kernel Object Manipulation (DKOM). Instead of hooking functions, it: removes its process from the active process list leaves the process alive elsewhere in memory psxview Findings Plugin Result pslist ❌ False psscan ✅ True thrdproc ✅ True pspcid ✅ True csrss ✅ True This is textbook DKOM behavior. pslist — the high-level view — has been manipulated. Low-level structures still know the process exists. That discrepancy is the detection. Why pslist Is the “Canary” pslist is the easiest place to hide. So your rule of thumb: If a process does not appear in pslist but appears elsewhere, investigate immediately. This is how most rootkit detections start. False Positive Example You’ll often see something like: psscan → True everything else → False Example: csrss.exe This usually means: process exited cleanly EPROCESS still present in memory no active references remain This is not malware — just memory artifacts. The Important Question If psscan already finds hidden processes, why do we need psxview? Because context matters. Without cross-view comparison: you might assume the process is legitimate you might miss that it was hidden from pslist you lose the evidence of DKOM manipulation psxview doesn’t just find processes —it tells you which kernel view was tampered with. That’s critical for attribution and reporting. Key Takeaways psxview is a rootkit detector, not a process lister Inconsistencies matter more than presence pslist = high-level truth psscan = raw reality ---------------------------------------Dean--------------------------------------------