Packets, Clues, and Coffee: A Wireshark Investigation Story

Sometimes the best way to learn is to get your hands dirty. That’s exactly what I did when I tackled a Malware Traffic Analysis exercise.

It wasn’t just another packet capture, it was a crime scene, and my job was to figure out who did what, when, and how.

Setting the Scene

The packet capture (PCAP) was buzzing with background noise from routers, smart devices, and other chatter. My mission? Find the infected Windows machine, figure out who used it, identify any fake websites it reached out to, and uncover the command-and-control (C2) servers that kept the infection alive.

Step 1: Finding the Infected IP

My first move was to clean up the view in Wireshark. I didn’t want to see every little broadcast or IoT heartbeat. I only cared about web traffic, both HTTP and HTTPS.

So I used this filter: (http.request or tls.handshake.type eq 1) and !(ssdp)

This simple line told Wireshark, “Show me only the good stuff.”

And just like that, the infected client revealed itself: 10.1.17.215.

Tip: Using tls.handshake.type == 1 includes encrypted HTTPS traffic by showing Client Hello packets. Perfect when you want to see who’s talking even if you can’t read what they’re saying.

Step 2: The MAC Address

With the IP in hand, the next question was, “Which device is this, really?”

The Ethernet II section in the packet details held the answer: 00:d0:b7:26:4a:74.

That MAC address told me exactly which machine was infected on the local network.

It’s like finding the fingerprints at the scene.

Step 3: The Hostname

I switched filters and looked at DHCP packets using "dhcp"

Matching the same IP and MAC led me to the hostname: DESKTOP-L8C5GSJ. Now I had the victim's "name tag".

Step 4: Who Was Logged In?

This part was trickier. I needed to find the username of whoever was logged into the infected computer.

After scrolling through packets, expanding fields, and trying a few different filters, I finally struck gold with this one: kerberos.CNameString

And there it was — shutchenson.

That felt like discovering the main suspect after hours of detective work.

 

Step 5: The Fake Google Authenticator Page

Next up: finding the fake website that started it all.

I checked every domain the client queried using this filter: dns.qry.name

Two domains jumped out at me:

• google-authenticator.burleson-appliance.net
• authenticatoor.org

Both looked suspicious, but authenticator.org was the real culprit. It had that "too clean to be real" vibe. Simple, believable, and likely crafted to fool users into downloading something malicious.

 

Step 6: Tracking the C2 Servers

This was the part that tested my patience.

I needed to figure out which IPs the infected machine was talking to after it got infected—those would likely be the command and control servers.

I started by filtering outbound HTTP GET requests from the infected IP using http.request.method == "GET" and ip.addr == 10.1.17.215

That led me to 5.252.153.241. This IP kept receiving repetitive GET requests to small paths like /1517096937 and /api/file/get-file/....

Repetitive, tiny requests like that are often signs of a beacon calling home to a C2 server.

But I wasn’t done yet.

I widened my filter with ip.src == 10.1.17.215

That’s when I spotted something even stranger—continuous TCP ACK packets going to 45.125.66.32 on port 2917.

That port isn’t used by any common service, and there were no web headers or normal data. The connection just… stayed open.

Bingo. Another C2 server.

So I ended up with two likely suspects:

• 5.252.153.241
• 45.125.66.32

Wrapping Up

By the end of the exercise, I had mapped the infection from start to finish:

• Found the infected client (10.1.17.215)
• Identified the device (DESKTOP-L8C5GSJ)
• Uncovered the user (shutchenson)
• Flagged the fake domain (authenticatoor.org)
• Discovered two C2 servers (5.252.153.241 and 45.125.66.32)

This lab not only improved my packet analysis skills but also reminded me how powerful it is to see the story behind the data. So next time you’re staring at a noisy capture file, remember, every infection leaves a trail. You just need the right filters and a bit of patience to uncover it.