T1205

Traffic Signaling

Defense Evasion Persistence Command and Control Last updated:

Adversaries may use traffic signaling to hide open ports or other malicious functionality used for persistence or command and control. Traffic signaling involves the use of a magic value or sequence—such as a specific string in a packet, a sequence of connection attempts to closed ports (port knocking), or a Wake-on-LAN magic packet—to trigger a special response from a compromised system. Passive listeners implemented via libpcap or raw sockets sniff network traffic without binding to a visible port, making them invisible to standard port scanners. Real-world examples include Turla Penquin (sniffs TCP/UDP for magic packets before C2 activation), Ryuk ransomware (Wake-on-LAN UDP broadcasts for lateral movement to powered-off systems), Winnti for Linux (passive listener activated by a magic value), SYNful Knock (Cisco IOS router backdoor activated via crafted SYN packets), ZIPLINE (triggered by a specific SSH banner string), J-magic (monitors TCP for one of five predefined parameter values then spawns a reverse shell), and REPTILE (listens for specialized packets in TCP, UDP, or ICMP for activation).

What is T1205 Traffic Signaling?

Traffic Signaling (T1205) maps to the Defense Evasion and Persistence and Command and Control tactics — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for Traffic Signaling, covering the data sources and telemetry it touches: Module: Module Load, Network Traffic: Network Connection Creation, Network Traffic: Network Traffic Flow, 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
Defense Evasion Persistence Command and Control
Technique
T1205 Traffic Signaling
Canonical reference
https://attack.mitre.org/techniques/T1205/
Microsoft Sentinel / Defender
kusto 
let PacketCaptureLibs = dynamic(["wpcap.dll", "npcap.dll", "packet.dll"]);
let LegitNetworkTools = dynamic(["wireshark.exe", "tshark.exe", "dumpcap.exe", "rawcap.exe", "networkminer.exe", "fiddler.exe", "procexp.exe", "procexp64.exe"]);
// Signal 1: Unexpected process loading packet capture libraries (passive listener / magic packet sniffer indicator)
let PacketSnifferLoad = DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where FileName has_any (PacketCaptureLibs)
| where not(InitiatingProcessFileName has_any (LegitNetworkTools))
| project Timestamp, DeviceName, AccountName,
          ProcessName = InitiatingProcessFileName,
          CommandLine = InitiatingProcessCommandLine,
          TargetInfo = strcat("Loaded packet capture library: ", FileName),
          AlertType = "PacketCaptureLibraryLoad";
// Signal 2: Wake-on-LAN magic packet transmission (Ryuk ransomware lateral movement pattern)
let WoLTransmission = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where Protocol =~ "Udp"
| where RemotePort in (7, 9)
| where RemoteIP has "255" or RemoteIP =~ "255.255.255.255"
| project Timestamp, DeviceName,
          AccountName = InitiatingProcessAccountName,
          ProcessName = InitiatingProcessFileName,
          CommandLine = InitiatingProcessCommandLine,
          TargetInfo = strcat("WoL UDP to ", RemoteIP, ":", tostring(RemotePort)),
          AlertType = "WakeOnLanMagicPacket";
// Signal 3: Sequential failed connections to multiple distinct ports within 60-second window (port knocking pattern)
let PortKnocking = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionFailed"
| summarize
    PortCount = dcount(RemotePort),
    PortList = make_set(RemotePort, 10),
    AttemptCount = count(),
    FirstAttempt = min(Timestamp),
    ProcessCmdLine = any(InitiatingProcessCommandLine),
    ActName = any(InitiatingProcessAccountName)
    by DeviceName, ProcName = InitiatingProcessFileName, RemoteIP, TimeBin = bin(Timestamp, 60s)
| where PortCount >= 3
| project Timestamp = FirstAttempt, DeviceName, AccountName = ActName,
          ProcessName = ProcName, CommandLine = ProcessCmdLine,
          TargetInfo = strcat("Port knocking: ", tostring(PortCount), " unique ports to ", RemoteIP, " within 60s"),
          AlertType = "SequentialPortKnocking";
union PacketSnifferLoad, WoLTransmission, PortKnocking
| sort by Timestamp desc

Multi-signal KQL detection for Traffic Signaling (T1205) across three primary vectors using Microsoft Defender for Endpoint tables. Signal 1 uses DeviceImageLoadEvents to identify unexpected processes loading packet capture libraries (wpcap.dll, npcap.dll, packet.dll) that may indicate passive magic packet listeners as seen in Turla Penquin and Winnti for Linux. Signal 2 uses DeviceNetworkEvents to detect UDP transmissions to broadcast addresses on Wake-on-LAN ports 7 and 9, matching the Ryuk ransomware lateral movement pattern. Signal 3 uses DeviceNetworkEvents to detect sequential TCP connection failures to three or more distinct ports on the same destination within a 60-second window, matching port knocking activation sequences.

high severity medium confidence

Data Sources

Module: Module Load Network Traffic: Network Connection Creation Network Traffic: Network Traffic Flow Microsoft Defender for Endpoint

Required Tables

DeviceImageLoadEvents DeviceNetworkEvents

False Positives

  • Network monitoring agents (Datadog, PRTG, SolarWinds) that load Npcap/WinPcap libraries for legitimate packet-level telemetry collection
  • IT management and help desk tools (ManageEngine Desktop Central, custom WoL scripts, PDQ Deploy) that legitimately send Wake-on-LAN packets to power on workstations
  • Authorized penetration testing or vulnerability scanning tools (nmap, masscan) that generate sequential port connection failures during scheduled assessments
  • VPN clients and network virtualization software (VMware, VirtualBox, OpenVPN) that load packet capture drivers during normal initialization
  • Backup or endpoint management platforms that use WoL to wake systems for scheduled maintenance jobs outside business hours
  • Service discovery and health-check mechanisms in microservice environments that probe multiple ports on container hosts in rapid succession

Sigma rule & cross-platform mapping

The detection logic for Traffic Signaling (T1205) 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 T1205 Sigma rules on detection.fyi

Platform-specific guides for T1205

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-19 Research depth: deep
References (8)

Testing Methodology

Validate this detection against 4 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 1Wake-on-LAN Magic Packet Broadcast

    Expected signal: Sysmon Event ID 3: Network Connection from powershell.exe to 255.255.255.255:9 via UDP protocol. DeviceNetworkEvents in MDE will show InitiatingProcessFileName=powershell.exe, RemoteIP=255.255.255.255, RemotePort=9, Protocol=Udp. The UDP payload will contain the WoL signature (6x 0xFF + target MAC repeated 16 times) visible in full packet capture.

  2. Test 2Port Knocking Sequence Simulation (Sequential Failed Connections)

    Expected signal: Sysmon Event ID 3: Four network connection events from powershell.exe to 127.0.0.1 on ports 7000, 8000, 9000, 10000 within approximately 1 second. ActionType will be ConnectionFailed for each since no service listens on these ports. DeviceNetworkEvents in MDE will show sequential ConnectionFailed events with distinct RemotePort values from the same initiating process.

  3. Test 3Packet Capture Library Load from Non-Network-Tool Process

    Expected signal: Sysmon Event ID 7: ImageLoad event with Image path ending in powershell.exe (or python3.exe) and ImageLoaded path containing wpcap.dll. DeviceImageLoadEvents in MDE: InitiatingProcessFileName=powershell.exe or python3.exe, FileName=wpcap.dll. The load will appear regardless of whether the DLL export call succeeds.

  4. Test 4Linux Raw Packet Socket Creation (Passive Listener Simulation)

    Expected signal: Linux auditd with rule 'auditctl -a always,exit -F arch=b64 -S socket -F a0=17 -k raw_socket_creation' will generate AUDIT_SYSCALL record: syscall=socket, a0=17 (AF_PACKET), a1=3 (SOCK_RAW), process=python3. During the 2-second sleep, /proc/<PID>/net/packet will show the active raw socket. Sysmon for Linux (if deployed) will generate a NetworkConnect event for raw socket creation.

Response Playbook

Triage

  1. Identify the alert type — PacketCaptureLibraryLoad, WakeOnLanMagicPacket, or SequentialPortKnocking — as each requires a distinct triage path
  2. For PacketCaptureLibraryLoad: identify the process that loaded the pcap library and determine whether it has a legitimate network capture purpose. Check the process binary path, digital signature (Get-AuthenticodeSignature), parent process, and whether it appears in your authorized software inventory. A signed, IT-managed agent loading wpcap.dll is expected; an unsigned binary in %TEMP% or %APPDATA% is highly suspicious
  3. For WakeOnLanMagicPacket: determine if the source host is a known IT management system. Verify whether a change ticket or maintenance window exists. Cross-reference the destination MAC/IP against asset inventory to confirm the target is an authorized endpoint. WoL from non-IT workstations or after-hours from unexpected sources warrants immediate escalation
  4. For SequentialPortKnocking: review the port sequence contacted — are they sequential integers, known magic sequences, or random? Check whether the destination IP is an internal server or external host. If the destination is external, this is likely a client-side port knock to unlock a remote backdoor
  5. Check for concurrent or subsequent suspicious activity within 10 minutes of the alert: new outbound connections to external IPs on non-standard ports, new listening services (netstat change), privilege escalation events, or lateral movement indicators
  6. Examine the parent process chain of the triggering process — was it spawned by an Office application, browser, script host (wscript.exe, cscript.exe), or other unexpected parent that could indicate initial access via a malicious document?
  7. On Linux hosts, check /proc/<PID>/net/packet and /proc/<PID>/net/raw for any process with active raw or packet sockets that is not a recognized network tool

Containment

  1. If a passive listener is confirmed with active external C2 connections: immediately isolate the endpoint using EDR network isolation or emergency VLAN quarantine to cut communication without alerting the adversary via process termination
  2. If Wake-on-LAN-based lateral movement is confirmed: identify all systems that received WoL packets and verify their current state; isolate any hosts that were woken and may now be running ransomware payload. Disable WoL at the BIOS/UEFI level on non-essential endpoints via Group Policy (HKLM\SYSTEM\CurrentControlSet\Services\NDIS\Parameters\WakeOnLanCapabilities)
  3. If a port knock sequence successfully opened a previously closed port: block the newly opened port immediately at the perimeter firewall and endpoint-level firewall (Windows Firewall or iptables), then investigate what service was exposed
  4. Collect a full memory dump of the suspected listener process before terminating it: use ProcDump (procdump.exe -ma <PID> C:\Forensics\listener_dump.dmp) on Windows or gcore on Linux to preserve the magic packet values, C2 protocol implementation, and embedded keys
  5. Revoke and rotate credentials for any account that was active on the affected system during the traffic signaling window
  6. If a network device (router/switch) is suspected of running a SYNful Knock-style implant: take the device offline immediately, restore firmware from a known-good vendor image, change all management credentials, and audit all ACLs and routing tables for adversary modifications

Evidence Collection

  1. Memory dump of the suspected passive listener process: procdump.exe -ma <PID> C:\Forensics\<processname>_dump.dmp (Windows) or sudo gcore -o /tmp/listener_dump <PID> (Linux) — preserves embedded magic values, C2 protocol logic, and decryption keys that are only present in memory
  2. Network PCAP from the affected endpoint: run a targeted capture filtered to the suspicious process PID using Wireshark capture filters or tcpdump during the investigation window to identify actual magic packet values and communication patterns
  3. Sysmon Event ID 7 (ImageLoad) logs: extract the full DLL load history for the suspicious process to understand all packet capture and networking libraries loaded, with precise timestamps
  4. Sysmon Event ID 3 (NetworkConnect) logs: document all network connections (inbound and outbound) established before and after the traffic signal event; focus on new connections following a port-knock sequence
  5. Firewall/packet filter rule changes: on Linux, run 'iptables -L -n -v --line-numbers' and 'nft list ruleset' to identify rules recently added to ACCEPT traffic on previously closed ports as a result of port knocking activation
  6. Process listing with network socket state: run 'netstat -ano' combined with 'tasklist /fo csv' (Windows) or 'ss -tulnp' (Linux) to identify any new listening services that appeared after the traffic signal event
  7. Linux kernel module inventory: run 'lsmod' and diff against a known-good baseline to detect kernel modules loaded as part of socket filter implants (T1205.002); check /proc/modules and dmesg for module load messages
  8. File system timeline: check for new executables, scripts, shared libraries, or configuration files created within the 30-minute window around the traffic signal event using Sysmon Event ID 11 or DeviceFileEvents

Escalation Criteria

  • ! Confirmed passive listener (pcap library loaded by unknown process) with subsequent outbound connections to external IPs — especially if the process has no legitimate network monitoring purpose
  • ! Evidence that a port knock sequence successfully opened a previously closed port and the adversary connected to the newly opened service within minutes of the knock
  • ! Multiple endpoints showing the same WoL-based lateral movement pattern within a short timeframe — indicative of active ransomware propagation across the environment
  • ! Discovery of a rootkit or kernel-level BPF socket filter (T1205.002) — the presence of a kernel module intercepting raw traffic indicates nation-state-level threat actor capability
  • ! Traffic signaling activity detected on a network device (router or switch) rather than an endpoint — SYNful Knock-style firmware implants require immediate escalation to network security and vendor incident response
  • ! The magic packet listener process is running as SYSTEM, root, or a high-privilege service account with no corresponding change ticket, authorized deployment record, or known software association

Investigation Guide

Forensic Artifacts

  • > Windows Registry: HKLM\SYSTEM\CurrentControlSet\Services\npcap — Npcap driver service registration indicating packet capture capability was installed on the system
  • > Windows File System: C:\Windows\System32\Npcap\wpcap.dll, npcap.dll, Packet.dll — packet capture library files; check creation/modification timestamps against software deployment records
  • > Windows Prefetch: C:\Windows\Prefetch\<PROCESS>.EXE-*.pf — execution timestamps and loaded DLL list for the suspected listener process; confirms whether pcap libraries were loaded in past executions
  • > Linux /proc/<PID>/net/packet — shows active AF_PACKET raw sockets for a running process; a non-network-tool process with entries here is highly suspicious
  • > Linux /proc/<PID>/net/raw — shows active IPPROTO_RAW sockets; used by passive listeners that need to inspect raw IP traffic without binding to a port
  • > Linux /proc/<PID>/maps — memory maps showing all loaded shared libraries including libpcap.so; confirms whether a process has packet capture capability loaded in memory
  • > Linux auditd logs — AUDIT_SYSCALL records for socket() calls with a0=17 (AF_PACKET) or a2=SOCK_RAW; generated when a process creates a raw network socket
  • > Linux iptables/nftables rules — new ACCEPT rules for previously closed ports added via 'iptables -I INPUT ...' or 'nft add rule' commands; indicates successful port-knocking activation triggered a firewall rule change
  • > Network PCAP — UDP payloads on port 7 or 9: first 6 bytes are FF:FF:FF:FF:FF:FF followed by the target MAC address repeated 16 times confirms WoL magic packet; sequential SYN packets to closed ports from the same source IP within milliseconds confirms port knocking
  • > Windows Event Log: System channel, Event ID 7045 (new service installed) — check for services installed shortly after a traffic signal event, as the signal may have triggered a backdoor service installation

Tuning Guidance

Traffic Signaling detections require environment-specific baseline tuning. For PacketCaptureLibraryLoad: build an explicit allowlist of authorized processes permitted to load pcap libraries (security agents, network monitoring platforms, authorized analysis tools) keyed on process path and digital signature. Flag only unsigned or unlisted processes — this reduces noise significantly while preserving detection fidelity for novel implants. For WakeOnLanMagicPacket: identify and allowlist authorized WoL senders by IP address (help desk workstations, SCCM/MECM servers, asset management systems) and suppress their alerts. Alert on any WoL transmission from workstation-class devices, user laptops, or hosts outside the authorized management IP range. For SequentialPortKnocking: the 3-port/60-second threshold catches most automated knock sequences but may fire on legitimate scanning. Raise the threshold to 5 ports if false positive rates are high. Build an allowlist of authorized scanner IPs (vulnerability management platforms, network discovery tools) and exclude them. For Linux environments: supplement Windows detection with auditd rules that catch raw socket creation — specifically socket() syscalls with a0=17 (AF_PACKET) combined with execve() of unknown binaries. This combination has very high fidelity for traffic signaling backdoors on Linux servers. Additionally consider adding a secondary correlation: flag when a process both loads a pcap library AND establishes an outbound network connection within five minutes, as this two-signal combination nearly eliminates passive monitoring tools that capture but never connect externally.

Hunting Queries

Hunt for non-standard processes persistently loading packet capture libraries across multiple devices or over multiple days. A single incidental load may be noise; repeated loads or spread across many endpoints indicates a persistent passive listener or deployed malware family using libpcap for magic packet C2 activation. Focus on processes with high UniqueDevices count as indicators of widespread implant deployment.

Hunting — KQL
kql 
// Hunt for processes persistently loading pcap libraries across multiple systems or over multiple days
DeviceImageLoadEvents
| where Timestamp > ago(7d)
| where FileName has_any ("wpcap.dll", "npcap.dll", "packet.dll")
| where not(InitiatingProcessFileName has_any ("wireshark.exe", "tshark.exe", "dumpcap.exe", "rawcap.exe", "fiddler.exe", "networkminer.exe"))
| summarize
    LoadCount = count(),
    UniqueDevices = dcount(DeviceName),
    DeviceList = make_set(DeviceName, 5),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    CommandLines = make_set(InitiatingProcessCommandLine, 3)
    by InitiatingProcessFileName, InitiatingProcessSHA256
| extend DaysActive = datetime_diff('day', LastSeen, FirstSeen)
| where LoadCount > 1 or UniqueDevices > 1
| sort by UniqueDevices desc, LoadCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=7
  (ImageLoaded="*\\wpcap.dll" OR ImageLoaded="*\\npcap.dll" OR ImageLoaded="*\\packet.dll")
  NOT (Image="*\\wireshark.exe" OR Image="*\\tshark.exe" OR Image="*\\dumpcap.exe" OR Image="*\\rawcap.exe" OR Image="*\\fiddler.exe")
| stats count as LoadCount, dc(host) as UniqueDevices, values(host) as DeviceList, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(CommandLine) as CommandLines by Image, Hashes
| where LoadCount > 1 OR UniqueDevices > 1
| eval DaysActive=round((LastSeen - FirstSeen) / 86400, 1)
| sort - UniqueDevices, - LoadCount

Hunt for processes making high-frequency or broad UDP transmissions to Wake-on-LAN ports (7, 9) or less common signal ports (2304, 40000). Legitimate WoL tools typically target one to a few specific hosts; ransomware (Ryuk) and worms send to many targets rapidly as part of lateral movement. A single process sending to more than two unique IPs on WoL ports is a strong indicator of malicious WoL-based propagation.

Hunting — KQL
kql 
// Hunt for outbound UDP to WoL and signal ports from multiple processes or high-frequency senders
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where Protocol =~ "Udp"
| where RemotePort in (7, 9, 2304, 40000)
| summarize
    SendCount = count(),
    UniqueTargets = dcount(RemoteIP),
    TargetIPs = make_set(RemoteIP, 10),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where UniqueTargets > 2 or SendCount > 10
| sort by UniqueTargets desc, SendCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  Protocol=udp (DestinationPort=7 OR DestinationPort=9 OR DestinationPort=2304 OR DestinationPort=40000)
| stats count as SendCount, dc(DestinationIp) as UniqueTargets, values(DestinationIp) as TargetIPs, earliest(_time) as FirstSeen, latest(_time) as LastSeen by host, Image, CommandLine
| where UniqueTargets > 2 OR SendCount > 10
| sort - UniqueTargets, - SendCount

Hunt for sustained port knocking patterns that evade the 60-second window detection by spreading the knock sequence across multiple sessions or hours. Adversaries using stealthy port knocking (e.g., one knock per minute or once per day) will not trigger the short-window alert but will accumulate in this longer-horizon query. High PortCount against a single RemoteIP from a single process over many days is a strong persistent C2 indicator.

Hunting — KQL
kql 
// Hunt for long-term port knocking patterns: same host connecting to many distinct ports on the same destination over 7 days
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where ActionType == "ConnectionFailed"
| summarize
    PortCount = dcount(RemotePort),
    PortList = make_set(RemotePort, 20),
    SessionCount = count(),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by DeviceName, InitiatingProcessFileName, RemoteIP
| where PortCount >= 5 and SessionCount >= 5
| extend SpreadDays = datetime_diff('day', LastSeen, FirstSeen)
| sort by PortCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 Initiated=true
| stats dc(DestinationPort) as PortCount, values(DestinationPort) as PortList, count as SessionCount, earliest(_time) as FirstSeen, latest(_time) as LastSeen by host, Image, DestinationIp
| where PortCount >= 5 AND SessionCount >= 5
| eval SpreadDays=round((LastSeen - FirstSeen) / 86400, 1)
| sort - PortCount

Atomic Red Team Tests

Test 1 Wake-on-LAN Magic Packet Broadcast
windows

Simulates the Wake-on-LAN magic packet transmission used by Ryuk ransomware for lateral movement to powered-off systems. Sends a standard WoL UDP broadcast to port 9 on the local subnet using PowerShell. The magic packet consists of 6 bytes of 0xFF followed by the target MAC address repeated 16 times (102 bytes total). This test generates the network telemetry that the WakeOnLanMagicPacket detection signal targets.

Command

powershell 
$mac = "AABBCCDDEEFF"; $macBytes = @(); for ($i = 0; $i -lt $mac.Length; $i += 2) { $macBytes += [Convert]::ToByte($mac.Substring($i, 2), 16) }; $header = [byte[]](0xFF,0xFF,0xFF,0xFF,0xFF,0xFF); $payload = $header; 1..16 | ForEach-Object { $payload += $macBytes }; $udp = New-Object System.Net.Sockets.UdpClient; $udp.EnableBroadcast = $true; $udp.Send($payload, $payload.Length, "255.255.255.255", 9) | Out-Null; $udp.Close(); Write-Host "WoL magic packet sent: $($payload.Length) bytes to 255.255.255.255:9"

Expected Telemetry

Sysmon Event ID 3: Network Connection from powershell.exe to 255.255.255.255:9 via UDP protocol. DeviceNetworkEvents in MDE will show InitiatingProcessFileName=powershell.exe, RemoteIP=255.255.255.255, RemotePort=9, Protocol=Udp. The UDP payload will contain the WoL signature (6x 0xFF + target MAC repeated 16 times) visible in full packet capture.

Expected Detection

KQL WoLTransmission signal fires: Protocol=Udp, RemotePort=9, RemoteIP contains '255', AlertType=WakeOnLanMagicPacket. SPL EventCode=3 with Protocol=udp, DestinationPort=9, DestinationIp=255.255.255.255 alert triggers. Hunting query will surface powershell.exe as the initiating process on the WoL port.

Test 2 Port Knocking Sequence Simulation (Sequential Failed Connections)
windows

Simulates the outbound port knocking sequence an adversary workstation sends to unlock a backdoor on a compromised server. Makes four sequential TCP connection attempts to closed ports in rapid succession, generating the ConnectionFailed network events that the SequentialPortKnocking detection signal detects. Uses localhost to avoid external network traffic.

Command

powershell 
$Target = "127.0.0.1"; $KnockSequence = @(7000, 8000, 9000, 10000); Write-Host "Initiating port knock sequence to ${Target}: $($KnockSequence -join ' -> ')"; foreach ($Port in $KnockSequence) { $Client = New-Object System.Net.Sockets.TcpClient; try { $Client.Connect($Target, $Port) } catch { Write-Host "Knock port $Port: attempt completed" }; $Client.Close(); Start-Sleep -Milliseconds 150 }; Write-Host "Port knocking sequence complete"

Expected Telemetry

Sysmon Event ID 3: Four network connection events from powershell.exe to 127.0.0.1 on ports 7000, 8000, 9000, 10000 within approximately 1 second. ActionType will be ConnectionFailed for each since no service listens on these ports. DeviceNetworkEvents in MDE will show sequential ConnectionFailed events with distinct RemotePort values from the same initiating process.

Expected Detection

KQL PortKnocking signal fires: PortCount=4 (>= 3 threshold), AttemptCount=4, RemoteIP=127.0.0.1 within the 60-second bin. AlertType=SequentialPortKnocking. SPL hunting query will surface powershell.exe with PortCount=4 against 127.0.0.1 within the time window.

Test 3 Packet Capture Library Load from Non-Network-Tool Process
windows

Simulates a traffic signaling passive listener by loading the wpcap.dll packet capture library from a PowerShell process via ctypes or P/Invoke. Malware such as Turla Penquin, Winnti for Linux, and Chaos uses packet capture libraries to sniff all network traffic for magic packets without binding to a visible listening port. Requires Npcap to be installed.

Command

powershell 
python3 -c "import ctypes; lib = ctypes.CDLL('wpcap.dll'); print('wpcap.dll loaded successfully — raw packet capture available from this process')" 2>&1; if ($LASTEXITCODE -ne 0) { Write-Host 'Python not available or wpcap.dll not found. Trying PowerShell P/Invoke:'; Add-Type -TypeDefinition 'using System; using System.Runtime.InteropServices; public class PcapTest { [DllImport("wpcap.dll", EntryPoint="pcap_findalldevs")] public static extern int FindDevs(ref IntPtr a, System.Text.StringBuilder e); }' -ErrorAction SilentlyContinue; Write-Host 'wpcap.dll referenced via P/Invoke from powershell.exe' }

Expected Telemetry

Sysmon Event ID 7: ImageLoad event with Image path ending in powershell.exe (or python3.exe) and ImageLoaded path containing wpcap.dll. DeviceImageLoadEvents in MDE: InitiatingProcessFileName=powershell.exe or python3.exe, FileName=wpcap.dll. The load will appear regardless of whether the DLL export call succeeds.

Expected Detection

KQL PacketSnifferLoad signal fires: FileName matches PacketCaptureLibs (wpcap.dll), InitiatingProcessFileName (powershell.exe or python3.exe) not in LegitNetworkTools allowlist, AlertType=PacketCaptureLibraryLoad. SPL EventCode=7, ImageLoaded=*\wpcap.dll, Image not in allowlist — alert triggers.

Test 4 Linux Raw Packet Socket Creation (Passive Listener Simulation)
linux

Creates a raw AF_PACKET socket on Linux to simulate the passive listener mechanism used by traffic signaling malware such as Turla Penquin, Umbreon, Chaos, and REPTILE. Raw AF_PACKET sockets capture all packets arriving on a network interface at the link layer without binding to a port, making the listener completely invisible to netstat and port scanners. Requires CAP_NET_RAW capability or root.

Command

bash 
sudo python3 -c "
import socket
import sys
try:
    s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(0x0800))
    print('Raw AF_PACKET socket created (ETH_P_IP=0x0800) - passive listener simulation active')
    print('Socket fd:', s.fileno())
    import time; time.sleep(2)
    s.close()
    print('Socket closed - simulation complete')
except PermissionError:
    print('Error: CAP_NET_RAW required. Re-run with sudo.')
    sys.exit(1)
"

Expected Telemetry

Linux auditd with rule 'auditctl -a always,exit -F arch=b64 -S socket -F a0=17 -k raw_socket_creation' will generate AUDIT_SYSCALL record: syscall=socket, a0=17 (AF_PACKET), a1=3 (SOCK_RAW), process=python3. During the 2-second sleep, /proc/<PID>/net/packet will show the active raw socket. Sysmon for Linux (if deployed) will generate a NetworkConnect event for raw socket creation.

Expected Detection

Auditd alert on AUDIT_SYSCALL for socket() with a0=17 (AF_PACKET) from a non-network-tool process. Splunk with linux_auditd sourcetype: type=SYSCALL, syscall=socket, a0=17, comm=python3. SIEM correlation rule: raw AF_PACKET socket creation from process not in approved network tool list triggers high-severity alert.

Related Detections

Tactic Hubs

TA0005Defense EvasionTA0003PersistenceTA0011Command and Control

Sub-techniques (2)

Related Techniques

T1205.001Port KnockingT1205.002Socket FiltersT1601.001Patch System ImageT1556.004Network Device AuthenticationT1571Non-Standard PortT1095Non-Application Layer ProtocolT1008Fallback ChannelsT1055Process InjectionT1546Event Triggered Execution

Same Tactic: Defense Evasion

Popular Detections