Threat Hunting: In this lab, there is a SOC investigation workflow. Instead of chasing obvious malware indicators immediately, I had to pivot through:

• DNS logs
• HTTP requests
• connection logs
• Suricata alerts
• suspicious binaries
• strange traffic behaviour

This Threat Hunting with Brim exercise pushed me into thinking more like an analyst instead of someone just answering questions.

The main focus throughout the investigation was:

• Malware C2 Detection
• PCAP Analysis
• identifying suspicious traffic patterns
• validating indicators with threat intelligence
• correlating logs together

What I Saw First

The first thing I noticed during the PCAP Analysis was how noisy the traffic looked.

At first glance, nothing immediately screamed malware.

Most of the traffic looked like:

• HTTP
• DNS
• SSL
• normal outbound connections

One of the first queries I kept using was:

cut id.orig_h, id.resp_p, id.resp_h | sort | uniq -c | sort -r

This became one of the quickest ways to identify:

• top talkers
• unusual connection frequency
• suspicious external IP addresses

Then I started pivoting into:

_path=="conn"

and:

_path=="dns"

because DNS volume usually reveals a lot during Threat Hunting with Brim.

Why It Looked Normal

Honestly, this is where I struggled a bit. The traffic initially blended in very well.

A lot of the ports looked normal:

• 80
• 443
• DNS traffic
• SSL traffic

Even the HTTP requests did not immediately look malicious until I started sorting and counting things properly.

One mistake I usually make early during PCAP Analysis is focusing too much on single packets instead of traffic behaviour.

Once I slowed down and looked at:

• frequency
• repeated domains
• POST requests
• response sizes
• suspicious user agents

the picture started becoming clearer.

What Felt Off

The first major red flag was the DNS behaviour. Some domains looked completely abnormal.

I started using:

_path=="dns" | count() by query | sort -r

That immediately exposed strange repetitive DNS queries.

Then during Malware C2 Detection, I noticed suspicious outbound communication repeatedly hitting the same infrastructure.

Another thing that felt off was:

• repeated POST requests
• executable downloads
• strange URI paths
• uncommon ports like 6666 and 8888
• massive byte transfers

This query helped a lot:

_path=="conn"
| put total_bytes := orig_bytes + resp_bytes
| sort -r total_bytes

That was one of the moments where the investigation shifted from “maybe suspicious” to clearly malicious activity.

Where I Got It Wrong

One thing I got wrong initially was assuming Suricata alerts would immediately solve everything.

I relied too heavily on:

event_type=="alert"

too early.

But I later realized the real value came from correlating:

• DNS logs
• HTTP logs
• connection behaviour
• file downloads
• Suricata signatures

together.

Another mistake I made was ignoring HTTP response sizes early on.

Later, I discovered suspicious payload delivery by filtering things like:

_path=="http" response_body_len==1309

That helped identify malware delivery infrastructure.

I also learned that during Threat Hunting with Brim, the real investigation usually happens in the pivots between logs.

Not inside one single log source.

What Changed My Thinking

What changed my thinking most was realizing how important traffic baselining is during Malware C2 Detection.

Instead of asking:

“Where is the malware?”

I started asking:

“What behaviour looks different from normal?”

That mindset shift changed everything.

I started focusing more on:

• traffic patterns
• repeated connections
• suspicious DNS activity
• binary downloads
• C2 communication behaviour

Some of the most useful queries I used repeatedly were:

DNS Analysis

_path=="dns"
| count() by query
| sort -r

HTTP Investigation

_path=="http"
| cut id.orig_h, id.resp_h, method, host, uri

Suricata Alerts

event_type=="alert"
| count() by alert.category

POST Request Hunting

_path=="http" method=="POST"

Suspicious Downloads

_path=="http"
| grep ".exe"

These queries became some of my favourite quick hunting pivots during the PCAP Analysis workflow.

My Final Conclusion

This lab was one of the practical Threat Hunting with Brim exercises I have worked through so far.

It connected:

• Malware C2 Detection
• DNS analysis
• Suricata alert investigation
• PCAP Analysis
• IOC validation
• threat intelligence enrichment

into one workflow.

Some of the malicious activities identified included:

• Cobalt Strike C2 traffic
• Meterpreter activity
• Dridex indicators
• suspicious executable downloads
• crypto mining traffic
• stealer malware behaviour

The biggest lesson for me was learning how attackers can hide inside what initially looks like normal network traffic.

What I Would Do in a Real SOC

If I encountered this during a real SOC investigation, I would:

Immediately isolate affected endpoints

Especially systems showing:

• repeated POST requests
• C2 beaconing
• malicious downloads
• crypto mining behaviour

Block malicious infrastructure

Including:

• malicious domains
• external IP addresses
• suspicious DNS queries

Hunt across the environment

I would search for:

• matching user agents
• repeated DNS requests
• same executable hashes
• identical Suricata signatures
• similar outbound traffic patterns

Validate indicators with threat intelligence

Using:

• VirusTotal
• URLhaus
• Abuse.ch
• MalwareBazaar

Review detection coverage

I would also improve:

• Suricata rules
• DNS monitoring
• outbound traffic monitoring
• anomaly detection thresholds

because some of the malware traffic blended in surprisingly well.

Did you know about the popular Warzone- Check it out: Warzone Malware Investigation Alert Triage

Visit my everyday playground here