A while back I wrote about how Windows uses Alternate Data Streams to tag files downloaded from the internet — that Zone.Identifier trick that quietly labels your files as "came from the web." A lot of people found it interesting because it's one of those Windows features that silently runs in the background and most users never think about. But here's the thing about ADS that I didn't cover in that article, and honestly it's the part that should make defenders a little nervous: the exact same feature that Microsoft uses to label your downloads? Attackers use it to hide malware . And they've been doing it for years, targeting major organizations, hiding ransomware payloads, and evading security tools — all inside a feature built right into Windows. So if you read the first article and thought "huh, cool Windows feature" — this one's the darker chapter. Let's talk about how attackers actually weaponize ADS. Section 1 — Quick Recap: What Is ADS Again? Quick refresher before we get into the attack stuff. Every file on an NTFS volume (which is basically every modern Windows system) can carry more than one "stream" of data. You have the main data stream — that's the file content you normally see and interact with. But NTFS allows additional streams to be attached to the same file, hidden under a colon syntax like this: filename.txt:hiddenstream Most Windows applications, Windows Explorer, and a lot of security tools only look at the primary data stream. The hidden streams? Completely invisible to them. You can't see their size in Explorer, they don't show up in a normal DIR listing, and they travel with the file if you copy it on NTFS. That last part is key. Zone.Identifier is the legitimate example — Windows writes it automatically when you download a file. But the exact same mechanism works for an attacker who wants to tuck a malicious executable inside what looks like a completely harmless text file. MITRE ATT&CK tracks this as T1564.004 — Hide Artifacts: NTFS File Attributes. Section 2 — Four Ways Attackers Actually Use This So how does this actually show up in real attacks? There are four main things attackers do with ADS, and they often chain them together in the same campaign. Here's how each one works in practice. Section 3 — Executing Payloads with Windows' Own Tools (LOLBAS) This is where it gets really uncomfortable for defenders. Hiding a file in an ADS is one thing — but attackers don't even need a separate dropper to execute it. Windows ships with a long list of native binaries that will happily run content directly from an alternate data stream. The LOLBAS project (Living Off the Land Binaries and Scripts) documented a whole category of these, and it's a wild read. The idea of LOLBAS is simple: if you can make a legitimate, signed Windows tool do your dirty work, you blend in perfectly. No sketchy executables, no unsigned code. Just Windows doing what Windows does — except the attacker is the one pulling the strings. The classic example is rundll32.exe. This is the standard Windows utility for loading DLL files. Normally harmless. But if you point it at an ADS path, it'll execute whatever DLL is hiding in that stream — and to most security tools, all they'll see is rundll32 running, which is totally normal. Same story with wscript, certutil, bitsadmin, and others. They all have documented capability to interact with ADS. Section 4 — Real Malware That Did This This isn't theoretical. MITRE ATT&CK lists over a dozen named malware families that used ADS in real campaigns. Here are three of the most well-known examples — and they're a good reminder that this technique has been used by everyone from sophisticated APTs to big ransomware operations. Section 5 — Okay, How Do We Actually Find These? So now that we know what's possible, the obvious question is: how do defenders catch this? The good news is there are several ways to detect ADS abuse, both on live systems and during forensic analysis. The key is knowing where to look — because default Windows tooling doesn't make it easy. The two built-in Windows commands that surface ADS data are dir /r in CMD, and Get-Item with the -Stream parameter in PowerShell. These will show you streams you wouldn't normally see. For forensic analysis , Sysinternals Streams.exe is the go-to tool for getting a clean list of non-standard streams across a directory. On the detection and hunting side, MITRE's CAR analytics and tools like Sysmon give you command-line argument visibility — which is where ADS execution leaves its traces. When rundll32 or wscript get called with a path containing a colon followed by a stream name, that's your indicator. Normal legitimate calls to these tools don't look like that. Conclusion The thing that makes ADS such an effective attacker technique is the same thing that made Zone.Identifier interesting in the first article — it's hidden in plain sight. The file is right there on the filesystem . You can see it, you can open it, everything looks normal. The malicious content is just... attached to it in a place most people never think to look. The good news is that with the right tooling — Sysmon, EDR with command-line visibility, or forensic tools that parse the MFT properly — ADS abuse leaves traces. But the bigger takeaway is this: the security gap here isn't really technical — it's awareness. Most security teams know about ADS, but how many have actually tuned their detection rules for it? How many have checked whether their EDR surfaces ADS execution events? I f the answer is "not sure," that's worth a few hours of your time to find out. Because if ransomware groups like ALPHV and WastedLocker are using this technique in real campaigns against real companies, you can bet the less-famous threat actors are too. ---------------------------------------------Dean-----------------------------------------------------------

Updated 22 Feb, 2026 v2 Section 1 — Why Attackers Can't Always Hide Their Tracks When a sophisticated attacker gets into a system, one of the first things they think about is cleanup. We're talking file wipers, free space wipers, deleting archive files — the whole nine yards. Say they used a privilege escalation tool to move through the network. Before they leave, they'll try to wipe that tool so nobody finds it. Same goes for those .rar archives they used to bundle up stolen data before exfiltrating it — gone. The problem for them (and the good news for us) is that Windows has been quietly taking snapshots of the system in the background the whole time. Even if an attacker nukes a file, there's a decent chance a copy of it is sitting in a volume shadow snapshot from a few hours or days earlier. That's the whole game here. To know more about forensic Wipers: Link below https://www.cyberengage.org/post/every-forensic-investigator-should-know-these-common-antiforensic-wipers Section 2 — What Even Is a Volume Shadow Copy? Let's back up a second. Volume Shadow Copies (VSCs) are point-in-time snapshots of your file system, managed by the Volume Shadow Copy Service (VSS). This thing has been around since Windows XP — though back then it was called System Restore points and it was a lot more limited. Starting with Vista and Server 2008, Microsoft upgraded it significantly. Instead of just backing up a handful of key system files, VSS started capturing near-complete snapshots of the entire volume. That's a huge deal for forensics — we're talking recovering deleted executables, DLLs, drivers, registry files, event logs the attacker deleted. Basically rewinding the whole system to a previous state. The way it works under the hood is called copy-on-write (COW). Whenever something gets written to disk, VSS first saves a backup copy of those data blocks before letting the new data overwrite them. These backed-up blocks are stored in 16KB chunks inside the System Volume Information folder, tracked by a catalog file named with a specific GUID. Section 3 — The ScopeSnapshots Problem Here's where things get a little annoying. Starting with Windows 8, Microsoft introduced a feature called ScopeSnapshots, which is now enabled by default on Windows 8, 8.1, 10, and 11. When this is turned on, volume snapshots only capture files "relevant for system restore" — which basically brings us back to the limited Windows XP era. Files on the user's desktop, random directories, stuff an attacker might leave behind? Potentially not captured. The good news: Windows Server platforms still use the full snapshot functionality — so if you're analyzing a server (which is often the most critical machine in an intrusion), you're in good shape. And on client systems you can disable ScopeSnapshots with a registry tweak shown below. Also worth knowing — there's a small exclusion list at HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot for files VSS won't capture. The hibernation file and page file are typically excluded too, though some have found them present in certain cases — so don't write them off completely. Section 4 — Listing Available Shadow Copies First thing you want to do on a live Windows machine is see what shadow copies are actually available. Open Command Prompt as Administrator and run the command below — replace C: with whatever drive you're targeting. The output will show each shadow copy with its volume name, the originating machine, and — most importantly — the creation timestamp. That timestamp is how you figure out which snapshot might contain the evidence you're after. Section 5 — Accessing Shadow Copies from a Live System If you're working on a live machine and want to browse a shadow copy, symbolic links are your friend. Here's the process — once you've created the link, navigate to that folder in File Explorer or Command Prompt. It'll look just like a regular directory, but you're actually browsing the snapshot from that point in time. This is a quick way to pull files that have since been deleted or modified on the live system. Section 6 — Analyzing Shadow Copies from a Disk Image For critical systems — patient zero, the executive's laptop, whatever the main target was — you're going to want a full disk image. That way you have everything and you're not touching the live system any more than necessary. Here's where the real forensic tools come in. Option 1 : Arsenal Image Mounter Arsenal Image Mounter does something clever — it uses a driver to make the disk image look like a real physical SCSI drive to Windows. Once Windows thinks it's a real disk, it automatically exposes all the volume shadow copies on it. Note: FTK Imager's mount feature does NOT expose VSCs to the OS, which is why Arsenal is the go-to here. Option 2: libvshadow When you need to work without relying on Windows, the libvshadow tools from Joachim Metz are fantastic. The two main tools are vshadowinfo (lists shadow copies) and vshadowmount (exposes them as raw disk images). Here's the full workflow: Option 3: Kape  Link below https://www.cyberengage.org/post/volume-shadow-copy-with-kape Section 7 — Timeline Analysis with log2timeline Here's where things get really powerful. If you're building a forensic timeline, log2timeline.py has built-in support for VSS. When you point it at a disk image, it'll prompt you to include shadow copies and let you pick which ones — none, some, or all. The big challenge with VSS timeline analysis is duplicate data — the same event log entry might show up across five different snapshots. That's where psort's deduplication feature saves you. It filters out identical entries across snapshots so you're not drowning in noise. To learn more using Plaso : log2timeline Link below https://www.cyberengage.org/post/a-deep-dive-into-plaso-log2timeline-forensic-tools Section 8 — What This Means for an Investigation To put it simply — volume shadow copies can completely change the outcome of a case. Here's a snapshot of what you can realistically recover: Even when a machine has been thoroughly wiped, shadow copies often survive because attackers either don't know about them, don't have time to clear them, or can't access them without administrative tools that would leave their own traces. Their oversight is your advantage. Conclusion Volume Shadow Copies are one of those features that exist quietly in the background, doing their job whether anyone pays attention or not. For forensic analysts, that's a gift. They give us a time machine — imperfect, yes, especially on modern Windows client systems with ScopeSnapshots enabled — but powerful enough to recover evidence that attackers thought was gone forever. ---------------------------------------------Dean-----------------------------------------------------------

Unlike Google-targeted attacks, the Microsoft 365 PhaaS ecosystem is well-documented, heavily researched — and quietly industrialised. Here's the full picture from kit purchase to BEC payout. Business email compromise used to require skill. Attackers needed to understand Exchange internals, craft convincing social engineering at scale, and know how to quietly live inside a compromised tenant without triggering alerts. That skillset still exists — but it's no longer required . Today you can rent it for $120. The Microsoft 365 PhaaS ecosystem is, frankly, mature. While Google-targeting kits are underreported and likely circulating in the same underground markets , the M365 side has been thoroughly catalogued by threat researchers at Sekoia, Proofpoint, Barracuda, Sygnia, Invictus IR, and Microsoft's own Defender team. What has emerged is a portrait of an industrialised attack supply chain that makes sophisticated MFA bypass accessible to any moderately motivated criminal with a Telegram account and a few hundred dollars in Bitcoin. This article documents how these kits work, what attackers do once inside, and — critically — what forensic artefacts they leave behind, because the most repeatable attacks leave the most repeatable evidence. The Kit: Tycoon 2FA Tycoon 2FA is the dominant player. First observed in August 2023 by Sekoia researchers, it emerged as an evolution of an earlier kit called Dadsec OTT — the Tycoon developer likely forked that codebase and extended it with AiTM-specific capabilities. It is sold via Telegram through a channel called the "Saad Tycoon Group", advertising ready-to-use Microsoft 365 and Gmail phishing pages, attachment templates, and access to an administration panel that lets customers monitor ongoing campaigns in real time. Pricing starts at $120 for a 10-day window, scaling upward depending on the top-level domain and kit features selected — typically maxing around $320. Payment is via Bitcoin. By mid-2024, the operator's wallet had logged more than 1,800 transactions, with cumulative revenues estimated at over $394,000. This is not a hobby project. It is a running business with active product development: a major updated version was released in March 2024 with enhanced obfuscation and anti-detection capabilities, followed by another significant update in November 2024 specifically designed to defeat security tooling inspection. How the Attack Works: The Kill Chain The attack is an Adversary-in-the-Middle operation. Unlike traditional phishing that captures static credentials and codes, an AiTM kit inserts a reverse proxy between the victim and Microsoft's real authentication infrastructure. The victim's browser is talking to a pixel-perfect Microsoft login page — which is, technically, real, because all traffic is being relayed through the proxy. MFA is not broken; it is completed legitimately by the victim, and the authenticated session cookie produced by that successful MFA challenge is captured by the proxy in real time. The Inbox Rule: The Most Important Forensic Artefact If there is one finding that IR practitioners should prioritise in any M365 compromise, i t is the inbox rule created immediately after session takeove r. This is documented extensively across independent IR firms' caseloads — Invictus IR, Sygnia, Microsoft Defender researchers, and Huntress have all highlighted it — and it is operationally deliberate. The attacker's goal with these rules is simple : the victim must not know the account is compromised . A rule that deletes all incoming email, or silently moves security alert messages to a folder the victim never opens, can buy days of undetected access. In the Microsoft-documented energy sector campaign, the attacker's rule was specific: delete all incoming emails and mark all messages as read, eliminating visual cues of new activity. The hidden rule problem is particularly insidious. Attackers have learned that rules created through MAPI manipulation — rather than the standard Outlook or OWA interface — do not appear in the Exchange admin center's rules list. Standard client-side auditing misses them entirely. MFCMAPI or PowerShell with the -IncludeHidden flag is required to surface them, a fact that many incident responders do not encounter until they're deep into a case wondering why a mailbox appears clean despite clear signs of compromise. Why MFA Didn't Stop It — And What Would The most common client reaction to these incidents is disbelief. MFA was enabled. The user completed the challenge. How is there a compromise? The answer is that AiTM attacks do not attack MFA — they work around it by stealing the output of a successful MFA session (the cookie) rather than trying to intercept or defeat the MFA mechanism itself. Once a session cookie is obtained, it represents an authenticated, trusted browser session. Microsoft's infrastructure sees it as a legitimate continuation of a session that was properly MFA-verified. Changing the password after the fact does not help: the cookie was issued before the password change, and Microsoft's session management does not automatically invalidate cookies when passwords are reset unless administrators explicitly revoke all active sessions. "Password resets alone are insufficient — impacted organizations must ensure that they have revoked active session cookies and removed attacker-created inbox rules." — Microsoft Defender Security Research Team, January 2026 The only authentication mechanisms technically resistant to AiTM attacks are FIDO2 hardware security keys and passkeys . Both bind the authentication response cryptographically to the legitimate origin domain using the WebAuthn standard. A proxy server relaying traffic from a phishing domain cannot forge this binding — the cryptographic assertion will fail if the origin doesn't match. TOTP codes, SMS OTPs, and Authenticator push notifications are all susceptible, because they produce portable, origin-agnostic proofs that a proxy can relay unchanged. The Anti-Analysis Arms Race What makes Tycoon 2FA and its competitors genuinely sophisticated is not the AiTM technique itself — that has been publicly documented and implementable via open-source tools like Evilginx for years. It is the anti-analysis layer that now ships as a standard product feature . The March 2024 update introduced heavily obfuscated JavaScript with dynamic code generation that alters its structure on each execution, defeating signature-based detection. The November 2024 update specifically targeted the tooling security researchers use to analyse phishing pages — blocking developer tool shortcuts, detecting debugger attachment, preventing element inspection, and redirecting to legitimate decoy sites when automated analysis is detected. Backend validation ensures phishing payloads only execute if a specific server response value is returned, meaning URL scanners that don't fully emulate the authentication flow receive only a clean redirect. The Multi-Org Cascade: When One Compromise Becomes Ten One of the more alarming real-world patterns, documented by both Sygnia and Microsoft's Defender team, is the cascading multi-organisation spread that can result from a single AiTM compromise. The attacker, once inside a victim account, harvests the victim's recent email contacts and threads. Phishing emails sent from the compromised account to those contacts arrive from a trusted domain with legitimate email authentication. Each recipient who clicks and completes MFA yields another compromised session. Each of those victims' contacts becomes the next target pool. In the energy sector campaign documented by Microsoft in January 2026, a single initial compromise spawned a chain of AiTM attacks across multiple distinct organisations. The attack was specifically designed to abuse SharePoint file-sharing links — because a link to a shared file in SharePoint looks inherently legitimate, even to security-aware users. The phishing campaign from just one compromised user sent over 600 emails targeting contacts both inside and outside the victim's organisation. What to Look For: IR Triage Checklist For practitioners responding to a suspected M365 AiTM compromise, the following artifacts are the highest-priority items in the Unified Audit Log and Entra ID sign-in logs . Confirm the UAL is enabled first — query Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIsEnabled — because without it, forensic reconstruction is severely limited. Sign-in logs should be examined for the originating IP and ASN of the first post-compromise session: expect a VPS provider, often in a jurisdiction inconsistent with the victim's normal login pattern. The timestamp delta between the phishing email being clicked, the MFA completion, and the attacker's VPS login is often under five minutes in automated kit operations. UAL operations to search include New-InboxRule, Set-Mailbox, UpdateInboxRules, and MailItemsAccessed — the last being critical for understanding what the attacker read before the compromise was detected. Remediation must include explicit session revocation — not just a password reset. All active refresh tokens for the compromised account must be revoked via Entra ID (formerly Azure AD), and all inbox rules should be audited and removed, including those hidden from standard views. MFA method changes made by the attacker during the compromise window should also be reviewed and rolled back. Bottom Line Microsoft 365 AiTM attacks via PhaaS toolkits are no longer an emerging threat — they are the dominant mode of MFA bypass against enterprise Microsoft environments. Tycoon 2FA alone has been tied to over 64,000 documented incidents, operates across more than 1,100 domains, and generated nearly $400,000 in revenue before many organisations had updated their defensive playbooks to account for session-cookie theft as distinct from credential theft. The key shift in posture required is treating post-authentication session management as a security control in its own right. FIDO2 mandates for high-value accounts eliminate the AiTM vector entirely . Conditional access policies that continuously evaluate session legitimacy — not just at login — reduce attacker dwell time when cookies are stolen. And inbox rule monitoring in the UAL, correlated with anomalous sign-in events, gives defenders the best forensic hook into detecting kit-based operations, because the most automated attacks are also the most consistent. The kit economy has made this easy to deploy. Defenders need to make it hard to survive. --------------------------------------------------Dean------------------------------------------- If you want to check out for article related to Gmail PhaaS Link below https://www.cyberengage.org/post/the-gmail-phaas-playbook-anatomy-of-a-repeat-offender ---------------------------------------------------------------------------------------------------

After seeing more than a dozen Gmail account-compromise incidents, a pattern has emerged that is too consistent to be coincidental. The victim receives a legitimate-looking Google MFA prompt on their mobile device, accepts it thinking nothing of it, and their account is silently handed to an attacker sitting on a VPS somewhere overseas. Within hours — sometimes minutes — the hijacked inbox becomes a launchpad, blasting hundreds of phishing emails to the victim's contact list. The kill chain is almost identical across every case. Same hosting providers, same post-compromise behaviour, same evasion technique. This article documents what I've observed in the field, and makes the case that these campaigns are being powered by a commoditised, black-market Phishing-as-a-Service (PhaaS) toolkit — the Google-targeting cousin of well-documented Microsoft 365 kits like Tycoon 2FA. How the Attack Works: The attack flow is a textbook Adversary-in-the-Middle (AiTM) operation. Rather than breaking encryption or exploiting a Google vulnerability, the attacker positions a reverse proxy server between the victim and Google's real login page. The victim authenticates — for real — and the proxy captures their live session cookie. MFA is never "bypassed" in the traditional sense; the user completes it legitimately, and the attacker simply steals the authenticated session that results. The Mailer-Daemon Block: An Underappreciated Tell The single most distinctive indicator in these cases — and the one I've rarely seen documented specifically for Gmail AiTM campaigns — is the deliberate blocking of mailer-daemon@googlemail.com immediately prior to the outbound spam run. When an email fails to deliver, Google's mail delivery subsystem sends a Non-Delivery Report (NDR), or "bounce," back to the sending address from mailer-daemon@googlemail.com . In a bulk phishing operation sending to hundreds of targets, a significant proportion of those addresses will be invalid, dormant, or protected by spam filters — generating a flood of bounce-back messages into the victim's inbox. These bounces are a bright red flag. A victim seeing their inbox fill with hundreds of delivery failures for emails they never sent would immediately know something is wrong and likely raise the alarm or change their credentials before the phishing campaign reaches full effect. By creating the block rule first , the attacker buys time. The victim's inbox appears normal. No bounces arrive. The campaign runs undetected for longer. This is not a casual decision — it's an operationally deliberate step that indicates the actor understands the detection risk and has scripted a mitigation into their workflow. This Is a PhaaS Toolkit — Not a Solo Operator The uniformity across unrelated cases is the giveaway. Independent victims, different organisations, different time periods — yet the same hosting providers, the same post-compromise playbook, the same sequencing. This is not the signature of a creative threat actor adapting their approach. It is the signature of a product. The Microsoft 365 side of this problem is well-documented. Tycoon 2FA , first surfaced by Sekoia researchers in late 2023, is the most prominent example: a fully commercialised AiTM PhaaS platform sold via Telegram for as little as $120 for a 10-day phishing window . It targets both Microsoft 365 and Gmail accounts, operates across over 1,100 domains, and had generated more than $394,000 in Bitcoin transactions by mid-2024 alone. It is actively maintained, with regular updates to improve evasion and obfuscation of its phishing pages. The Google-specific variant I've encountered in the field bears the same hallmarks of a packaged kit: automated steps, consistent infrastructure choices, and pre-built post-compromise actions (like the mailer-daemon filter) that no manual operator would apply identically across ten separate victim accounts. The most likely explanation is that there is a Google-focused PhaaS toolkit — or a Google module within an existing one — circulating in black-market channels that has simply received less public research attention than the Microsoft 365-focused kits. Why MFA Didn't Stop This A common client reaction when these incidents are presented is disbelief that MFA "failed." It didn't fail — it was bypassed elegantly. The AiTM technique doesn't attack MFA at the protocol level. It weaponises the user's trust in their own device notification and the real-time nature of the proxy relay. The victim completes a genuine MFA challenge against the real Google infrastructure . The attacker simply intercepts what that authentication produces: a session cookie representing an already-authenticated session. Stolen cookies allow attackers to replay a session and maintain access even if credentials are subsequently changed, because the session was established with valid MFA consent. The only authentication methods that are technically resistant to AiTM are FIDO2 hardware keys and passkeys, both of which bind the authentication response cryptographically to the legitimate origin domain — something a proxy cannot forge. Traditional TOTP codes, SMS codes, and push-notification approvals are all susceptible. What IR Reports Should Document If you're handling a similar case, the following artifacts are the most valuable to preserve and document. Timeline of Gmail filter creation (found in Gmail's audit logs or via Google Workspace Admin Console) is critical — the timestamp of the mailer-daemon block rule relative to the first anomalous login and the first outbound phishing email establishes the operator's automated playbook. Login IP addresses and ASN data will likely cluster around a small set of VPS providers; cross-case correlation on these is highly productive for attribution and building shared IoC sets. Sent mail folder content — if not deleted — reveals phishing template design, which can often be matched to known PhaaS kit templates. And device approval logs will show the precise moment the victim accepted the fraudulent MFA prompt, which is useful both for forensic reconstruction and for explaining the compromise to the victim. The good news, if there is any, is that the repeatability of this attack pattern means that once you've worked one case thoroughly, you have a reliable template for the next. The bad news is that the repeatability also means the toolkit is stable, functional, and being actively used at scale. Bottom Line Gmail-targeted AiTM attacks are being conducted with the same tooling discipline seen in the well-documented Microsoft 365 PhaaS ecosystem. The specific post-compromise behaviour of blocking bounce notifications before a bulk phishing blast is a repeatable, operational artefact of an automated kit — not improvised tradecraft. Security teams responding to Gmail BEC incidents should treat this pattern as a reliable indicator of kit-based attacks, add the mailer-daemon filter check to their standard Gmail triage checklist, and escalate intelligence on hosting providers and infrastructure to contribute to broader community detection efforts. Phishing-as-a-Service has lowered the floor for conducting sophisticated MFA-bypassing campaigns to the price of a budget software subscription. The Google ecosystem deserves the same research scrutiny the Microsoft 365 PhaaS space has received. Hopefully, public documentation of these field patterns will accelerate that work. -------------------------------------------Dean----------------------------------------------------

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-------------------------------------------------------------