This Zeek traffic analysis lab felt different from the beginning because it was less about “opening packets” and more about learning how to think through traffic behavior like a SOC analyst.

The room moved through:

• Zeek logs
• Zeek signatures
• Zeek scripts
• threat hunting
• phishing investigations
• DNS tunneling
• Log4Shell detection
• malware extraction
• VirusTotal pivoting

and this was one of the first labs where I started seeing how network telemetry, detection engineering, and investigation logic all connect together.

What I Saw First

At first, Zeek looked overwhelming because of the number of generated logs.

After processing a PCAP, Zeek would generate:

• conn.log
• dns.log
• http.log
• files.log
• notice.log
• signatures.log
• intel.log

and several others depending on the traffic and loaded scripts.

Initially, I approached it like Wireshark:

“Open packets, inspect traffic, search manually.”

But Zeek works differently.

Instead of showing packets directly, Zeek turns traffic into structured logs that can be queried quickly with tools like:

• zeek-cut
• grep
• sort
• uniq
• wc

Example:

cat dns.log | zeek-cut query | sort | uniq | wc -l

That changed the speed of investigation completely.

Why It Looked Normal

At first, many of the PCAPs looked harmless.

Especially during:

• DNS activity investigations
• HTTP traffic reviews
• phishing analysis

Most of the traffic appeared like normal browsing behavior. For example, during the DNS tunneling challenge, there were thousands of DNS queries, which initially just looked noisy.

But after normalizing domains:

cat dns.log | zeek-cut query | rev | cut -d '.' -f 1-2 | rev | sort | uniq

I realized most of the traffic was tied to the same base domain:

• cxxxco-update.com

That was the first strong indicator of abnormal DNS behavior. This was one of the biggest lessons from the Zeek traffic analysis lab:

massive repetition can matter more than individual packets.

What Felt Off

The biggest red flags started appearing during:

• phishing traffic analysis
• Log4Shell detection
• FTP brute-force investigations

One phishing PCAP contained:

• a malicious Word document
• an executable payload
• suspicious external domains
• malware retrieval over HTTP

The HTTP logs quickly exposed the activity:

cat http.log | zeek-cut host uri

Output:

sxxxt-fxx.com   /Documents/xxxxx&MSO-Request.doc
sxxxt-fax.com   /kxr.exe

That immediately shifted the investigation toward:

• malware delivery
• payload execution
• external communication

The source host: 1x[.]x[.]x7[.]xxx, became the main infected system pivot.

Where I Got It Wrong

I struggled with Zeek signatures more than expected.

At first, my HTTP detection rule wasn’t generating any alerts:

signature http-password {
  ip-proto == tcp
  dst-port == 80
  payload /password/
  event "Cleartext Password Found!"
}

No notice.log was created.

Here’s how I debugged it: I realized the regex pattern was too loose for the traffic inside the PCAP.

What finally worked was:

signature http-password {
  ip-proto == tcp
  dst-port == 80
  payload /.*password.*/
  event "Cleartext Password Found!"
}

That immediately generated:

• notice.log
• signature hits
• HTTP detection events

I had a similar issue during the FTP brute-force section. This broader payload match:

payload /.*530.*/

was unreliable.

The working version became:

signature ftp-brute {
  ip-proto == tcp
  payload /.*530.*Login.*incorrect.*/
  event "FTP Brute-force Attempt!"
}

That taught me something important:

detection logic is not only about matching patterns, but matching context correctly.

What Changed My Thinking

The biggest mindset shift happened when I stopped treating Zeek like a packet viewer and started treating it like a detection engine.

Especially during:

• DNS tunneling analysis
• phishing investigations
• Log4Shell exploitation detection

I started correlating:

• dns.log
• conn.log
• http.log
• files.log
• notice.log
• intel.log

instead of investigating them separately. One example was decoding attacker commands from the Log4Shell activity.

Inside log4j.log, there were base64 encoded commands.

After decoding them:

echo "<base64_string>" | base64 -d

I could identify:

• attacker actions
• created files
• exploitation behavior

That felt much closer to actual SOC investigation work than simple packet analysis. Another major moment was using VirusTotal pivots through extracted file hashes:

cat files.log | zeek-cut filename md5

That connected:

• PCAP traffic
• malware samples
• external threat intelligence
• contacted domains

into a single investigation chain.

My Final Conclusion

This Zeek traffic analysis lab became one of the most practical blue-team exercises I’ve done so far.

It covered:

• DNS tunneling detection
• phishing investigations
• malware extraction
• threat hunting
• Zeek signatures
• Zeek scripts
• Log4Shell exploitation analysis
• detection engineering concepts

The biggest lesson was understanding that:

network traffic analysis is not only about packets, but about behavior correlation. Zeek made investigations feel structured.

Instead of manually searching packets endlessly, I could:

• extract indicators quickly
• build detection logic
• pivot across logs
• validate suspicious behavior faster

This lab also reinforced how important:

• regex precision
• log correlation
• IOC enrichment
• threat hunting logic

are inside real SOC workflows.

What I Would Do in a Real SOC

If I encountered similar traffic in a real SOC environment, I would:

DNS Tunneling

• baseline DNS behavior
• monitor repeated subdomain patterns
• alert on excessive query volume
• investigate long/randomized subdomains

Phishing Activity

• isolate infected hosts
• block malicious download domains
• retrieve malware hashes
• pivot through VirusTotal and threat intel feeds
• identify lateral movement attempts

Log4Shell Exploitation

• identify vulnerable systems immediately
• review outbound connections
• decode attacker payloads
• monitor command execution artifacts
• correlate with endpoint telemetry

Detection Engineering

I would also improve detection rules by:

• reducing false positives
• tightening regex conditions
• correlating multi-log events
• enriching alerts with IOC intelligence

Because one thing this lab showed clearly:

accurate detections matter more than noisy detections.

Useful Zeek Commands Used Throughout The Lab

Count Unique DNS Queries

cat dns.log | zeek-cut query | sort | uniq | wc -l

Normalize Base Domains

cat dns.log | zeek-cut query | rev | cut -d '.' -f 1-2 | rev | sort | uniq

Longest Connection Duration

cat conn.log | zeek-cut duration | sort -nr | head -1

Extract HTTP Hosts & URIs

cat http.log | zeek-cut host uri

Extract MD5 Hashes

cat files.log | zeek-cut filename md5

FTP Brute-force Signature

signature ftp-brute {
  ip-proto == tcp
  payload /.*530.*Login.*incorrect.*/
  event "FTP Brute-force Attempt!"
}

HTTP Password Detection Signature

signature http-password {
  ip-proto == tcp
  dst-port == 80
  payload /.*password.*/
  event "Cleartext Password Found!"
}

Decode Base64 Commands

echo "<base64_string>" | base64 -d

Check out more about Zeek & Brim: Warzone Malware Investigation Alert Triage

Visit my everyday playground here