Detect Data Exfiltration via ICMP Covert Channel in Google Chronicle
Tools such as icmpsh, ptunnel, icmptunnel, Nishang's Invoke-PowerShellIcmp, and Cobalt Strike's ICMP beacon exfiltrate collected data by embedding it in the payload of ICMP Echo Request (Type 8) packets and relying on an adversary-controlled listener to reassemble it from Echo Reply traffic. ICMP is exceptionally effective as an exfiltration channel because it is a network-layer control protocol that most firewalls and proxies pass without content inspection or logging, and it requires no application-layer handshake, DNS resolution, or TLS certificate that could be fingerprinted. PLATINUM has been documented using ICMP as a communication and file-transfer channel specifically because it evades traditional network intrusion detection that focuses on TCP/UDP application traffic. Critically, this technique also evades most process-centric EDR network telemetry: Sysmon's Network Connection event (Event ID 3) and Microsoft Defender for Endpoint's DeviceNetworkEvents only monitor TCP/UDP socket activity and do not record raw ICMP traffic at all, so detection here requires visibility from genuinely ICMP-capable network-layer sensors — NGFW/firewall session logs, Zeek/Bro network-tap conn.log, or flow collectors (NetFlow/IPFIX/QFlow). This differs from the generic T1041 base record (which centers on HTTP/DNS beaconing patterns) in that ICMP tunnels are identifiable by a distinct network-layer fingerprint: abnormal session/packet volume to a single destination, oversized payload-per-session inconsistent with diagnostic ping, and sustained session duration outside of standard troubleshooting use.
MITRE ATT&CK
- Tactic
- Exfiltration
YARA-L Detection Query
rule icmp_c2_exfiltration_covert_channel {
meta:
author = "Detection Engineering"
description = "Detects ICMP covert-channel exfiltration via sustained session volume and oversized payload size, sourced from firewall/network telemetry rather than endpoint EDR (which does not capture ICMP)."
mitre_attack_tactic = "Exfiltration"
mitre_attack_technique = "T1041"
severity = "HIGH"
priority = "HIGH"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.network.ip_protocol = "ICMP"
$e.security_result.action = "ALLOW"
$src = $e.principal.ip
$dst = $e.target.ip
$bytes = $e.network.sent_bytes + $e.network.received_bytes
match:
$src, $dst over 1h
outcome:
$session_count = count($e.metadata.id)
$total_bytes = sum($bytes)
$avg_bytes_per_session = $total_bytes / $session_count
condition:
$e and $session_count >= 200 and $avg_bytes_per_session >= 100
}Chronicle YARA-L 2.0 rule matching NETWORK_CONNECTION UDM events with ip_protocol=ICMP, sourced from firewall/NGFW log forwarders ingested into Chronicle (not endpoint EDR connectors, which do not surface ICMP). Uses match/outcome aggregation over a 1-hour window by source/destination IP pair to score sustained session volume and average payload size per session — the same fingerprint used in the kql/spl scoring model.
Data Sources
Required Tables
False Positives & Tuning
- Network monitoring and availability-check appliances generating sustained ICMP sessions to a small set of anchor IPs
- Path MTU discovery and network troubleshooting using oversized ping payloads
- Authorized vulnerability scanning or network mapping generating high-volume ICMP sweeps
Other platforms for THREAT-ICMP-C2Exfiltration
Testing Methodology
Validate this detection against 2 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 1Simulated ICMP Tunneling via Oversized Ping Payload Burst
Expected signal: CommonSecurityLog (or Zeek conn.log): ~60 permitted ICMP session records between the test host's source IP and 198.51.100.10, each with SentBytes/orig_ip_bytes reflecting the 128-byte payload (well above the 56-byte default), spanning roughly 12 seconds. Sysmon/MDE will NOT show this traffic — that is expected and confirms the endpoint-blind-spot this detection is designed to cover.
- Test 2Sustained Single-Destination ICMP Session Simulation
Expected signal: CommonSecurityLog (or Zeek conn.log): 400 permitted ICMP session records from the test host to 198.51.100.10 spanning approximately 3-4 minutes, with SessionCount and DurationMinutes both elevated relative to normal diagnostic traffic patterns.
References (8)
- https://attack.mitre.org/techniques/T1041/
- https://attack.mitre.org/techniques/T1095/
- https://www.microsoft.com/en-us/security/blog/2017/04/24/platinum-continues-to-evolve-find-ways-to-maintain-invisibility/
- https://github.com/inquisb/icmpsh
- https://github.com/utoni/ptunnel-ng
- https://github.com/samratashok/nishang
- https://github.com/SigmaHQ/sigma/tree/master/rules/network
- https://docs.zeek.org/en/current/scripts/base/protocols/conn/main.zeek.html
Response Playbook
Triage
- Confirm the alerting source is genuinely ICMP-capable network telemetry (firewall session log, Zeek conn.log, flow collector) — endpoint EDR data (Sysmon, MDE DeviceNetworkEvents) will not show this traffic and should only be used for secondary correlation, never as the primary detection source.
- Confirm sustained, single-destination ICMP session activity — legitimate diagnostic pings are brief and often target multiple hosts (e.g. default gateway, DNS server, a remote site) rather than looping indefinitely against one external IP.
- If packet capture is available from the same sensor, inspect ICMP Echo Request/Reply payload bytes for non-standard content — Windows/Linux ping payloads are a fixed repeating pattern (e.g. 'abcdefghi...'); tunneling tools carry arbitrary, often high-entropy or Base64-like data.
- Correlate the source IP against endpoint identity (DHCP lease log, VPN concentrator log, or asset inventory) to identify the specific host, then pull DeviceFileEvents/Sysmon Event ID 11 for that host in the preceding window for archive creation, credential-store reads, or bulk file access, indicating a collect-then-tunnel pattern.
- Check whether outbound ICMP is even required for this network segment's normal function — many workstation subnets have no legitimate business reason for sustained ICMP traffic to external IPs, making this a strong environment-specific anomaly regardless of volume thresholds.
- Determine whether the remote IP correlates with known ICMP tunneling C2 infrastructure or has been recently registered/flagged in threat intelligence.
Containment
- Block the destination IP at the perimeter firewall — since ICMP tunnels require sustained two-way Echo Request/Reply exchange with a specific listener, blocking the destination immediately severs the channel.
- Once the source host is identified via DHCP/VPN/asset correlation, isolate the endpoint via EDR network isolation; ICMP tunneling clients are typically standalone processes that will resume once network access is restored, so isolation should precede remediation.
- Consider organization-wide egress filtering that rate-limits or blocks outbound ICMP Echo Request to arbitrary external hosts, permitting it only to a documented allowlist of monitoring/diagnostic targets — this single control defeats the technique class broadly.
- Rotate credentials for any account active on the identified host during the tunneling window, since ICMP exfiltration is frequently used to move credential dumps or reconnaissance data.
- Preserve a packet capture of the ICMP traffic before blocking — the reassembled payload is often the best evidence of what was actually stolen.
Evidence Collection
- Full firewall/Zeek session log for the destination IP across the complete activity window, not just the alerting window — tunnels often run for extended periods before crossing volume thresholds.
- Packet capture of the ICMP session if available — this is the highest-value artifact since it may contain the raw exfiltrated payload in Echo Request data fields.
- Once the source host is identified, a process memory dump of the tunneling client if still running — icmpsh and similar tools keep the reconstructed data buffer in memory prior to writing to disk.
- Any locally staged archive or output file the tunneling tool assembled data from (check %TEMP%, /tmp, and the tool's working directory on the identified host).
- DHCP lease logs, VPN concentrator logs, or NAT/PAT translation tables covering the alert window, needed to map the firewall/Zeek-observed source IP back to a specific endpoint and user.
Escalation Criteria
- !Packet capture analysis confirms exfiltration of credentials, source code, or regulated data (PII, PHI, PCI) — escalate immediately to incident response and legal/privacy.
- !The destination IP or tooling matches known APT infrastructure (e.g. PLATINUM ICMP-based file transfer patterns) in threat intelligence.
- !ICMP tunneling activity is observed originating from a server subnet, datacenter segment, or privileged management network rather than a standard user endpoint subnet.
- !The activity has been sustained for more than 24 hours before detection, indicating a substantial volume of data may already be off-network.
- !The same destination IP or tunneling signature appears across multiple source IPs, indicating lateral spread or a shared C2 infrastructure compromise.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Firewall/NGFW session logs (CommonSecurityLog) — the primary artifact for identifying sustained ICMP sessions, since endpoint agents do not log ICMP. - >
Zeek/Bro conn.log and, where deployed, icmp.log — packet-capture-derived records with genuine ICMP type/code and byte/packet counters, the most reliable network-layer artifact short of full PCAP. - >
Full packet capture (pcap) — the only artifact that can reveal the actual ICMP Echo Request/Reply payload content for decoding. - >
Once the source host is identified via DHCP/NAT correlation: prefetch and process execution artifacts for the tunneling client binary (icmpsh, ptunnel, icmptunnel, or a PowerShell script implementing Invoke-PowerShellIcmp). - >
Any dropped configuration file or script specifying the listener IP and encoding scheme used by the client, recovered from the identified endpoint.
Tuning Guidance
Establish an allowlist of source/destination pairs with a legitimate business need for sustained ICMP traffic (network monitoring servers, WAN circuit health-check appliances) before enabling this in alerting mode, since these are the primary source of false positives. If your environment has no legitimate business reason for outbound ICMP from standard user subnets, consider lowering MinSessionCount substantially for that population while keeping a higher threshold for designated network operations hosts. Packet capture with payload inspection is the single highest-value addition to this detection — volume and duration heuristics alone will miss low-and-slow tunnels, but payload entropy/pattern-deviation analysis catches them even at low session counts. Do not attempt to substitute Sysmon Event ID 3 or MDE DeviceNetworkEvents for the primary detection source — neither captures ICMP traffic, and a detection built on them will never fire regardless of tuning. If your firewall or Zeek deployment exposes ICMP type/code directly, add a rule arm that flags Echo Request traffic with anomalous type/code combinations or payload sizes deviating from your OS fleet's standard default sizes (32 bytes Windows, 56 bytes most Linux/macOS ping implementations).
Hunting Queries
Hunts broadly for any source/destination pair generating more than a handful of ICMP sessions to a single external destination — a coarse volume-based hunt intended to surface candidates for deeper payload-size and entropy inspection when full packet capture is available.
// Hunt for ICMP sessions with average byte-per-session sizes that deviate from the standard OS default ping payload (32 bytes Windows, 56 bytes Linux/macOS)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where Protocol =~ "ICMP"
| where ipv4_is_private(DestinationIP) == false
| summarize SessionCount = count(), TotalBytes = sum(SentBytes + ReceivedBytes), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, DestinationIP
| extend AvgBytesPerSession = TotalBytes / SessionCount
| where SessionCount > 20
| sort by SessionCount descindex=zeek sourcetype="bro:conn:json" proto="icmp"
| stats count as SessionCount, sum(orig_ip_bytes+resp_ip_bytes) as TotalBytes, earliest(ts) as FirstSeen, latest(ts) as LastSeen by 'id.orig_h', 'id.resp_h'
| eval AvgBytesPerSession=TotalBytes/SessionCount
| where SessionCount>20
| sort - SessionCountHunts for sub-3-second-interval ICMP session bursts — the automated, scripted pacing signature of an ICMP tunneling client rather than the irregular, low-volume pattern of manual ping-based troubleshooting.
// Hunt for regular, automated-pacing ICMP session activity consistent with a scripted tunnel client rather than manual troubleshooting
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where Protocol =~ "ICMP"
| where ipv4_is_private(DestinationIP) == false
| sort by SourceIP, DestinationIP, TimeGenerated asc
| serialize
| extend PrevTimestamp = prev(TimeGenerated), PrevSource = prev(SourceIP), PrevDest = prev(DestinationIP)
| where SourceIP == PrevSource and DestinationIP == PrevDest
| extend GapSeconds = datetime_diff('second', TimeGenerated, PrevTimestamp)
| where GapSeconds between (0 .. 3)
| summarize BurstSessions = count(), AvgGapSeconds = avg(GapSeconds) by SourceIP, DestinationIP, bin(TimeGenerated, 1h)
| where BurstSessions > 50
| sort by BurstSessions descindex=zeek sourcetype="bro:conn:json" proto="icmp"
| sort 0 'id.orig_h', 'id.resp_h', ts
| streamstats current=f last(ts) as PrevTime by 'id.orig_h', 'id.resp_h'
| eval GapSeconds=ts-PrevTime
| where GapSeconds>=0 AND GapSeconds<=3
| bucket ts span=1h
| stats count as BurstSessions, avg(GapSeconds) as AvgGapSeconds by 'id.orig_h', 'id.resp_h', ts
| where BurstSessions>50
| sort - BurstSessionsAtomic Red Team Tests
Simulates the payload characteristics of an ICMP tunneling tool (icmpsh/ptunnel-style) by issuing a rapid burst of pings with an oversized, encoded payload to an external test destination that transits the monitored perimeter firewall or Zeek-tapped network segment, replicating the high-volume, oversized-payload signature the detection targets, without requiring installation of an actual tunneling tool. Must be run from a host whose egress traffic passes through the monitored NGFW or network tap — this detection cannot be validated from endpoint telemetry alone.
Command
for i in $(seq 1 60); do ping -c 1 -s 128 -W 1 198.51.100.10 > /dev/null 2>&1; sleep 0.2; done
echo 'ICMP tunneling simulation complete: 60 oversized-payload pings generated'Expected Telemetry
CommonSecurityLog (or Zeek conn.log): ~60 permitted ICMP session records between the test host's source IP and 198.51.100.10, each with SentBytes/orig_ip_bytes reflecting the 128-byte payload (well above the 56-byte default), spanning roughly 12 seconds. Sysmon/MDE will NOT show this traffic — that is expected and confirms the endpoint-blind-spot this detection is designed to cover.
Expected Detection
KQL/SPL ICMP detection: SessionCount=60 exceeds MinSessionCount when lowered for lab testing (or extend the run for a realistic 200+ session threshold); AvgBytesPerSession/AvgBytesPerPacket exceeds the oversized-payload threshold given the 128-byte payload. IcmpScore should reach at least 2.
Generates a longer-duration, evenly-paced ICMP session to a single external test destination via the monitored network egress point, replicating the sustained-duration fingerprint of an ICMP tunneling client rather than a one-off diagnostic ping burst.
Command
for i in $(seq 1 400); do ping -c 1 -s 96 -W 1 198.51.100.10 > /dev/null 2>&1; sleep 0.5; done
echo 'Sustained ICMP session simulation complete: 400 pings over ~3.3 minutes'Expected Telemetry
CommonSecurityLog (or Zeek conn.log): 400 permitted ICMP session records from the test host to 198.51.100.10 spanning approximately 3-4 minutes, with SessionCount and DurationMinutes both elevated relative to normal diagnostic traffic patterns.
Expected Detection
IsHighVolume=true once SessionCount thresholds are scaled for lab testing; IsSustained=true given the multi-minute duration. Combined IcmpScore reaches 2+ and the detection fires on the SourceIP/DestinationIP pair.