Wireshark for Beginners · lesson 2 · 2026-10-01

Wireshark for Beginners Part 2 — Spot Suspicious Traffic on Your Network

▶

Before you start

• A Kali Linux machine or VM with tshark (preinstalled on Kali) and python3.
• Permission to capture packets: run as root with sudo, or add your user to the wireshark group.
• A loopback-only practice setup that plays an infected machine for 15 seconds: a tiny web server on 127.0.0.1:4444, a client that checks in with it every 2 seconds, and a few DNS lookups sent to 127.0.0.1:53 (use only .example names, and make sure nothing is listening on port 53).
• A writable working folder for suspicious.pcapng.
• Only test systems you own or are authorized to test.

Look at these five numbers. Something on this computer is quietly phoning home every two seconds, like clockwork, and Wireshark just caught it.

Here’s the proof, read straight out of a real capture we just took.

tshark -r suspicious.pcapng -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' -T fields -e frame.time_relative -e ip.dst -e tcp.dstport

Zero seconds, two seconds, four, six, eight. Same address, same strange door number, four four four four, every two seconds. Real people don’t browse like that. Programs that check in with someone do.

That’s where we’re headed. Now let’s restart from zero and build up to it, one step at a time, so you can do this yourself.

Quick recap of part one, in case you’re new here.

What you need to know

• Network traffic travels as small chunks called packets
• Wireshark reads those packets; tshark is its command-line version
• A capture filter decides what gets SAVED while listening
• A display filter decides what gets SHOWN from what was saved

Everything on a network travels in small chunks called packets. Wireshark is the tool that reads them, and tshark, spelled t-shark, is its command-line version, which is what we type today. In part one we learned the two kinds of filters: a capture filter decides what gets saved while we listen, and a display filter decides what we’re shown afterward. If any of that is new, part one is linked in the description, but you can follow along without it.

Today’s question is different. Last time we asked: what’s inside this traffic? Today we ask: does this traffic look normal?

What makes traffic suspicious?

• Defenders don’t read every packet — they look for PATTERNS
• Red flag 1: an unusual door number (port)
• Red flag 2: beaconing — checking in on a perfect schedule
• Red flag 3: strange, random-looking website names

Security defenders almost never read every single packet. There are far too many. Instead they look for patterns that don’t fit. Today we’ll hunt three classic red flags. One, traffic going to an unusual port. Two, beaconing, which is a program checking in with someone on a perfect, regular schedule. And three, strange random-looking website names being looked up. Any one of these can be innocent. Together, they’re worth a closer look.

Two words before we start: port, and beacon.

Port and beacon

• Port: a numbered door on a computer — web traffic uses 80 and 443
• Uncommon ports like 4444 deserve a second look
• Beacon: a program contacting the same place at regular intervals
• Malware beacons to its controller to ask: any orders for me?

A port is a numbered door on a computer. Each kind of service listens behind its own door. Websites normally use door 80, or door 443 for the secure version. When you see traffic going to an unusual door, like 4444, that’s worth a second look, because some well-known hacking tools use that number by default. A beacon is a program that contacts the same place over and over at regular intervals. Infected computers often do this, checking in with the attacker’s server to ask, do you have any orders for me?

So where does our suspicious traffic come from? We built it ourselves.

Our pretend infected machine

• A tiny practice server on this computer, behind door 4444
• A pretend program that checks in with it every 2 seconds
• Normal website lookups mixed with random-looking ones
• Everything stays on this one machine — nothing real is involved

To practice safely, we set up a pretend infected machine. A tiny practice server runs on this computer behind door 4444. A pretend program checks in with it every two seconds. And mixed in, there are some normal website lookups and some random-looking ones. All of it stays inside this one computer, and the website names all end in example, a name reserved for practice, so nothing real is ever contacted.

Step one: capture the traffic.

Step 1 — record 15 seconds of traffic

tshark -i lo -f "udp port 53 or tcp port 4444" -w suspicious.pcapng -a duration:15

Open the terminal window. Dash i l-o listens on loopback, the computer talking to itself. Dash f is our capture filter: udp port 53 keeps website-name lookups, which always use door 53, and tcp port 4444 keeps anything going to our suspicious door. Dash w saves it all to a file called suspicious dot pcap n g. Dash a duration colon fifteen stops after fifteen seconds. While it listens, our pretend infected program does its thing.

Type the command and press Enter.

A few dozen packets, saved to the file. Now we investigate, starting from the big picture.

Step two: get an overview of what’s in the file.

Step 2 — what kinds of traffic are here?

tshark -r suspicious.pcapng -q -z io,phs

A protocol is just a set of rules for how computers talk, like a language. Dash r reads our saved file. Dash q means quiet, so we don’t print every packet. And dash z io comma p h s asks for protocol hierarchy statistics, which is a family tree of every protocol in the capture and how many packets each one used. Type it and press Enter.

Read it like a family tree. Under udp we have dns, that’s website-name lookups. Under tcp we have http, that’s web traffic. So this file holds two things: someone looking up website names, and someone talking to a web server. Nothing alarming yet. Now let’s zoom in.

Step three, red flags one and two: who is connecting, to which door, and when?

Step 3 — list every new connection

tshark -r suspicious.pcapng -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' -T fields -e frame.time_relative -e ip.dst -e tcp.dstport

Every new connection starts with a special packet called a SYN, short for synchronize, like knocking on the door. Our display filter, tcp dot flags dot syn equals equals one, and tcp dot flags dot ack equals equals zero, picks out only those first knocks, so we see each connection exactly once. Dash capital T fields says print only the columns we ask for. Then three dash e options choose the columns: the time in seconds since the capture started, the destination address, and the destination door number.

Type it and press Enter.

Here’s our opening shot. Look at the last column first: every connection goes to door 4444, not 80 or 443. That’s red flag one, an unusual port. Now look at the first column: zero, two, four, six, eight seconds. Exactly two seconds apart, every time. That’s red flag two, beaconing. A person clicking around a website is messy and random. A perfect rhythm means a program, on a timer.

Step four: what is that program actually saying?

Step 4 — read the check-ins

tshark -r suspicious.pcapng -d tcp.port==4444,http -Y http.request -T fields -e http.request.uri -e http.user_agent

Wireshark guesses what language traffic speaks by its door number. Door 4444 isn’t a normal web door, so we have to tell it. That’s what dash d does, short for decode as: tcp dot port equals equals 4444 comma http means treat door 4444 as web traffic. Then our display filter shows only web requests, and two columns: the page it asked for, and the user agent, which is the name a program gives itself when it connects. Type it and press Enter.

Five times, the same page: slash check in. And the user agent says curl, which is a command-line tool, not a web browser. So it isn’t a person on a website. It’s a script, checking in. In real life, that’s exactly how a lot of infected machines talk to their controllers.

Step five, red flag three: what website names were looked up?

Step 5 — list every name lookup

tshark -r suspicious.pcapng -Y 'dns.flags.response==0' -T fields -e dns.qry.name

Before your computer can visit a website, it has to look up the name, like checking a phone book. That’s called DNS. Our filter, dns dot flags dot response equals equals zero, shows only the questions, not the answers. And dash e dns dot q r y dot name prints just the name being looked up. Type it and press Enter.

Some of these look normal: w w w dot example dot com, mail dot example dot com, update dot example dot org. Words a human would pick. But look at the others: k q 7 v z 2 x w 9 p. That’s not a word anyone would type. Some malware generates random names like these on purpose, so defenders can’t simply block one address. A burst of gibberish names is red flag three.

So you spot this on a real network. What now?

Found a red flag? Next steps

• Find WHICH device: filter with ip.addr == <its address>
• Find WHICH program: ss -tp on Linux, netstat -ano on Windows
• Look up the domain or address on a reputation site
• Don’t panic-delete — disconnect the device, then investigate

First, find which device it is. The display filter ip dot addr equals, followed by an address, shows everything one device said. Second, find which program on that device is doing it: ss dash t p on Linux, or netstat dash a n o on Windows, lists connections along with the program that owns each one. Third, look up the strange names or addresses on a reputation site to see if they’re known to be bad. And don’t panic-delete things. Disconnect the device from the network first, then investigate calmly, so you don’t destroy the evidence.

Remember, none of these red flags is proof on its own.

Red flags, not verdicts

• Update checkers and apps also check in on a schedule
• Some legitimate services use random-looking names
• Combine clues: odd port + perfect rhythm + gibberish names
• Only capture on networks you own or are allowed to monitor

Plenty of normal software checks in on a schedule, like update checkers and chat apps, and some legitimate services use random-looking names too. That’s why defenders combine clues. An unusual door, plus a perfect rhythm, plus gibberish names, all from the same device: that’s when you dig in. And as always, only capture traffic on a network you own or have written permission to monitor. Everything in this video happened inside one computer, talking to itself. Thanks for learning with The Exploit HQ, and I’ll see you in the next one.