Reggie and the Chonky Pings: Adventures in ICMP Tunnelling
There are two kinds of network traffic: the stuff you expect, polite HTTP calls, earnest software updates, and the occasional desperate Zoom feed, and the stuff that looks exactly like the first lot but is actually committing crimes in a bowler hat. ICMP sits firmly in the first category: a bland, useful protocol used for diagnostics and keeping routers from having panic attacks. Which, naturally, makes it perfect for criminals with a fondness for hide-and-seek.
Before you reach for the “block everything” button like it’s a magic wand, remember this: ICMP is useful. It helps engineers establish whether a host is alive, assists in path MTU discovery, and generally keeps the network from falling into confused silence. Strip it away entirely and your helpdesk tickets multiply like poorly-tested microservices. So instead of outright banning the protocol, the sensible approach is to accept that it will exist, and therefore accept that someone, somewhere, will sooner or later try to abuse it.
Enter our unlikely hero (and office morale hazard): Reggie the Raccoon. Reggie likes two things, digging up ancient, embarrassing network artefacts (which he calls “fossils”) and writing nasty little Bash scripts that make firewalls sweat. He wears a teacup helmet, drinks the kind of coffee that should be illegal, and has opinions on everyone’s SSH key rotation schedule. Reggie is the kind of analyst who will happily crawl through 20,000 packets at 3 a.m., humming under his breath, while muttering “there’s your exfiltration right there” like it’s a bedtime story.
Why bring Reggie into a serious piece about covert channels? Because cybersecurity is less about shiny tools and more about grimy, patient elbow-grease. The people who find the malicious things hiding in protocols are rarely the vendors with marketing budgets; they’re the sleep-deprived engineers who know how to read a packet dump with affection and suspicion in equal measure. Reggie is them, the in-house observer who knows that if something’s allowed without scrutiny, someone will eventually shove business-critical data through it.
The trick with protocols like ICMP is their dual-use nature. They’re essential for network health, which gives them a kind of diplomatic immunity: “oh, that’s just ping traffic” becomes a reflex in many teams. Malicious actors lean on that reflex. Rather than trying to blast their way through a well-guarded port, they wrap their traffic up in packets that look like routine diagnostics, and hope the gatekeepers are too polite to ask questions.
This is not niche trickery; it’s the current flavour of laziness in adversary TTPs (Tactics, Techniques, and Procedures). Attackers prefer to “live off the land”: reuse trusted services, co-opt legitimate protocols, and never give defenders the obvious signatures they could block with a single rule. DNS, HTTPS, SMB, and, yes, ICMP are all fair game. If you run a network with lots of legacy systems, liberal egress rules, and a philosophy of “we’ll deal with it if it breaks,” you might as well put a neon sign above your perimeter that reads please exfiltrate here.
The defensive pivot is straightforward in concept but awkward in execution: stop thinking about “ports are open or closed” and start thinking about behaviour. What does normal look like for ICMP on your estate? How often should an endpoint ping an external server? What sizes do ping payloads usually have? What are the rhythms and the oddities that tell a human analyst, or a decent detection engine, that something is not a clipboard-and-coffee network check but a clandestine link carrying a reverse shell?
That’s where Reggie’s scratches in the packet dust come in handy. The upcoming sections will walk through the anatomy of an ICMP-based covert channel, the practical forensic fingerprints it leaves (size, randomness, and obsessive frequency), and a practical, no-nonsense Bash detection script Reggie insists on calling “The Bouncer.” We’ll also cover why this problem isn’t just an ICMP thing, it’s emblematic of a larger cultural problem in IT security: the tendency to trust convenient protocols until they betray us.
So, make yourself another cup of that suspicious office coffee, get comfortable, and prepare to meet the bits of your network you never knew could be smugglers. Reggie has already started digging; he found a fossil in the routing table and is halfway through a script that will make your firewall blush.
Why ICMP? Because humans like things that just work
Long before the internet became a seething pit of ransomware, crypto scams, and poorly-secured toasters, it was a rather polite place. Computers spoke to one another in well-mannered tones, networks were small enough to draw on a napkin, and nobody thought twice about letting packets wander wherever they pleased. This was the golden age of bearded computer enthusiasts, the sort who wore UNIX T-shirts, quoted RFC numbers like scripture, and genuinely believed that “security through good intentions” was a viable strategy.
And in that utopian haze of Ethernet innocence, a protocol called ICMP was born. Defined in 1981’s RFC 792 (Postel, 1981), it was never meant to carry your darkest secrets, just to help machines talk about their feelings. “Host unreachable,” “destination too big,” “echo request,” “echo reply”, these were the small-talk phrases of network civilisation. ICMP was the polite cough between routers, the “excuse me” of packet exchange, the gentle nudge that kept the whole thing from collapsing under its own confusion.
The bearded architects adored it. They saw ICMP as elegant, essential, and far too dignified to ever be abused. Who would possibly use ping, the internet’s equivalent of tapping a microphone and saying “is this thing on?”, for anything nefarious? It was diagnostic, noble, pure. They wrote ping utilities with payloads that carried cheerful repeating byte patterns or timestamps, the digital equivalent of whistling while you work. And they never imagined that, forty-odd years later, someone would be stuffing those same packets with encrypted command-and-control traffic and smuggling it past a corporate firewall guarded by an overworked intern.
The irony is exquisite. ICMP exists precisely because humans crave things that “just work.” It was built to make network troubleshooting instant, a one-packet answer to the question, “is this thing alive?” Firewalls, intrusion detection systems, and all the barbed wire we later wrapped around our networks came after. ICMP was already there, baked into every operating system and appliance, happily chatting away with no authentication, no encryption, and absolutely no sense of boundaries.
That convenience became doctrine. Blocking ICMP outright is technically possible but practically suicidal. Without it, the simplest diagnostic tasks, discovering whether a host is up, finding the path packets take, identifying fragmentation issues, become miserable exercises in timeouts and guesswork. Network engineers quickly learn that a world without ping is a world full of panic. So, even in 2025, after four decades of security disasters, most organisations still leave ICMP enabled because the alternative is watching their NOC (Network Operations Center) teams stage a mutiny.
Of course, the bad guys noticed. If something is allowed everywhere and almost never inspected, it’s effectively a tunnel with a “free passage” sign over the door. The moment defenders learned to block suspicious ports and protocols, attackers began looking for anything not blocked, and there sat ICMP, the digital equivalent of an unlocked side gate.
That’s how we ended up here: a protocol designed to say “hello” quietly repurposed to whisper secrets out of your network. Each innocent-looking echo request might be a carrier pigeon for stolen credentials. And the best part? Most security tools still wave them through with a polite nod, because ping has always been considered “safe.”
Reggie the Raccoon, naturally, finds this hilarious. He calls ICMP “the world’s oldest VPN,” and he’s not wrong. When he’s not elbow-deep in packet captures, he likes to read old RFCs aloud in a reverent whisper, muttering about how the pioneers trusted everything with an IP address. “They thought the internet was a library,” he grumbles, “not a den of thieves.” Then he takes another swig of his industrial-strength coffee and adds, “Bless ’em. Without their optimism, half my job wouldn’t exist.”
So yes, ICMP persists because humans, bless our lazy souls, prefer convenience over caution. We’ll tolerate a silent risk if it means our ping works and our network graphs stay green. And that’s exactly why attackers adore it. They don’t need zero-days (IBM, no date) when they can simply ride along with humanity’s oldest configuration error: blind trust in the things that just work.
The Anatomy of an ICMP Tunnel (A Love Story Between Echo and Obfuscation)
Let’s start with the basics: ICMP tunnels are like smuggling contraband through airport security by hiding it in a tray of sandwiches. The sandwich, the ping packet, looks perfectly innocent. The contraband, your encrypted commands or stolen data, sits harmlessly between two slices of diagnostic bread. To the firewall’s tired eyes, it’s just another lunchbox headed out of the network.
At a protocol level, ICMP is breathtakingly simple (Rosen, 2014). A ping, officially an Echo Request, is just a small packet that says, “Hello, are you there?” The recipient (if it’s a decent citizen) sends back an Echo Reply: “Yes, I’m alive, thanks for asking.” Both messages can carry a payload, which is a polite way of saying “random bytes that nobody checks very closely.” That payload might be a timestamp, a repeating pattern, or whatever the sender decides to include. The RFC doesn’t care. It doesn’t even specify how long that payload should be, just that it fits within the total packet size limit. In the 1980s, this flexibility was a feature. In 2025, it’s a security nightmare with a vintage logo.
Now, here’s where the magic, or horror, happens. Someone, somewhere, realised that because the payload is arbitrary, you could use it to carry anything. Instead of a timestamp, you could stuff a slice of another protocol inside it, say, a TCP packet, and send that to another machine. That second machine could unwrap the TCP packet, forward it on, and when it gets a response, it can do the same trick in reverse: shove the reply inside an ICMP Echo Reply and fling it back. Congratulations: you’ve just created a bidirectional tunnel using the world’s most boring diagnostic tool.
Reggie the Raccoon explains it best. He calls ICMP tunnelling “ping pong with a hidden payload.” On one side is the compromised client inside your network; on the other, an attacker-controlled server on the internet. Every Echo Request carries data from the inside out. Every Echo Reply carries data from the outside in. To anyone watching casually, it’s just a long game of ping-pong, except the ball is stuffed with stolen spreadsheets.
Let’s break it down into its cast of characters:
1. The Client (the mole inside your network)
This is the compromised machine. It runs some sneaky software, often downloaded during a phishing attack or planted by malware, that hijacks outbound connections. When the malware wants to talk to its handler (the attacker’s Command-and-Control server), it wraps the outgoing data into the payload of an ICMP Echo Request. It’s polite, well-behaved, and goes out on port zero, which most firewalls simply wave through without inspection.
2. The Proxy or Command-and-Control (C2) Server
Out on the internet sits a server waiting for those special Echo Requests. It listens for packets from its pet client, unwraps the hidden data, and forwards it to its true destination, whether that’s a remote shell session, a web request, or another protocol entirely. When a response comes back, it reverses the trick: wraps the data into an Echo Reply and fires it back into your network.
3. The Channel (the “tunnel” itself)
This back-and-forth forms a covert, bidirectional data stream, a full-blown tunnel. Think of it as a tiny, secret VPN made out of pings. It’s not fast. It’s not stable. It’s not glamorous. But it works, and for an attacker, that’s all that matters. Firewalls and intrusion detection systems generally ignore ICMP or only look for flood attacks, not covert payloads. The tunnel sails right through, masquerading as diagnostic noise.
There are plenty of tools that make this trick dead simple:
- ptunnel / ptunnel-ng — a veteran of the tunnelling underworld. It lets you proxy TCP traffic through ICMP with minimal fuss.
- icmpsh — a leaner option that provides an ICMP-based reverse shell. Attackers love it because it’s lightweight and blends in with normal ping traffic.
- hping3 — not a tunnelling tool by design, but versatile enough to craft custom packets, including those with payloads that look suspiciously like file fragments.
In short: if you can ping, you can tunnel, provided you’re unscrupulous and clever enough.
Reggie, ever the drama queen, compares this to a postal scam. “It’s like stuffing a love letter inside a tax form,” he says. “The post office just stamps it and sends it on, none the wiser.” He’s not wrong. ICMP was never designed to not carry data; it just wasn’t designed to carry meaningful data. Attackers exploit that vagueness like it’s a legal loophole written by a hungover standards committee.
The result is what security researchers call protocol-level steganography: hiding one form of communication inside another (Mazurczyk et al., 2016). It’s not encryption; it’s camouflage. The malicious traffic isn’t hidden by secrecy, it’s hidden in plain sight. To a human or a simple firewall rule, everything looks normal. Packets go out, packets come back, connectivity checks succeed, and nobody asks why a workstation is “pinging” the same IP address every half-second for twelve hours straight.
And this is why Reggie gets twitchy whenever someone says “we don’t need to log ICMP.” Because ICMP is the quiet corridor everyone forgets to lock. In its payloads, entire conversations can take place, reverse shells, file transfers, even HTTP traffic disguised as diagnostic chatter. It’s all just data at the end of the day, and if your tools only look at TCP and UDP ports, ICMP might as well be wearing an invisibility cloak.
So, when you next see a long list of pings in your network logs, remember: it might be an engineer testing connectivity… or it might be someone tunnelling out your customer database at 64 bytes per packet. The packets themselves won’t tell you, not unless you start looking at what’s inside the echo.
That’s the dark romance of ICMP tunnelling: two ends whispering sweet encrypted nothings through a protocol too polite to interrupt.
How to Spot the Liar: The Three Forensic Fingerprints of ICMP Tunnels
Let’s be honest: if you’re defending a network, your logs are full of liars. Every protocol swears it’s innocent, every endpoint insists it’s just “pinging for diagnostics,” and your SIEM pretends it understands context. The truth? Somewhere in that pile of packets, a criminal is whispering through ICMP, grinning because you never bothered to baseline your ping traffic.
But ICMP, like every liar, has tells. Three of them, in fact. Detect these and you’ll ruin an attacker’s day faster than you can say “who authorised outbound Type 8 Echo Requests again?”
1. The Suspiciously Fat Ping (Payload Size Anomaly)
Let’s start with the easiest giveaway: packet obesity. Normal pings are trim little things, models of efficiency. On Windows, the default ping payload is 32 bytes (60 on the wire once headers are added). On Linux or macOS, it’s 56 bytes (84 on the wire). Engineers rarely change that unless they’re doing MTU (the Maximum Transmission Unit) tests or feeling particularly adventurous (Okta, 2025).
Now, when someone builds a covert ICMP tunnel, they start cramming entire IP packets inside those payloads. A minimal TCP packet (20-byte IP header + 20-byte TCP header) already eats 40 bytes. Add even a sliver of application data, and you’re in the hundreds. File transfers or interactive sessions? You’re looking at payloads north of 500–1000 bytes. That’s not “ping.” That’s “please investigate me immediately.”
Reggie the Raccoon calls these “chonky pings.” When he sees an Echo Request with a payload of 1024 bytes, he doesn’t think “diagnostics.” He thinks “someone’s running a reverse shell and hoping I don’t notice.” He then mutters something unspeakable about firewall admins and opens another terminal.
The beauty of this indicator is how cheap it is to check. You don’t need deep packet inspection or machine learning; you just need to know what “normal” looks like. Capture a week of benign traffic, calculate an average payload size per host, and set a threshold. Anything consistently over that threshold is either an engineer breaking things on purpose (likely) or an attacker breaking things on principle (also likely).
The rule of thumb: if a host’s ping packets are consistently larger than your sense of optimism, start digging.
2. The Encrypted-looking Ping (Payload Uniqueness and Entropy)
The second tell is subtler but just as damning: randomness. A legitimate ping payload is predictable, it’s either a static string, a timestamp, or a neat repeating pattern (0x61, 0x62, 0x63…). It’s the network equivalent of small talk: consistent, boring, and utterly devoid of imagination.
A tunnel, however, has to carry real data, keystrokes, file chunks, shell commands, and those change constantly. To make things worse (for you), attackers often encrypt or base64-encode that data to make it harder to spot. The result is high-entropy payloads, full of bytes that look like noise.
Entropy, for the uninitiated, is a measure of randomness. Text, timestamps, and repeating bytes have low entropy (easy to compress, predictable). Encrypted or compressed data has high entropy (looks like static). If you calculate Shannon entropy per payload and start seeing values near 8 bits per byte, congratulations: you’ve just found something pretending to be chaos (Konicanin, 2024).
You don’t need to run full statistical analysis to detect this, though. Even a simple checksum comparison between consecutive pings from the same host can reveal that payloads are all different. Legitimate diagnostic traffic is dull, every ping’s payload looks just like the last. Tunnels, on the other hand, never repeat because each packet carries a new slice of whatever the attacker is sending.
Reggie likes to visualise it as an art project. He once generated a heatmap of ICMP payloads from a suspected tunnel, normal traffic looked like gentle stripes of uniformity; the tunnel looked like a Jackson Pollock painting. “Entropy,” he said, sipping from a mug labelled World’s Saddest Packet Analyst, “is just chaos with a payload.”
So, if your pings start looking like static, you’re not troubleshooting a connection. You’re harbouring a fugitive.
3. The Obsessive Pinger (Traffic Volume and Frequency)
Finally, the behavioural tell, the human pattern in the machine noise. Most people ping like they breathe: occasionally, gently, and with purpose. They run ping for a few seconds to see if a host responds, then stop. A normal admin might leave it running a minute during testing. That’s it. The rest of the time, ICMP traffic is background chatter, a few packets here and there for network health.
A tunnel doesn’t have that restraint. It needs a constant back-and-forth to be useful. Each keystroke in a reverse shell, each data chunk in an exfiltrated file, means another ICMP Echo Request and Reply. The result? A steady, rhythmic heartbeat of packets between one host and one external IP address. Thousands per hour. Identical timing intervals. Always to the same destination.
If you plotted that on a graph, it would look less like human diagnostics and more like a possessed metronome.
The trick is to establish a baseline for “normal” ICMP frequency on your network. If you see a host suddenly generating hundreds of Echo Requests every minute, or maintaining a continuous ICMP session for hours, it’s either running a misconfigured monitoring agent or it’s been colonised by someone who thinks data exfiltration via ping is funny.
Reggie finds this pattern almost poetic. “Attackers think they’re invisible,” he says, scrolling through a capture. “But they all leave the same rhythm, tick, tick, tick, like a bad techno track. If you can hear the beat, you can find the DJ.”
From a practical perspective, correlating volume with packet size and payload uniqueness is deadly accurate. One anomaly is suspicious. Two together are incriminating. Three? That’s a confession in binary.
The Unholy Trinity in Practice
The reason these three indicators work so well is that they represent the physical laws of tunnelling. To smuggle data, you must send more of it (size). To make it useful, it must change (entropy). And to keep the conversation alive, you must do it constantly (frequency). Each of those necessities bends ICMP’s natural behaviour just enough to expose the lie.
And the best part? You don’t need enterprise tools or AI-driven nonsense. Reggie detects all of it with a Bash script and an attitude problem. He doesn’t care what marketing calls “zero trust” (Cloudflare, 2025), he just doesn’t trust anything that pings too enthusiastically.
In short: if you want to catch an ICMP tunnel, don’t chase ghosts, chase patterns. Look for fat packets, noisy payloads, and obsessive behaviour. The moment you see a host that pings like it’s trying to reach the afterlife, you’ve found your tunnel.
A no-nonsense detection tool: the Bash + tcpdump script (copy, paste, adapt, profit)
Yes, the world increasingly uses fancy NDR platforms. No, not every small SOC has a budget for Sentinels built from unicorn tears. The following script was designed to be simple, portable, and effective: run it on any Linux box with tcpdump, watch the console, and it will call out hosts that meet your suspicious-size-and-frequency thresholds. It’s the practical result of wrapping a stateful logic layer around the otherwise stateless tcpdump. The logic and parameters are sensible defaults, but you should tune them for your network.
Save as detect_icmp_tunnel.sh and run with root. (I told you to be brave; this is not rocket surgery.)
#!/bin/bash
# --- Configuration ---
# The network interface to monitor. Use 'ip a' to list interfaces.
INTERFACE="eth0"
# ICMP payload size (ICMP header + data) that triggers suspicion.
# Default pings are ~60-84 bytes on the wire. 100 is a conservative starting point.
SUSPICIOUS_SIZE_THRESHOLD=100
# Number of suspicious packets from a single IP before alerting.
ALERT_THRESHOLD=5
# Time window in seconds to reset counters, preventing alerts on long-tailed events.
TIME_WINDOW=300
# --- Initialization ---
declare -A suspicious_counts
declare -A last_seen
echo "Starting ICMP tunnel detection on interface ${INTERFACE}..."
echo "Alerting on hosts sending ${ALERT_THRESHOLD} packets with payload size > ${SUSPICIOUS_SIZE_THRESHOLD} bytes within a ${TIME_WINDOW}s window."
echo "--------------------------------------------------------------------------------"
# --- Main Loop ---
tcpdump -lni "${INTERFACE}" "icmp and 'icmp[icmptype] == icmp-echo'" | while read -r line; do
current_time=$(date +%s)
# Extract source IP and the length reported by tcpdump (last field).
src_ip=$(echo "${line}" | awk '{print $3}')
length=$(echo "${line}" | awk '{print $NF}')
# If tcpdump output has different formatting in your distro, you may need to adapt the awk fields.
if [[ "${length}" =~ ^[0-9]+$ ]] && (( length > SUSPICIOUS_SIZE_THRESHOLD )); then
if [[ -v suspicious_counts[${src_ip}] ]] && (( current_time - last_seen[${src_ip}] > TIME_WINDOW )); then
suspicious_counts[${src_ip}]=0
echo "[INFO] Resetting counter for ${src_ip} due to time window expiry."
fi
suspicious_counts[${src_ip}]=$(( ${suspicious_counts[${src_ip}]:-0} + 1 ))
last_seen[${src_ip}]=${current_time}
echo " Detected large ICMP echo request from ${src_ip}. Size: ${length} bytes. Count: ${suspicious_counts[${src_ip}]}"
if (( suspicious_counts[${src_ip}] >= ALERT_THRESHOLD )); then
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo " Potential ICMP tunnel detected from source IP: ${src_ip}"
echo " This host has sent ${suspicious_counts[${src_ip}]} packets with payload size > ${SUSPICIOUS_SIZE_THRESHOLD} bytes."
echo " Timestamp: $(date)"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
# Reset to avoid spam
suspicious_counts[${src_ip}]=0
fi
fi
doneAll done? Not yet, here’s the extra bit Reggie insisted on. Read it, or don’t, and we’ll leave your network to its own devices (which is to say: criminals).
Real-world tweaks & hard-earned grudges
First, warnings: run this as root, run it in a lab before production, and don’t blame our in-house raccoon if your monitoring box melts under legitimate traffic. This script is intentionally opinionated and judgmental, like Reggie, but also gloriously effective when used with sense.
Practical tuning: every network has its oddities. Set INTERFACE to the interface that sees egress (not localhost), and adjust SUSPICIOUS_SIZE_THRESHOLD after you sample real traffic. If your network carries legitimate jumbo ICMP for testing or MTU discovery, your threshold might need to sit somewhere between “sane” and “defensive therapist-level concern.”
Noise reduction: if you hate false positives as much as you hate corporate meetings, add a whitelist of known monitoring hosts and infrastructure devices to ignore. A tiny associative array and a quick check before incrementing suspicious_counts will save you a week of hand-wringing and a mess of tickets marked “false alarm.”
Logging & escalation: the script prints to stdout because it’s honest and terminal-facing. In production, pipe alerts into syslog or a file, and set up a cron job or systemd unit with log rotation. Better: have the script call logger or use curl to ping your ticketing system with a snarky subject line. Automation with manners.
Portability gripes: tcpdump output varies by version. If awk fails to extract src_ip or length, tweak the field indexes or switch to -tttt -e -q options for more reliable formats. If you’re feeling fancy, swap the awk parsing for python -c or jq on JSON output from a pcap library, but then you’ll miss the sweet, filthy joy of solving problems with bash.
Performance: this approach is fine for small offices and lab setups. If you’re in an ISP or enterprise with tens of thousands of flows, donor-advised funds for a proper NDR are recommended. This script is your truncheon, not your fighter jet.
And finally: don’t be smug. The script is useful because it exposes sloppy assumptions: that diagnostics don’t need inspection, that everything on the wire is honest, and that security is a one-off checkbox. Tune it, learn from it, and when it alerts, act, not with fury, but with the weary competence of someone who has been right about bad pings before.
Simulating the attack (for the love of science, in your lab only)
Picture the scene: a tiny, evil lab network where nothing you do breaks production and every mistake costs only your pride. You’ll need three things:
- Monitor host — where you run the Bash +
tcpdumpdetection script (Reggie’s “Bouncer”). - Victim host — the host that will appear compromised (your poor, unsuspecting VM).
- Attacker host — sends the oversized ICMP Echo Requests (this is the role you get to play for science).
Optional: do it all in VMs on a single machine with a user-defined virtual network. No human infrastructure harmed, no managers called.
Step 0 - Safety briefing (don’t be an idiot)
- Only in your lab or with explicit permission.
- Use isolated subnets or NAT’d VMs so traffic doesn’t leak onto the internet.
- If your monitoring machine forwards packets or has egress rules, be careful, we’re making things deliberately noisy.
Step 1 - Start the monitor and the Bouncer
On the Monitor, start the detection script we already dropped into the article:
sudo ./detect_icmp_tunnel.shIt’ll print a friendly startup banner and then sit, patient and judgemental, waiting for suspicious pings.
Step 2 - Verify tcpdump sees ICMP (sanity check)
On the Monitor, in a new shell, run a raw tcpdump view so you can watch what the script parses:
sudo tcpdump -nni <interface> "icmp and icmp[icmptype] == icmp-echo" -vv -s 0Replace <interface> with the monitor’s interface name (e.g., eth0 or ens33). -s 0 makes tcpdump capture full payloads so you can see the deliciously large lengths we’re about to create.
Step 3 - The simplest, dumb test: big-payload ping
From the Attacker, send oversized pings to the Victim:
# On many Linux systems, -s sets ICMP data size (not total pkt size).
ping -s 1024 <victim_ip>That -s 1024 results in a tcpdump-reported length of roughly 1024 + 8 (ICMP header), plenty to trip a naive threshold.
What to expect:
- In the monitor terminal, you’ll see
tcpdumplines showing ICMP echo requests from the attacker to the victim withlength 1032(or similar). - The detection script will report:
Detected large ICMP echo request from <attacker_ip>. Size: 1032 bytes. Count: 1and escalate onceALERT_THRESHOLDis reached.
Reggie’s commentary: “If that ping were a person, it’d be wearing cargo shorts and shouting about a startup idea.”
Step 4 - Make it look more tunnel-like (simulate steady traffic)
For a more realistic “persistent tunnel” feel, make the attacker send many pings at a regular interval:
# Send 100 pings, one every 0.2s
ping -s 1024 -i 0.2 -c 100 <victim_ip>That steady cadence looks much more like a maintained channel than a surprised admin doing a one-off test.
Optional: craft packets with hping3 (for the curious)
If you want to be slightly more grown-up and craft custom ICMP packets, hping3 lets you set payloads and timing. Example:
# Requires hping3 installed
sudo hping3 --icmp --data 1024 --flood <victim_ip>Do not run --flood unless your lab is ready for a minor DOS and you like frantic log churn. Use --count and --interval to throttle.
Step 5 - Look at tcpdump/timestamps to confirm the three tells
While the attack runs, observe:
- Size:
tcpdump’slengthfield should be well above your usual baseline. - Entropy (quick eyeball): use
tcpdump -Xto dump payload bytes, if they look like random garbage rather than0x61 0x61 0x61…or a timestamp, that’s suspicious. - Frequency: note the inter-packet timings, steady, short intervals to the same dest IP scream “tunnel.”
Example tcpdump output snippet you might see:
12:34:56.789012 IP 10.0.0.5 > 203.0.113.77: ICMP echo request, id 12345, seq 1, length 1032
12:34:56.989012 IP 10.0.0.5 > 203.0.113.77: ICMP echo request, id 12345, seq 2, length 1032
...Your script will pick those up and start incrementing the suspicious count.
Step 6 - Stop, clean up, and reflect
When finished:
- Kill the ping or
hping3on the attacker (Ctrl+C). - Stop the detection script on the monitor (
Ctrl+C) or let it persist if you want to test log forwarding. - Review logs, PCAPs (
tcpdump -w capture.pcap), and the script’s alerts. Feed any artifacts to your lab SIEM or Reggie’s personal shrine of suspicious packets.
Expected lesson (the point of all this)
You watched a host mimic a persistent, high-entropy, large-payload ICMP flow. The detection script should have:
- flagged unusually large payload sizes,
- logged a rising count for the attacking IP, and
- triggered an alert once the threshold was reached.
If the script didn’t alert, tweak the SUSPICIOUS_SIZE_THRESHOLD, ALERT_THRESHOLD, or TIME_WINDOW, and try again. Reggie insists the script’s default settings are “sensible,” which in raccoon-speak means “likely to embarrass lazy networks.”
Closing note from Reggie
“Right, one last thing,” Reggie says, polishing a packet capture like it’s a trophy nicked from a negligent router. “Do this only in your lab. I mean proper isolation: VMs on an air-gapped network, a VLAN that doesn’t chat to the outside world, or a physical sandbox with fewer windows than a submarine. Not someone else’s kit. Not your work laptop. Not your mate’s router while they’re watching telly.
Do it anywhere else and you’re not doing research, you’re auditioning for an unexpected midnight knock. The polite people with badges, the three-letter agencies and their equivalents (you know the crowd: FBI, CIA, NSA or MI5/MI6, GCHQ, FSB, Mossad, BND, ASIO, or whatever outfit your country calls when it’s peevish), have an excellent sense of direction and a real dislike of unauthorised packet-sculpting. They do not appreciate sarcasm as a legal defence.
So simulate, learn, and then fix things for real, quietly, professionally, and on equipment you own. Reggie will take the unearthed fossils and the script; you take the lessons and stop your network from being the digital equivalent of an open luggage carousel. Everyone sleeps better that way.”
Mitigation: how to keep the cat flap from becoming a motorway
If you don’t want your network moonlighting as a courier service for stolen data, mitigation isn’t about grand gestures, it’s about relentless, unglamorous housekeeping. You’re not building Fort Knox; you’re closing the cat flap before it becomes a motorway.
Start at the perimeter. ICMP is handy, but it’s not sacred scripture. You don’t need to ban it outright, just stop worshipping it. Allow only what’s genuinely required, typically echo-request and echo-reply , and tell everything else to get stuffed. Half the ICMP message types were invented back when the internet was a small, bearded commune of UNIX idealists who thought “security” meant closing your terminal when you left the room. Those days are over.
Then there’s size. ICMP’s payload flexibility is what makes it abusable, so enforce a diet. A normal ping payload is tiny, 32 to 84 bytes on the wire, so anything larger than a modest sandwich should raise suspicion. Add a firewall rule to enforce that discipline. Here’s one Reggie swears by:
# Drop ICMP echo requests with payloads larger than 128 bytes
iptables -A INPUT -p icmp --icmp-type echo-request -m length --length 0:128 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROPor, for the more modern crowd:
nft add rule inet filter input icmp type echo-request payload length 0-128 accept
nft add rule inet filter input icmp type echo-request dropIt’s blunt, yes, but so is the average attack. That simple rule will block most amateur tunnels before they can even whisper. If your engineers genuinely need to run jumbo pings for MTU testing, carve out a separate network segment for them and let them have their fun there. Just don’t make exceptions on the main highway and call it “agility.”
Hosts shouldn’t get to shrug responsibility onto the firewall. Configure local rules to mirror the perimeter’s boundaries: block unsolicited ICMP where it’s not needed, cap packet size, disable redirects, and stop trusting that your perimeter appliance will save you from yourself. Defence-in-depth may be a tired cliché, but it’s also the reason you’re not explaining to compliance why your database was last seen tunnelling through ping packets to a VPS in Moldova.
Detection is the next leg of this joyless relay. Baseline normal ICMP behaviour on your network, who pings what, how often, and with what payload sizes. Once you know what’s dull, you can spot what’s drama. Tools like Zeek or Suricata can handle this neatly; if you’re less flush with budget, a few cron jobs grepping tcpdump output into logs will do the trick. The point is to actually look at it. Suspiciously consistent ICMP chatter to one external IP? That’s not “monitoring,” that’s your cat flap whistling in the wind.
And when you do catch something, respond like a professional: isolate the host, capture the traffic, find the offending process, and fix the misconfiguration that made the tunnel possible in the first place. Then, and this is the bit everyone skips, document the change. A policy written down is one fewer assumption someone can accidentally misinterpret later.
In short: treat ICMP like the friendly-but-unreliable neighbour it is. Wave politely, but never lend it your house keys. Keep your rules tight, your baselines current, and your logs uncomfortably honest. That’s how you stop your network’s humble cat flap from turning into the next M1.
Final thoughts: paranoia with manners
There’s a peculiar irony to modern cybersecurity. We’ve built an industry that can’t stop talking about AI, machine learning, “behavioural threat modelling,” and other buzzwords that sound like they should come with their own TED Talk, but half the people deploying these shiny toys couldn’t tell you the difference between an ICMP echo request and a small woodland mammal. The landscape has shifted so far toward automation and abstraction that the fundamentals, the messy, human, packet-level stuff, are becoming an endangered species.
Every vendor now promises “autonomous detection,” “AI-driven analytics,” and “threat intelligence at scale,” which roughly translates to “we’ve built a statistical oracle that will occasionally light up red, and we hope you’ll assume it’s correct.” Don’t misunderstand, some of these systems are brilliant. But they’re only as good as the humans who know what’s happening underneath. And if you don’t understand what ICMP actually does, no algorithm on earth will save you from a cleverly hidden tunnel quietly leaking data through the firewall your AI swore was fine.
This is why people like Reggie, and perhaps you, if you’re still reading, remain essential. Knowing how to read a packet capture, to spot when something “just works” too well, or to tell that a ping shouldn’t be 1,024 bytes long, is a kind of superpower. It’s what separates engineers from button-pushers, analysts from dashboard decorators. While everyone else is asking ChatGPT for a threat summary, you’ll be the one who can look at a hex dump and mutter, “That’s odd,” just before averting a disaster.
The cybersecurity job market loves to talk about “critical thinking” and “curiosity,” but here’s the secret: curiosity with context beats automation every time. Anyone can click “scan,” but few can explain why a tool flags what it does, or what it missed because of how packets behave in the real world. When you understand protocols, really understand them, you start seeing the patterns, the anomalies, and the mistakes others ignore. You don’t panic when a new exploit drops, because you already grasp the plumbing beneath the buzzwords.
So yes, paranoia still matters, but it should come with manners. Check the basics before you reach for the machine-learning hammer. Ask whether your systems need to trust a protocol before you feed its telemetry to another algorithm. Be sceptical, but be kind; the person who set up that overly permissive ICMP rule probably didn’t mean to build an exfiltration tunnel, they just wanted their diagnostics to work. Fix it, document it, and move on.
In a world that automates faster than it educates, being the one who understands what’s really happening under the hood is your career insurance policy. When you sit in an interview and they ask you about threat detection, don’t just talk about “AI analytics”, talk about entropy, packet baselines, and how you once caught a covert channel pretending to be a ping. They’ll remember that.
Because long after the buzzwords fade and the AI dashboards stop spinning, the people who can still read the raw output, who know what a lie looks like in binary, will be the ones left keeping the internet vaguely honest. Reggie would approve. He’d call it “paranoia with manners,” then mutter something about how he misses the days when being good at your job just meant reading packets until your eyes hurt.
References:
Postel, J. (1981) 'Internet Control Message Protocol', IETF, September. Available at: https://www.rfc-editor.org/rfc/rfc792 (Accessed: 24 October 2025)
IBM (no date) 'What is a zero-day exploit?'. Available at: https://www.ibm.com/think/topics/zero-day (Accessed: 24 October 2025)
Rosen, R. (2014) 'Internet Control Message Protocol (ICMP)'. In: Linux Kernel Networking. Apress, Berkeley, CA. Available at: https://doi.org/10.1007/978-1-4302-6197-1_3 (Accessed: 24 October 2025)
Mazurczyk, W., Wendzel, S., Zander, S., Houmansadr, A., Szczypiorski, K. (2016) "Network Steganography". In: Information Hiding in Communication Networks: Fundamentals, Mechanisms, Applications, and Countermeasures , IEEE, pp.1-30. Available at: https://doi.org/10.1002/9781119081715.ch03 (Accessed: 24 October 2025)
Okta (2025) 'What Is MTU (Maximum Transmission Unit)?'. Available at: https://www.okta.com/en-gb/identity-101/mtu/ (Accessed: 24 October 2025)
Konicanin, V. (2024) 'Detecting Network Anomalies With Shannon Entropy: A Novel Approach to Cybersecurity', International Journal of Technical and Natural Sciences, 4(1):39-53. Available at: https://doi.org//10.69648/KJDP2991 (Accessed: 24 October 2025)
Cloudflare (2025) 'Zero Trust Security | What is a Zero Trust network'. Availabe at: https://www.cloudflare.com/en-gb/learning/security/glossary/what-is-zero-trust/ (Accessed: 24 October 2025)
