Where Do We Begin? A Network Forensic Investigator’s Steps
- Jun 2
- 9 min read
Forensic Mindset article
let’s be honest—when you're knee-deep in a digital forensic investigation or a threat hunting session, one of the biggest challenges is simply knowing where to start.
Sometimes you’re lucky. You get a nice clean lead: a suspicious IP, a malware hash, or a user who clicked something shady. But more often than not, someone just comes over and drops the classic:
“Something’s off… we don’t know what, but can you check it out?”
Frustrating, right? But this is actually where the real DFIR (Digital Forensics and Incident Response) journey begins.
-------------------------------------------------------------------------------------------------------------
The Investigative Compass: Ask the Right Questions
Here’s what helps me frame my approach—and you might find this helpful too:
1. What was taken? When? Where did it go? How? Who?
Classic damage assessment. This is what most stakeholders care about. What data was stolen? When did it happen? Is it still happening? "who did it" isn’t always the most urgent priority.
2. What happened just before and after the incident?
Events don’t happen in a vacuum. Context is king. A login from a foreign IP five minutes before the ransomware hit? That matters. Random account creation after an attachment was opened? That’s a clue.
Sometimes the thing you’re investigating is just the tip of the iceberg. Looking at the surrounding activity is how you find the rest of it.
3. How did the malware get in?
Was it a phishing email? A drive-by download from a shady ad network? A vulnerable web server?
You’ll often find these answers in your network logs or proxy data. Knowing how the threat entered helps you close that door and stop the same thing from happening again.
4. What else was happening on the network?
This is about scoping. Are there other compromised systems? Are there lateral movements? This is where real hunting begins.
A good rule of thumb: if one system is infected, chances are it’s not alone.
-------------------------------------------------------------------------------------------------------------
The Most Common Entry Point: Phishing (Yeah, Still)
Let’s walk through an all-too-familiar story:
User connects to the corporate Wi-Fi.
Logs into their domain account.
Opens Outlook.
Sees an email — looks legit.
Clicks a link. Boom. Game over.
Here’s what actually happens under the hood:
DNS request to the phishing domain.
Website serves a drive-by download.
User unknowingly runs the payload.
It fetches a second-stage malware.
Tries connecting to primary C2 — blocked.
Falls back to backup C2 — success.
This tiny click becomes a pivot point for an entire compromise. Knowing the order of operations helps you know exactly what to look for in logs and network traffic.
-------------------------------------------------------------------------------------------------------------
Packet Captures (pcaps): Goldmine or Nightmare?
If you’ve worked with network data, you’ve seen .pcap files. These are generated by tools like tcpdump, Wireshark, or npcap (for Windows).
But let’s get real—just having a pcap isn’t enough.
You’ve got to ask:
What interface did the capture come from?
Was it a WLAN in managed mode (data frames only)?
Or monitor mode (more detailed 802.11 frames)?
Knowing how and where the pcap was captured can save you hours of chasing false leads.
Also, pcaps are heavy. On high-bandwidth networks, they can get out of hand quickly—moving them, parsing them, even opening them can be painful.
-------------------------------------------------------------------------------------------------------------
NetFlow & IPFIX: Metadata Magic
If you can’t get full packet captures (because... storage), the next best thing is NetFlow or IPFIX. These are like traffic summaries — you won’t see payloads, but you will see what talked to what, when, and how much.
Cisco started it. IPFIX is the open standard.
Collectors store the data, analysts query it.
It’s best used for large networks where full captures are impractical.
For example: if you see 1000 connections from a IOT to an outside IP on port 443... yeah, something’s weird.
-------------------------------------------------------------------------------------------------------------
Logs: Trust, but Verify
Logs are amazing, but only if you:
Hash them the moment you collect them.
Store originals in read-only storage.
Work only on trimmed-down copies.
Label edits and don’t overwrite the originals.
Also, retention matters. Sometimes breaches stay hidden for months. If you’re only keeping logs for 30 days, that’s not good enough.
A good practice? Match your log retention to your threat landscape. At least a year for critical servers.
-------------------------------------------------------------------------------------------------------------
Scoping: What Else Was Happening?
After finding malware or a breach, don’t stop there. Ask:
Were other systems affected?
Is this lateral movement?
Is the malware beaconing out?
This process — scoping — is crucial. Think of it like a crime scene investigation: don’t just look at the body, look at the entire room.
-------------------------------------------------------------------------------------------------------------
let’s slow down and talk about something we often take for granted: how we actually get the traffic in the first place.
We usually get excited about libpcap, tcpdump, and Suricata rules (yes, guilty here 🙋♂️), but without the right hardware setup, those tools are like a car without wheels.
First Stop: The Humble Switch (And Port Mirroring)
Let’s start with the network switch. These little workhorses make sure devices talk to the right destinations by segmenting traffic. Great for performance — but bad for traffic visibility.
On a switched network, we can’t just plug into a random port and expect to see all the traffic. Switches are too smart for that. So this is were port mirroring to the rescue! Also known as SPAN ports (Switch Port Analyzer).
Here’s how it works:
The switch duplicates traffic from one or more ports (or even VLANs).
It sends that duplicate stream to a specific port you designate.
You plug your capture box or sensor into that mirrored port, and boom — you're now watching the action.
Why it’s awesome:
Already built into most enterprise switches.
Zero hardware cost (just configuration).
No need to interrupt the network.
But there’s a catch:
The mirrored port might choke if you throw too much data at it.
Even if the switch supports 24 ports at 1Gbps, your SPAN port is still just one 1Gbps link.
If traffic exceeds what the mirror port can handle, it can drop packets — or worse, the switch might disable the mirror completely.
-------------------------------------------------------------------------------------------------------------
🛠️ Enter the Network TAP: Built for One Job, and It Nails It
When port mirroring isn’t cutting it — we turn to the network TAP . These are hardware devices designed solely to duplicate network traffic. No bells, no whistles — just glorious packets.
Different types of TAPs:
Basic TAPs
Split the traffic into two directions (ingress and egress).
You’ll need to reassemble them (called aggregation) using software or another device.
Aggregation TAPs
Combine both directions into one full-duplex stream — super handy for monitoring from a single interface.
Regenerating TAPs
They clone traffic to multiple output ports, so you can feed data to multiple sensors or analysis tools at the same time.
This is gold during IR when one team might be doing full packet capture while another is looking at behavior or writing detections.
-------------------------------------------------------------------------------------------------------------
Cloud’s Not Left Out Either
Guess what? Traffic mirroring isn’t just for on-prem anymore. Cloud vendors finally gave us what we need:
AWS: Has VPC Traffic Mirroring, which mirrors traffic from ENIs (Elastic Network Interfaces) to a collector.
Google Cloud: Offers Packet Mirroring, which works across instances in a VPC.
These are awesome for cloud visibility, but remember to monitor your costs — mirroring traffic can rack up bandwidth charges!
TAPs vs. Port Mirroring: What You Really Need to Know
Feature | Port Mirroring (SPAN) | Network TAP |
Cost | ✅ Free (built-in) | ❌ Expensive |
Reliability | ⚠️ Can drop packets | ✅ Rock solid |
Setup Impact | ✅ No downtime | ❌ Needs brief downtime |
Complexity | ✅ Simple config | ⚠️ Varies with features |
Use Case | 🟡 Light monitoring | 🟢 Heavy-duty, IR, forensics |
-------------------------------------------------------------------------------------------------------------
Let's talk about Network Flow Data.
Yup, we’re talking NetFlow, VPC Flow Logs, DNS logging, and all the juicy network breadcrumbs attackers leave behind. Whether you’re responding to a breach or threat hunting proactively, this kind of telemetry is pure gold.
What the heck is NetFlow and why should I care?
NetFlow is basically metadata about traffic that moves across a network. It won’t show you full packet content (so don’t expect to see passwords or payloads), but it tells you who talked to who, for how long, how many packets, and how much data.
Think of it like your phone bill: you may not hear the convo, but you know who called who, for how long, and from where.
-----------------------------------------------------------------------------------------------------------
Where Can You Get Flow Data From?
Internal Devices
Most routers and firewalls (especially enterprise-grade ones) can export flow logs. Many switches with Layer 3 or 4 capabilities can do this too.
Just note: it's often disabled by default, so check that setting first.
Want endpoint-level logging?
You can configure workstations and servers using tools like:
fprobe
pmacct
nprobe
Now, if you’re in the middle of an incident or running a hunting operation, you can even pair these tools with port mirroring to collect flows tactically. Super useful if you want focused visibility without touching every endpoint.
-----------------------------------------------------------------------------------------------------------
Cloud Platforms
For those running workloads in the cloud:
AWS gives you VPC Flow Logs
Azure has NSG Flow Logs
Google Cloud provides VPC Flow Logs
These are cloud-native equivalents of NetFlow and can be integrated right into your detection pipeline. Just remember to tune what’s being logged so you’re not overwhelmed.
-----------------------------------------------------------------------------------------------------------
Why Is NetFlow So Useful in IR?
Let’s say you detect a suspicious IP today. You can go back and ask:
Has this IP connected to us before?
What systems did it talk to?
Was data sent out (exfiltration)?
Is there a pattern of beaconing (C2)?
The cool thing is NetFlow data is super fast to query, and because it’s metadata, it's not as sensitive or heavy as full packet capture. That means storage and privacy concerns are much lower.
You can also spot odd behavior like:
Massive outbound flows → data theft?
Repetitive small bursts of traffic → C2?
Connections to known bad IPs → APT action?
-----------------------------------------------------------------------------------------------------------
Okay, but how do we actually get the logs?
Great question. Just because the devices can generate logs doesn’t mean you’ll have access.
Many security appliances have painful UI-based exports—especially if they’re managed by an MSSP.
You must test the log collection/export mechanism before an incident happens.
Can’t access the device? Then make sure the admins can, and fast. Or, better yet, automate the process if possible.
If logs are being sent to you from someone else make sure:
The logs are secure (in transit and at rest)
File formats and sizes are supported
Everyone involved knows how to collect and send the data
Pro tip: Set up regular drills with your team so that collecting and reviewing logs becomes second nature.
-------------------------------------------------------------------------------------------------------------
External Evidence: Often Forgotten, But Invaluable
This one’s often overlooked.
Your ISP
Yep, your ISP may collect NetFlow from boundary routers. If you have a good relationship with them (and legal clearance), they might be able to give you insight into every bit of inbound and outbound traffic. This can be life-saving if your internal logs were wiped or weren’t enabled.
Other Organizations
If your infrastructure is used to attack someone else (e.g., you got pwned and became a launchpad), they might send you logs showing:
Source IP
Port used
Packet metadata
But let’s be real—no one is going to start these conversations in the middle of a crisis. This is where ISACs or threat intel sharing groups can help. Set up those channels before you need them.
------------------------------------------------------------------------------------------------------------
Planning Your Logging Strategy
There are three types of planning scenarios:
1. Strategic/Architectural (Baked-in)
This is where security folks are part of the network design from the beginning. You decide where to place proxies, IDS sensors, and flow log exporters before any incident happens.
Pros:
Zero downtime when an incident hits
Continuous visibility
Forces network engineers to build security into the design
Cons:
Expensive
Requires justification (hard to show value until things go wrong)
Might involve proprietary data formats (vendor lock-in)
2. Tactical/Ad-hoc Platforms
This is my personal favorite—especially if you’re low on budget.
Build or buy portable packet capture boxes that you can deploy anywhere in the network when needed.
Pros:
Super flexible
You control the setup
Easier to train your team on
Cons:
Might need downtime to insert the box
You’ll need solid documentation for how/when/where to deploy
These are best when paired with a few pre-positioned sensors in high-value areas.
3. “We’ll Figure It Out When It Happens”
No. Just... no.
Seriously, don’t wing it. You’ll be halfway through the breach trying to order a capture card off Amazon.
Instead, build a hybrid model:
Place permanent monitors at your perimeter and crown jewels
Keep a few tactical boxes on standby
Train your team regularly to know how to use both
-----------------------------------------------------------------------------------------------------------
Don't Forget DNS Visibility
One last but crucial thing: DNS logs.
DNS is everywhere, and attackers love it for C2, exfiltration, and even domain generation algorithms (DGA). Make sure:
Internal DNS resolvers are logging queries and responses
External DNS providers (like Google, Cloudflare, etc.) are integrated into your SIEM if they allow it
DNS visibility = quicker scoping, faster identification of malware domains, and understanding attacker behavior.
-----------------------------------------------------------------------------------------------------------
Wrapping It Up
This stuff isn't just for blue teams. Red teamers, threat hunters, and IR folks all benefit from proper flow visibility. If you're serious about incident response or DFIR, flow data isn't a luxury—it's a necessity.
Let’s keep pushing for opensource cybersecurity knowledge.
--------------------------------------------Dean---------------------------------------------------------