Data Exfiltration via ICMP Tunneling
Adversaries encode stolen data inside ICMP echo request/reply payloads to exfiltrate over a protocol that is frequently permitted outbound by firewalls even when all other egress is blocked. Public tools such as icmpsh, ptunnel, hans, and pingtunnel wrap a full bidirectional channel inside ICMP type 8/0 packets, and living-off-the-land variants simply abuse the built-in ping utility with oversized payloads (-l on Windows, -s on Linux/macOS) to smuggle data in repeated pings. This technique is a persistent detection gap because most EDR network telemetry (Microsoft Defender for Endpoint DeviceNetworkEvents, Sysmon Event ID 3, CrowdStrike NetworkConnectIP4) only instruments TCP/UDP connection setup and does not log ICMP traffic at all. Reliable detection therefore requires combining process-level visibility (ping.exe / ping binary invoked with abnormal packet-size or repeat-count flags, or unrecognized ICMP tunneling binaries) with network-layer telemetry from firewalls, NetFlow, or NDR/Zeek sensors that do record ICMP as a protocol.
What is THREAT-Exfiltration-ICMPTunnel Data Exfiltration via ICMP Tunneling?
Data Exfiltration via ICMP Tunneling (THREAT-Exfiltration-ICMPTunnel) maps to the Exfiltration tactic — the adversary is trying to steal data in MITRE ATT&CK.
This page provides production-ready detection logic for Data Exfiltration via ICMP Tunneling, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Exfiltration
// THREAT: ICMP Tunnel Exfiltration
// Signal 1: ping.exe invoked with oversized payload or high-repeat flags (host-level, EDR-visible)
let SuspiciousPing = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "ping.exe"
| extend PayloadSize = extract(@"-l\s+(\d+)", 1, ProcessCommandLine)
| extend RepeatFlag = ProcessCommandLine has_any ("-t", "-n 500", "-n 1000")
| where (isnotempty(PayloadSize) and toint(PayloadSize) > 1000) or RepeatFlag
| extend Signal = "OversizedOrContinuousPing"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, Signal;
// Signal 2: known ICMP tunneling tool binaries dropped or executed
let KnownTools = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any ("icmpsh", "ptunnel", "hans.exe", "hans", "pingtunnel", "icmptunnel")
| extend Signal = "KnownICMPTunnelTool"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, Signal;
SuspiciousPing
| union KnownTools
| sort by Timestamp desc
// NOTE: DeviceNetworkEvents does NOT capture ICMP traffic in Microsoft Defender for Endpoint.
// Pair this query with the CommonSecurityLog / firewall-based hunting query below for
// network-layer confirmation of high-volume or high-frequency ICMP flows to public IPs. Host-level detection for ICMP tunnel exfiltration using Microsoft Defender for Endpoint process telemetry. Signal 1 flags ping.exe invocations with an oversized payload (-l greater than 1000 bytes, versus the 32-byte Windows default) or continuous/high-repeat flags (-t, large -n counts), both hallmarks of data being smuggled through repeated ICMP echo requests. Signal 2 flags execution of named ICMP tunneling utilities (icmpsh, ptunnel, hans, pingtunnel, icmptunnel). Because DeviceNetworkEvents does not log ICMP traffic, this query cannot see the tunnel's network side directly — it must be paired with firewall/NDR telemetry (see the hunting query in the investigation block) for full-chain confirmation.
Data Sources
Required Tables
False Positives
- Network engineers running large-payload ping tests (ping -l 1472) to validate MTU/path fragmentation settings
- Monitoring tools that use continuous ping (-t) for uptime/latency dashboards
- Legitimate network troubleshooting scripts that loop ping with high repeat counts
Sigma rule & cross-platform mapping
The detection logic for Data Exfiltration via ICMP Tunneling (THREAT-Exfiltration-ICMPTunnel) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for THREAT-Exfiltration-ICMPTunnel
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Oversized ICMP Payload via ping.exe
Expected signal: Sysmon Event ID 1 / DeviceProcessEvents: ping.exe process creation with CommandLine containing '-l 1400 -n 20'. No corresponding DeviceNetworkEvents entry will be generated, since MDE does not log ICMP traffic.
- Test 2Continuous Ping Simulation
Expected signal: Sysmon Event ID 1 / DeviceProcessEvents: ping.exe with CommandLine containing '-t'.
- Test 3Large ICMP Payload via ping (Linux/macOS)
Expected signal: Auditd EXECVE record for ping with arguments '-s 1400 -c 20 8.8.8.8'. Firewall/NDR sensors will show ICMP echo requests with 1400-byte payloads.
Response Playbook
Triage
- Confirm the process signal first: review the full command line for ping.exe or the named tunneling tool — a payload size (-l) above 1000 bytes on Windows (default is 32) or a Linux/macOS -s value above 100 bytes is a strong anomaly with no common legitimate use beyond MTU testing.
- Because host EDR (MDE, Sysmon, Falcon) does not log ICMP network content, pull firewall, NetFlow, or NDR/Zeek sensor data for the same host and time window — look for sustained ICMP echo request/reply pairs to a single external IP, especially at a steady interval or with consistently large packet sizes.
- Check for an unusually high ICMP packet count or byte volume to a single destination over a short window — legitimate ping usage is typically a handful of packets, not hundreds or thousands.
- Identify the parent process and user context: was the ping/tool execution initiated interactively, by a script, or by a scheduled task? Tunneling tools are rarely launched by interactive users on servers.
- Search for the tunnel's companion server-side listener process if the host under investigation might be the destination rather than the source (ICMP tunnels are bidirectional and require a listener on the attacker-controlled end, but internal pivoting can place a listener on another internal host).
Containment
- Block outbound ICMP to the identified external IP(s) at the perimeter firewall — most environments do not need unrestricted outbound ICMP to arbitrary public IPs.
- Isolate the endpoint via EDR if a known ICMP tunneling binary (icmpsh, ptunnel, hans, pingtunnel) was confirmed executing.
- Consider disabling outbound ICMP echo entirely at the network egress point for workstation subnets where it has no operational purpose, reserving allowed ICMP for designated monitoring/network infrastructure ranges.
- Preserve the binary (if a named tool was dropped) for reverse engineering and IOC extraction before remediation.
Evidence Collection
- DeviceProcessEvents / Sysmon Event ID 1: full command line of the ping or tunneling tool invocation, parent process, and account context
- Firewall/NDR ICMP flow logs: packet counts, byte totals, and timing pattern between the host and destination IP
- File system: presence of the tunneling tool binary, its hash, and drop location (temp directories, user profile paths)
- DNS/proxy logs: any resolution activity for the destination IP prior to the ICMP traffic, which may reveal how the destination was identified
Escalation Criteria
- ! Confirmed execution of a named ICMP tunneling tool (icmpsh, ptunnel, hans, pingtunnel, icmptunnel)
- ! Firewall/NDR data confirms sustained, high-volume ICMP traffic to a single external IP correlating with the process-level signal
- ! The host involved has access to sensitive data stores (file servers, databases, source code repositories)
- ! Multiple internal hosts show the same oversized-ping pattern, suggesting a broader campaign rather than an isolated test
Investigation Guide
Forensic Artifacts
- >
Windows Prefetch: PING.EXE-*.pf with execution timestamps confirming repeated invocations - >
PowerShell PSReadLine history: recorded ping commands with -l flags if invoked via PowerShell - >
File system: dropped icmpsh/ptunnel/hans binaries and any accompanying Python scripts (icmpsh is often a client/server Python + Windows exe pair) - >
Firewall/NDR flow records: ICMP packet size distribution and inter-packet timing, the primary evidence source since endpoint EDR lacks ICMP visibility - >
Bash/zsh history (Linux/macOS): ping -s <size> invocations or ptunnel/hans command lines
Tuning Guidance
The process-level signal (oversized ping payload or named tunneling tool) is high-fidelity and should rarely need tuning beyond excluding known network engineering teams who perform legitimate MTU discovery testing — track those by account name or source host group. The network-layer ICMP volume threshold (packet count/byte total) is environment-dependent; baseline normal ICMP traffic for 1-2 weeks before enabling alerting, since some environments run legitimate ICMP-based monitoring (Nagios, PRTG, SmokePing) that generates regular but low-volume ping traffic. Exclude known monitoring server IPs from the network-layer hunting query rather than raising the volume threshold, to avoid masking genuine low-and-slow tunnels.
Hunting Queries
Network-layer hunt for anomalously high-volume or high-frequency ICMP traffic to external destinations using firewall flow logs. This is the necessary complement to the host-based process query above, since ICMP payload/volume anomalies are the primary way to confirm an active tunnel once EDR flags a suspicious ping or tunneling tool on the host.
// Firewall/NDR-side hunt — requires CommonSecurityLog or equivalent ingestion of ICMP flow data
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where Protocol =~ "ICMP"
| where DestinationIP !startswith "10." and DestinationIP !startswith "192.168."
| summarize PacketCount=count(), TotalBytes=sum(toint(SentBytes)), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
by SourceIP, DestinationIP
| where PacketCount > 200 or TotalBytes > 1048576
| sort by PacketCount desc index=firewall proto=icmp
| where NOT (dest_ip="10.0.0.0/8" OR dest_ip="192.168.0.0/16" OR dest_ip="172.16.0.0/12")
| stats count as PacketCount, sum(bytes) as TotalBytes by src_ip, dest_ip
| where PacketCount > 200 OR TotalBytes > 1048576
| sort - PacketCount Atomic Red Team Tests
Invokes the Windows built-in ping utility with an oversized payload (-l 1400), simulating the packet-size pattern used by ICMP data-smuggling techniques. No actual data is exfiltrated; this only generates the anomalous process/command-line telemetry.
Command
ping -l 1400 -n 20 8.8.8.8 Expected Telemetry
Sysmon Event ID 1 / DeviceProcessEvents: ping.exe process creation with CommandLine containing '-l 1400 -n 20'. No corresponding DeviceNetworkEvents entry will be generated, since MDE does not log ICMP traffic.
Expected Detection
KQL/SPL Signal 'OversizedOrContinuousPing' fires on PayloadSize=1400 (> 1000 byte threshold).
Runs ping in continuous mode (-t), simulating the sustained-connection pattern a basic ICMP tunnel client would use to keep a channel open. Should be run for a short window only.
Command
ping -t 8.8.8.8 Cleanup
taskkill /IM ping.exe /F 2>nul Expected Telemetry
Sysmon Event ID 1 / DeviceProcessEvents: ping.exe with CommandLine containing '-t'.
Expected Detection
KQL/SPL Signal 'OversizedOrContinuousPing' / 'ContinuousPing' fires on the -t flag.
Simulates ICMP tunneling telemetry on Linux/macOS by sending oversized ICMP echo requests using the -s flag, mirroring how ptunnel/icmptunnel embed data in the payload.
Command
ping -s 1400 -c 20 8.8.8.8 Expected Telemetry
Auditd EXECVE record for ping with arguments '-s 1400 -c 20 8.8.8.8'. Firewall/NDR sensors will show ICMP echo requests with 1400-byte payloads.
Expected Detection
Firewall/NDR hunting query flags high packet count/byte total to the destination IP if repeated across multiple runs.
Related Detections
Tactic Hub
Detection Variants (3)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.
- THREAT-DNSTunnel-ExfilDNS Tunneling for Covert Data ExfiltrationUse for network-side DNS visibility — Zeek/Infoblox resolver logs and pcap; catches tunneling from hosts with no endpoint agent.
- THREAT-DNSTunneling-ExfiltrationData Exfiltration via DNS Tunneling ToolsUse for endpoint DNS telemetry — Sysmon EID 22 / MDE DeviceDnsEvents; adds process attribution and tool fingerprints (iodine, dnscat2, DNSExfiltrator).
- THREAT-Exfiltration-PlaintextFTPBulkUploadBulk Data Exfiltration over Plaintext FTP/TFTP to an External HostUse where FTP/TFTP egress is not blocked outright. In estates where outbound TCP/21 and UDP/69 are already denied at the perimeter, prefer this rule as a policy-violation/blocked-attempt monitor and lower the connection-count threshold to 1.