The question: how do you tell from a packet capture whether a device is beaconing out to a suspicious address, and what does an ordinary IoT device look like by comparison? I would like to compare methods, because most of what I see written on this skips the part where you learn what normal looks like first.
The short answer is that you cannot judge a device's traffic until you have a baseline. A smart plug that talks to a cloud service every thirty seconds is not suspicious. The same plug talking to an address in a country you have no reason to talk to, at a perfectly steady interval, at 3 a.m., deserves a closer look. The difference is context, and context comes from watching the device when you believe it is healthy.
What normal IoT chatter tends to look like
- A DNS lookup for a small number of vendor hostnames, repeated on a schedule or after a reboot.
- NTP requests to a public time server or the vendor's own.
- A long-lived TLS connection to one cloud endpoint, with small keepalive packets.
- Occasional local traffic: mDNS, SSDP, or DHCP renewals.
The pattern is narrow. Few destinations, few protocols, small packets. If a device does something outside that list, write it down and find out why.
What beaconing tends to look like
Beaconing is regular, small, and persistent. A client checks in with a server at a fixed or nearly fixed interval, sends a little data, and goes quiet again. Things I look for:
- Connections to the same destination at evenly spaced intervals. Some malware adds random jitter, so "almost regular" counts.
- Packets of nearly identical size in each exchange.
- A destination that the device never looked up by name, meaning a bare IP address with no preceding DNS query.
- DNS queries for long, random-looking hostnames, or a high volume of queries to one domain.
- Traffic on odd ports, or TLS on a port where you would not expect it.
None of these proves anything alone. Plenty of legitimate software polls on a timer. A weather widget is regular too. Regularity is a reason to ask a question, not a verdict.
A starting point
Capture at the firewall or a mirror port, filtered to the one device, so you are not drowning in noise:
tcpdump -i igb1 -w camera.pcap host 192.168.30.45
Then list the conversations and the DNS names it asked for:
tshark -r camera.pcap -q -z conv,tcp
tshark -r camera.pcap -Y dns.flags.response==0 -T fields -e dns.qry.name | sort | uniq -c | sort -rn
To check timing, export the frame times for one destination and look at the gaps between them. A column of nearly identical gaps is the thing you are hunting for.
One caution. Encrypted traffic hides the content, so you are judging behavior, not payload. I cannot tell you that timing analysis alone is enough to call a device compromised, and I would not claim it is. It tells you where to look next.
Two questions for the group. How long do you capture to build a baseline before you trust it? And do you do this at the firewall, or do you run a dedicated mirror port? Report back.