T1095

Non-Application Layer Protocol

Command and Control Last updated:

Adversaries may use OSI non-application layer protocols for C2 communications to evade network defenses that focus on application-layer monitoring. This includes ICMP tunneling (embedding C2 data in ping request/reply payloads), raw UDP sockets that bypass application-layer fingerprinting, SOCKS proxy chaining to obscure true traffic routing and destination, and custom binary protocols over raw TCP connections. ICMP is required in all IP-compatible host implementations but is significantly undermonitored compared to TCP and UDP application protocols, making it an attractive covert channel. Notable threat actors leveraging this technique include Gamaredon Group using SOCKS5 over port 9050, APT32's WINDSHIELD malware using TCP raw sockets, TSCookie (BlackTech) and Anchor (TrickBot infrastructure) using ICMP for C2, and PlugX being configured for raw TCP or UDP. FRP (a popular proxy tool) supports TCP, KCP, QUIC, and UDP multiplexing. In ESXi environments, adversaries may use the Virtual Machine Communication Interface (VMCI) to create covert channels between guest VMs and the ESXi host that are invisible to external network monitoring tools including tcpdump, netstat, nmap, and Wireshark, as documented in Google Cloud's 2023 analysis of UNC3886.

What is T1095 Non-Application Layer Protocol?

Non-Application Layer Protocol (T1095) maps to the Command and Control tactic — the adversary is trying to communicate with compromised systems to control them in MITRE ATT&CK.

This page provides production-ready detection logic for Non-Application Layer Protocol, covering the data sources and telemetry it touches: Network Traffic: Network Traffic Flow, Network Traffic: Network Traffic Content, 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
Command and Control
Technique
T1095 Non-Application Layer Protocol
Canonical reference
https://attack.mitre.org/techniques/T1095/
Microsoft Sentinel / Defender
kusto 
let SocksProxyPorts = dynamic([1080, 1081, 4145, 9050, 9051, 9150, 8118, 9999, 1082, 1083, 3128]);
let LegitICMPProcesses = dynamic(["ping.exe", "tracert.exe", "pathping.exe", "fping.exe", "hping3"]);
let LegitUDPProcesses = dynamic([
    "svchost.exe", "chrome.exe", "firefox.exe", "msedge.exe",
    "teams.exe", "zoom.exe", "slack.exe", "skype.exe", "discord.exe",
    "lsass.exe", "dns.exe", "avast.exe", "MsMpEng.exe", "wininit.exe"
]);
let CommonUDPPorts = dynamic([53, 67, 68, 123, 161, 162, 443, 500, 4500, 5353, 5355, 51820, 1194, 8801, 8802, 3478, 3479, 19302, 19303, 4096]);
DeviceNetworkEvents
| where Timestamp > ago(24h)
| extend IsSocksPort = RemotePort in (SocksProxyPorts)
| extend IsUnexpectedICMP = (
    Protocol == "Icmp"
    and not (InitiatingProcessFileName in~ (LegitICMPProcesses))
)
| extend IsUnusualUDP = (
    Protocol == "Udp"
    and RemoteIPType == "Public"
    and not (RemotePort in (CommonUDPPorts))
    and not (InitiatingProcessFileName in~ (LegitUDPProcesses))
)
| where IsSocksPort or IsUnexpectedICMP or IsUnusualUDP
| extend DetectionSignal = case(
    IsSocksPort and IsUnexpectedICMP, "SOCKS_And_ICMP_Combined",
    IsUnexpectedICMP, strcat("ICMP_From_Unexpected_Process_", InitiatingProcessFileName),
    IsSocksPort, strcat("SOCKS_Proxy_Port_", tostring(RemotePort)),
    IsUnusualUDP, strcat("Unusual_UDP_Port_", tostring(RemotePort)),
    "Unknown"
)
| extend RiskScore = case(
    IsSocksPort and IsUnexpectedICMP, 95,
    IsUnexpectedICMP, 85,
    IsSocksPort, 75,
    IsUnusualUDP, 60,
    50
)
| project
    Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    InitiatingProcessParentFileName, InitiatingProcessParentCommandLine,
    RemoteIP, RemotePort, Protocol, LocalPort,
    SentBytes, ReceivedBytes,
    DetectionSignal, RiskScore
| sort by RiskScore desc, Timestamp desc

Multi-signal detection for non-application layer protocol C2 using Microsoft Defender for Endpoint DeviceNetworkEvents. Identifies three primary attack patterns: (1) connections to SOCKS proxy ports (1080, 9050, etc.) from non-browser processes, targeting malware like Gamaredon Group tooling that tunnels C2 through SOCKS5; (2) ICMP traffic generated by processes other than standard ping utilities, indicating potential ICMP tunneling as used by TSCookie and Anchor; (3) high-frequency or unusual UDP traffic to non-standard ports from non-network-utility processes, indicating custom UDP C2 protocols. Risk scoring prioritizes multi-signal findings and ICMP from unexpected processes. Note: ICMP visibility in DeviceNetworkEvents depends on MDE sensor version and platform; network-layer visibility (firewall/IDS) provides more complete ICMP coverage.

high severity medium confidence

Data Sources

Network Traffic: Network Traffic Flow Network Traffic: Network Traffic Content Microsoft Defender for Endpoint

Required Tables

DeviceNetworkEvents

False Positives

  • Tor Browser and other privacy-focused browsers legitimately connect to SOCKS/Onion network on ports 9050 and 1080 — add process-level allowlist for tor.exe and the Tor Browser executable
  • Custom enterprise middleware and industrial control systems using raw UDP for inter-service heartbeats or telemetry on non-standard ports
  • VoIP, video conferencing, and media streaming applications (Zoom, Teams, WebEx) may negotiate UDP media channels on non-standard high ports
  • WireGuard, OpenVPN, and other VPN clients operate over non-standard UDP ports; the default WireGuard port 51820 is excluded but custom deployments use arbitrary ports
  • Network monitoring and security scanning tools (nmap, Nessus agents, Zabbix, PRTG) generate ICMP and unusual UDP as part of active health checks

Sigma rule & cross-platform mapping

The detection logic for Non-Application Layer Protocol (T1095) 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: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1095 Sigma rules on detection.fyi

Platform-specific guides for T1095

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-13 Research depth: deep
References (7)

Testing Methodology

Validate this detection against 5 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.

  1. Test 1ICMP Large Payload Flood (ICMP Tunnel Simulation)

    Expected signal: Sysmon Event ID 3: Network connections with Protocol=ICMP, DestinationIp=8.8.8.8, Image=C:\Windows\System32\cmd.exe (or ping.exe as child). Windows Security Event ID 5156 (WFP permitted connection) with Protocol=1 (ICMP). Note: This test uses cmd.exe calling ping.exe, so the ICMP processes as ping.exe in most telemetry — to test the unexpected-process signal, replace with a script calling ping from PowerShell or a custom executable context.

  2. Test 2SOCKS5 Proxy Connection via PowerShell (Gamaredon-style)

    Expected signal: Sysmon Event ID 3: Network Connection with Image=powershell.exe, DestinationIp=127.0.0.1, DestinationPort=9050, Protocol=tcp. Windows Security Event ID 5156 (WFP) for the connection attempt. The connection will fail with a refused error but the event fires before the refusal. For external SOCKS detection, substitute 127.0.0.1 with any public test IP.

  3. Test 3Custom UDP Beacon to Non-Standard Port (Raw UDP C2 Simulation)

    Expected signal: Sysmon Event ID 3: 20 network connection events with Image=python3.exe (or python.exe), Protocol=udp, DestinationIp=8.8.8.8, DestinationPort=4444. Windows Filtering Platform Event ID 5156 for each UDP send. Note: UDP packets to 8.8.8.8:4444 will be dropped by Google but the outbound events still fire.

  4. Test 4ICMP Tunnel Tool Execution (ptunnel-ng simulation on Linux)

    Expected signal: auditd SYSCALL records for socket() with AF_INET and SOCK_RAW type (raw socket creation). syslog/kern.log: ICMP outbound traffic from hping3 process. If Zeek is deployed on network: icmp.log entries with unusual payload length (64 bytes + ICMP header) and high frequency (2 packets/second). Linux /proc/net/icmp shows active ICMP sockets during execution.

  5. Test 5SOCKS5 Proxy Connection via Netcat (Unix)

    Expected signal: auditd SYSCALL: connect() syscall from ncat process to 127.0.0.1:9050. If SOCKS proxy is listening, a subsequent connection to example.com:80 is initiated. syslog: ncat network activity. Linux endpoint agent (Elastic Agent, Falcon sensor): network connection event with destination port 9050.

Response Playbook

Triage

  1. Identify the protocol and port combination: SOCKS port connections (9050, 1080, 4145) are highest priority — note that port 9050 is strongly associated with Tor and Gamaredon Group tooling. ICMP from non-ping processes is very suspicious with few legitimate explanations.
  2. Examine the initiating process: What process is making the connection? Is it a legitimate application (browsers legitimately use SOCKS), a system binary that has no business making SOCKS connections (cmd.exe, powershell.exe, wscript.exe), or an unknown executable?
  3. Check process lineage: Who spawned the suspicious process? A document editor (Word, Excel) spawning a process that then creates ICMP or SOCKS connections is a strong indicator of initial access exploitation. Use: DeviceProcessEvents | where DeviceId == '<device>' | where Timestamp between (datetime('<suspicious_time>') - 5m) .. (datetime('<suspicious_time>') + 30m)
  4. Inspect payload size and frequency for ICMP signals: Standard ping uses 32-56 byte payloads. ICMP tunneling tools (icmptunnel, ptunnel, PingTunnel) use maximum-size ICMP packets (1472 bytes) continuously. High-frequency ICMP (>10 packets/min) to the same external IP from a non-ping process is a strong tunnel indicator.
  5. For SOCKS connections, verify if a SOCKS server is actually listening at the remote endpoint: Check threat intelligence for the destination IP. SOCKS5 connections to known Tor exit nodes or threat actor infrastructure are immediately escalation-worthy.
  6. Review recent file creation and process execution on the affected host in the 24 hours before the alert: Look for dropped executables, scheduled tasks, registry modifications — T1095 is typically a persistence or lateral movement companion, not an initial foothold technique.

Containment

  1. If ICMP tunneling confirmed (high-frequency, large-payload ICMP from non-standard process): Immediately isolate the endpoint using EDR network isolation. Block ICMP egress to all external IPs at the perimeter firewall for the source host's subnet.
  2. If SOCKS C2 confirmed: Block the destination IP/CIDR at the perimeter and internal firewall. Isolate the endpoint. Reset credentials for any accounts authenticated on the host during the infection window.
  3. If custom UDP C2 confirmed: Block the specific destination IP and port at the firewall. If the destination IP resolves to a cloud provider, notify the provider's abuse team as it may be an attacker-rented VPS.
  4. Disable or quarantine the malicious process using EDR response capabilities. Do not simply kill the process — quarantine the parent executable for forensic analysis.
  5. Review and audit all outbound firewall rules to confirm ICMP egress filtering is enabled. Many organizations allow unrestricted outbound ICMP which should be restricted to operational needs (traceroute from monitoring hosts only).
  6. If ESXi VMCI abuse is suspected (ESXi host or guest VMs involved): Immediately engage VMware support and isolate the ESXi host from management networks. VMCI-based backdoors require patching at the hypervisor level.

Evidence Collection

  1. Full packet capture from the detection window: Request network team to provide PCAP from the host's network segment covering at least 30 minutes before and after the alert timestamp. ICMP payloads and raw UDP content are only visible in PCAP.
  2. Sysmon Event ID 3 logs (Network Connections): Export all network connection events from the affected host for the 48 hours surrounding the alert. Include DestinationIp, DestinationPort, Protocol, Image, ProcessId fields.
  3. Process creation timeline: Sysmon Event ID 1 logs for the affected host — build full process tree from the suspicious process back to its root parent.
  4. Memory image of the suspicious process: If still running, take a live memory dump using Process Hacker, ProcDump, or your EDR's memory acquisition capability. ICMP tunnel and SOCKS proxy code may only exist in memory.
  5. File system artifacts: Hash and preserve the suspicious executable. Check for additional dropped files in %TEMP%, %APPDATA%, %ProgramData%, and common malware drop locations (C:\Windows\Temp, C:\Users\Public).
  6. Windows Filtering Platform (WFP) audit logs: Event ID 5156 (Windows Filtering Platform permitted a connection) from the Security event log captures connections including protocol and port for all processes, providing a secondary data source if Sysmon was not deployed.
  7. Network device logs: Pull firewall and router logs for the source IP over the alert window. Look for protocol anomalies, unusual ICMP codes, or UDP traffic volume spikes.
  8. ESXi artifacts (if applicable): /var/log/vmkernel.log for VMCI driver events, esxcli network connection list output, and vmware.log files from affected guest VMs.

Escalation Criteria

  • ! ICMP from any non-ping process to an external public IP, especially if payload sizes are consistently near MTU (1472 bytes) or connections are high-frequency — this is near-confirmation of ICMP tunneling with very few benign explanations
  • ! SOCKS connection from a process with no legitimate need for proxy connectivity (cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe) — strong indicator of malware using SOCKS for C2 routing
  • ! Destination IP on threat intelligence feeds as known C2 infrastructure, Tor exit node, or bullet-proof hosting provider
  • ! Custom UDP or raw TCP connections from a process that also has no DNS lookups preceding the connection — malware often communicates directly by IP to avoid DNS-based detection, combined with non-standard protocol is highly suspicious
  • ! Same non-application protocol C2 pattern observed across multiple hosts in the environment within a short window — indicates automated lateral movement or a worm-like propagation mechanism
  • ! ESXi or virtualization platform involvement — VMCI-based backdoors represent a severe persistence mechanism that survives network isolation of guest VMs

Investigation Guide

Forensic Artifacts

  • > PCAP data from network taps or span ports: The only reliable source for ICMP payload content analysis and custom protocol reconstruction. Standard endpoint logs do not capture payload content.
  • > Windows Filtering Platform audit: Security Event ID 5156 (WFP permitted connection) and 5157 (WFP blocked connection) — captures all network connections with protocol and port, available without Sysmon deployment.
  • > Sysmon Event ID 3 (Network Connection): Captures outbound connections with full process context (Image, CommandLine, ProcessId, ParentImage) — preferred over WFP events for analyst triage.
  • > Linux/macOS: /proc/net/raw (raw socket table), /proc/net/udp, /proc/net/icmp — lists active raw sockets by process. Command: ss -tup or netstat -tup with -p flag shows process ownership.
  • > Zeek/Bro conn.log: If Zeek is deployed on network sensors, the conn.log provides proto field analysis. Zeek also generates icmp.log with ICMP type/code and payload length — critical for ICMP tunnel detection.
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy — identifies ICMP or protocol exceptions added by malware to Windows Firewall.
  • > Prefetch files: C:\Windows\Prefetch\<MALWARE>.EXE-*.pf — timestamps of malicious executable runs, even if the binary was deleted after execution.
  • > ESXi vmkernel.log: Located at /var/log/vmkernel.log on ESXi hosts, contains VMCI driver initialization messages and vsock connection events that may indicate VMCI-based backdoor activity.

Tuning Guidance

Start by building a baseline of all legitimate non-standard UDP and SOCKS traffic in your environment. Network monitoring tools (Zabbix, PRTG, Datadog agents), developer workstations with custom tooling, and VPN appliances generate significant legitimate SOCKS and UDP traffic. Create process-level allowlists rather than port-level allowlists — the same port may be malicious from powershell.exe but legitimate from a known monitoring agent. For ICMP detection, the primary tuning challenge is that MDE DeviceNetworkEvents may not capture all ICMP traffic depending on sensor version; supplement with network-layer visibility (Zeek/Bro, firewall logs) for reliable ICMP coverage. Palo Alto and Fortinet NGFWs with App-ID can identify ICMP tunneling via payload analysis and anomaly detection. For SOCKS port detection, the Tor Browser and privacy tools are the most common false positive source — allowlist these process names only on endpoints where Tor is organizationally approved, not globally. In high-security environments, ICMP egress to external IPs should be blocked entirely at the perimeter firewall except from designated monitoring hosts; this eliminates the ICMP tunnel surface and removes the need for behavioral detection. For ESXi environments, enable vSphere audit logging and monitor vmkernel.log for unexpected VMCI vsock activity, as standard network monitoring is blind to VMCI communications.

Hunting Queries

Hunt for ICMP beaconing patterns by analyzing connection frequency and regularity between a process and external IP. ICMP tunneling tools like ptunnel, PingTunnel, and ICMP-based C2 frameworks typically poll their C2 at fixed intervals (30s, 60s, 5m). This query identifies statistically regular ICMP timing patterns that differ from the main detection's focus on protocol/process anomalies.

Hunting — KQL
kql 
// Hunt: ICMP beaconing — frequent ICMP to same external IP from same process
// This pattern differs from the main detection by focusing on connection regularity
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where Protocol == "Icmp"
| where RemoteIPType == "Public"
| summarize
    ConnectionCount = count(),
    UniqueHours = dcount(bin(Timestamp, 1h)),
    AvgTimeBetweenConnections = datetime_diff('second', max(Timestamp), min(Timestamp)) / count(),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    TotalBytesSent = sum(SentBytes),
    TotalBytesReceived = sum(ReceivedBytes)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP
| where ConnectionCount > 50 and UniqueHours > 2
| extend AvgPayloadSize = (TotalBytesSent + TotalBytesReceived) / ConnectionCount
| extend BeaconingIndicator = case(
    AvgTimeBetweenConnections between (25 .. 35), "Regular_30s_Beacon",
    AvgTimeBetweenConnections between (55 .. 65), "Regular_60s_Beacon",
    AvgTimeBetweenConnections between (295 .. 305), "Regular_5m_Beacon",
    "Irregular")
| where BeaconingIndicator != "Irregular" or (ConnectionCount > 200 and UniqueHours > 4)
| sort by ConnectionCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 protocol="icmp"
| eval dest_ip = DestinationIp
| eval src_process = Image
| bucket _time span=1h as hour_bucket
| stats count as conn_count, dc(hour_bucket) as unique_hours, sum(eval(tonumber(DestinationPort))) as total_bytes, earliest(_time) as first_seen, latest(_time) as last_seen
    by src_process, CommandLine, dest_ip, host
| where conn_count > 50 AND unique_hours > 2
| eval avg_interval_secs = (last_seen - first_seen) / conn_count
| eval beacon_pattern = case(
    avg_interval_secs >= 25 AND avg_interval_secs <= 35, "30s_beacon",
    avg_interval_secs >= 55 AND avg_interval_secs <= 65, "60s_beacon",
    avg_interval_secs >= 285 AND avg_interval_secs <= 315, "5m_beacon",
    "irregular")
| where beacon_pattern != "irregular" OR conn_count > 200
| table host, src_process, CommandLine, dest_ip, conn_count, unique_hours, avg_interval_secs, beacon_pattern, first_seen, last_seen
| sort - conn_count

Hunt for hosts generating external UDP traffic without corresponding DNS resolution activity. Malware using custom UDP C2 protocols often connects directly to hard-coded C2 IP addresses, bypassing DNS entirely. This absence of DNS queries paired with external UDP connections is a distinctive pattern not covered by the main detection's protocol/port analysis.

Hunting — KQL
kql 
// Hunt: UDP C2 without preceding DNS — malware using direct IP bypasses DNS-based detection
// Correlates UDP connections to external IPs with absence of DNS queries for that IP's hostname
let UDPExternalConnections = DeviceNetworkEvents
| where Timestamp > ago(7d)
| where Protocol == "Udp"
| where RemoteIPType == "Public"
| where RemotePort !in (53, 67, 68, 123, 443, 500, 4500, 51820, 1194, 5353)
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort;
let DNSResolutions = DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort == 53
| project DNSTimestamp = Timestamp, DeviceName;
UDPExternalConnections
| join kind=leftanti (
    DNSResolutions
    | where DNSTimestamp > ago(7d)
) on $left.DeviceName == $right.DeviceName
| summarize
    ConnectionCount = count(),
    UniqueDestIPs = dcount(RemoteIP),
    UniquePorts = make_set(RemotePort),
    Processes = make_set(InitiatingProcessFileName)
    by DeviceName
| where UniqueDestIPs > 2 or ConnectionCount > 20
| sort by ConnectionCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 Initiated=true
| eval dest_port_num = tonumber(DestinationPort)
| eval protocol_lower = lower(Protocol)
| eval is_dns = if(dest_port_num=53, 1, 0)
| eval is_unusual_udp = if(protocol_lower="udp" AND NOT dest_port_num IN(53,67,68,123,443,500,4500,5353,51820,1194), 1, 0)
| stats sum(is_dns) as dns_queries, sum(is_unusual_udp) as udp_connections, values(DestinationIp) as dest_ips, values(Image) as processes
    by host, bin(_time, 1h)
| where udp_connections > 5 AND dns_queries < 2
| eval dns_to_udp_ratio = dns_queries / (udp_connections + 1)
| where dns_to_udp_ratio < 0.1
| sort - udp_connections

Enterprise-wide hunt for SOCKS proxy connections to identify shared C2 infrastructure across multiple compromised hosts. When the same external IP:port receives SOCKS connections from multiple hosts, it indicates coordinated compromise with centralized C2. This hunt differs from the main detection by correlating across devices rather than alerting per-host.

Hunting — KQL
kql 
// Hunt: SOCKS proxy connections across the enterprise — identify scope and common C2 infrastructure
// Looks for SOCKS port usage patterns that may indicate coordinated infection
let SocksPorts = dynamic([9050, 9051, 4145, 1080, 1081, 9150, 8118]);
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort in (SocksPorts)
| where RemoteIPType == "Public"
| summarize
    AffectedDevices = dcount(DeviceName),
    DeviceList = make_set(DeviceName, 20),
    ConnectionCount = count(),
    UniqueProcesses = make_set(InitiatingProcessFileName, 10),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by RemoteIP, RemotePort
| extend DurationHours = datetime_diff('hour', LastSeen, FirstSeen)
| where AffectedDevices > 1 or ConnectionCount > 50 or DurationHours > 24
| sort by AffectedDevices desc, ConnectionCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
| eval dest_port_num = tonumber(DestinationPort)
| where dest_port_num IN(9050, 9051, 4145, 1080, 1081, 9150, 8118)
| stats count as conn_count, dc(host) as affected_hosts, values(host) as host_list, values(Image) as processes, earliest(_time) as first_seen, latest(_time) as last_seen
    by DestinationIp, dest_port_num
| eval duration_hours = round((last_seen - first_seen) / 3600, 1)
| where affected_hosts > 1 OR conn_count > 50 OR duration_hours > 24
| sort - affected_hosts, - conn_count

Atomic Red Team Tests

Test 1 ICMP Large Payload Flood (ICMP Tunnel Simulation)
windows

Sends high-frequency ICMP echo requests with maximum payload size to an external IP, simulating the traffic pattern of ICMP tunneling tools like PingTunnel, ptunnel-ng, and icmptunnel. Normal ping uses 32-56 byte payloads; tunneling tools fill ICMP packets to MTU size (1472 bytes) to maximize bandwidth. This generates Sysmon Event ID 3 records and fires the unexpected ICMP detection signal if run from a non-standard process context.

Command

powershell 
cmd.exe /c "FOR /L %i IN (1,1,50) DO ping -n 1 -l 1472 8.8.8.8"

Expected Telemetry

Sysmon Event ID 3: Network connections with Protocol=ICMP, DestinationIp=8.8.8.8, Image=C:\Windows\System32\cmd.exe (or ping.exe as child). Windows Security Event ID 5156 (WFP permitted connection) with Protocol=1 (ICMP). Note: This test uses cmd.exe calling ping.exe, so the ICMP processes as ping.exe in most telemetry — to test the unexpected-process signal, replace with a script calling ping from PowerShell or a custom executable context.

Expected Detection

KQL: IsUnexpectedICMP fires only if InitiatingProcessFileName is not in the LegitICMPProcesses allowlist. If ping.exe is the logged initiating process, test may not trigger — this is correct behavior. To trigger the ICMP signal, run the command from a PowerShell download cradle context where powershell.exe becomes the initiating process.

Test 2 SOCKS5 Proxy Connection via PowerShell (Gamaredon-style)
windows

Simulates a SOCKS5 proxy connection from PowerShell, replicating the pattern used by Gamaredon Group which routes C2 traffic through SOCKS5 proxies on port 9050 (also the default Tor SOCKS5 port). The connection attempt to localhost:9050 will fail (no listener) but generates the process-level network connection event that fires the SOCKS detection signal.

Command

powershell 
powershell.exe -NoProfile -Command "try { $client = New-Object System.Net.Sockets.TcpClient; $client.Connect('127.0.0.1', 9050); $client.Close() } catch { Write-Host 'Connection attempt to SOCKS port completed (expected failure if no listener)' }"

Expected Telemetry

Sysmon Event ID 3: Network Connection with Image=powershell.exe, DestinationIp=127.0.0.1, DestinationPort=9050, Protocol=tcp. Windows Security Event ID 5156 (WFP) for the connection attempt. The connection will fail with a refused error but the event fires before the refusal. For external SOCKS detection, substitute 127.0.0.1 with any public test IP.

Expected Detection

KQL: IsSocksPort=true fires on RemotePort=9050. DetectionSignal='SOCKS_Proxy_Port_9050'. RiskScore=75. SPL: is_socks=1, dest_port_num=9050, Image=powershell.exe which is not in the browser allowlist — detection_signal='SOCKS_Proxy_Port_9050', risk_score=75.

Test 3 Custom UDP Beacon to Non-Standard Port (Raw UDP C2 Simulation)
windows

Uses Python to create a raw UDP socket and send beaconing packets to a non-standard port on an external IP, simulating custom UDP C2 protocols as used by PlugX (raw UDP mode), Clambling, and Gelsemium malware families. Sends 20 beacon packets at 3-second intervals to simulate realistic beaconing cadence. Target is Google DNS to ensure the UDP packets are routable without requiring an actual C2 server.

Command

powershell 
python3 -c "import socket, time; s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM); [s.sendto(b'ARGUS_TEST_BEACON_' + str(i).encode(), ('8.8.8.8', 4444)) or time.sleep(3) for i in range(20)]; s.close(); print('UDP beaconing test complete')"

Expected Telemetry

Sysmon Event ID 3: 20 network connection events with Image=python3.exe (or python.exe), Protocol=udp, DestinationIp=8.8.8.8, DestinationPort=4444. Windows Filtering Platform Event ID 5156 for each UDP send. Note: UDP packets to 8.8.8.8:4444 will be dropped by Google but the outbound events still fire.

Expected Detection

KQL: IsUnusualUDP=true fires — Protocol='Udp', RemotePort=4444 is not in CommonUDPPorts, python3.exe is not in LegitUDPProcesses. DetectionSignal='Unusual_UDP_Port_4444', RiskScore=60. SPL: is_unusual_udp=1, dest_port_num=4444, Image contains python, risk_score=60.

Test 4 ICMP Tunnel Tool Execution (ptunnel-ng simulation on Linux)
linux

Simulates execution of an ICMP tunneling tool on Linux by using hping3 to send crafted ICMP packets with custom payload data, replicating the technique used by TSCookie and Anchor malware which embed C2 data in ICMP echo payloads. hping3 differs from standard ping in that it allows arbitrary payload data and rate control, making it detectable as a non-standard ICMP source.

Command

bash 
hping3 --icmp --data 64 --count 30 --interval u500000 8.8.8.8 2>/dev/null; echo 'ICMP probe test complete'

Expected Telemetry

auditd SYSCALL records for socket() with AF_INET and SOCK_RAW type (raw socket creation). syslog/kern.log: ICMP outbound traffic from hping3 process. If Zeek is deployed on network: icmp.log entries with unusual payload length (64 bytes + ICMP header) and high frequency (2 packets/second). Linux /proc/net/icmp shows active ICMP sockets during execution.

Expected Detection

KQL: IsUnexpectedICMP fires if hping3 is not in LegitICMPProcesses allowlist — DetectionSignal='ICMP_From_Unexpected_Process_hping3'. SPL (CommonSecurityLog/Zeek): icmp traffic from non-standard tool. Linux auditd: raw socket creation audit event for hping3 process — can be detected via auditd rule: -a always,exit -F arch=b64 -S socket -F a0=2 -F a1=3 -k raw_socket_creation

Test 5 SOCKS5 Proxy Connection via Netcat (Unix)
linux

Uses netcat (ncat) with SOCKS5 proxy option to establish a proxied connection, simulating how malware frameworks route C2 through SOCKS5 relays. This tests the SOCKS detection signal on Linux/macOS systems where Sysmon equivalents (auditd, endpoint agents) monitor network connections.

Command

bash 
ncat --proxy 127.0.0.1:9050 --proxy-type socks5 example.com 80 2>&1 | head -3; echo 'SOCKS5 connection test complete'

Expected Telemetry

auditd SYSCALL: connect() syscall from ncat process to 127.0.0.1:9050. If SOCKS proxy is listening, a subsequent connection to example.com:80 is initiated. syslog: ncat network activity. Linux endpoint agent (Elastic Agent, Falcon sensor): network connection event with destination port 9050.

Expected Detection

Linux endpoint detection: connection to port 9050 from ncat which is not a standard browser process — fires SOCKS proxy detection. KQL equivalent: IsSocksPort=true for RemotePort=9050, InitiatingProcessFileName='ncat' not in browser allowlist.

Related Detections

Tactic Hub

TA0011Command and Control

Related Techniques

T1071Application Layer ProtocolT1090ProxyT1090.001Internal ProxyT1572Protocol TunnelingT1001Data ObfuscationT1573Encrypted ChannelT1041Exfiltration Over C2 ChannelT1205.002Socket FiltersT1548Abuse Elevation Control Mechanism

Same Tactic: Command and Control

Popular Detections