T1205.001 Microsoft Sentinel · KQL

Detect Port Knocking in Microsoft Sentinel

Adversaries may use port knocking to conceal open ports used for persistence or command and control. A predefined sequence of connection attempts to closed ports causes the host-based firewall (or custom software) to dynamically open a listening port. Implementations include libpcap-based packet sniffing (cd00r, REPTILE), raw socket listeners, and dedicated daemons such as knockd or fwknopd. Real-world usage includes PROMETHIUM configuring knockd for C2 access, UNC3886 using ICMP-based knocking on FortiGate firewalls, the Mafalda/metaMain implant pair using knocking for inter-implant authentication, and REPTILE malware accepting knock sequences to activate backdoor access.

MITRE ATT&CK

Tactic
Defense Evasion Persistence Command and Control
Technique
T1205 Traffic Signaling
Sub-technique
T1205.001 Port Knocking
Canonical reference
https://attack.mitre.org/techniques/T1205/001/

KQL Detection Query

Microsoft Sentinel (KQL)
kusto
// T1205.001 — Port Knocking Detection
// Three detection branches: Linux knockd daemon activity, network knock sequences via firewall logs, and knock client tool execution

// Branch 1: Linux endpoints — knockd/fwknopd daemon syslog messages indicating knock sequences
let KnockdActivity =
Syslog
| where TimeGenerated > ago(24h)
| where ProcessName in ("knockd", "fwknopd")
    or SyslogMessage has_any ("knockd", "fwknop", "knock sequence", "OPEN SESAME", "Opening port", "Stage 1", "correct knock")
| extend DetectionBranch = case(
    SyslogMessage has_any ("Opening port", "OPEN SESAME", "correct knock", "sequence complete"), "KnockSequenceTriggered",
    SyslogMessage has_any ("Stage 1", "Stage 2", "Stage 3"), "KnockSequenceInProgress",
    ProcessName in ("knockd", "fwknopd"), "KnockDaemonRunning",
    "KnockdGeneralActivity"
  )
| project TimeGenerated, Computer, HostName, ProcessName, SyslogMessage, DetectionBranch;

// Branch 2: Network/firewall devices — rapid sequential denied connections to distinct ports
// from same source IP within a tight time window (knock pattern vs port scan differentiation)
let NetworkKnockSequence =
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceAction in~ ("Deny", "Drop", "Block", "Reject", "DENY", "DROP")
| where isnotempty(SourceIP) and isnotempty(DestinationPort)
| summarize
    DistinctPortsHit = dcount(DestinationPort),
    PortSequence = make_set(DestinationPort, 10),
    TotalPackets = count(),
    WindowStart = min(TimeGenerated),
    WindowEnd = max(TimeGenerated)
    by SourceIP, DeviceName, DeviceProduct, bin(TimeGenerated, 1m)
| where DistinctPortsHit between (3 .. 8)   // knock sequences are 3-8 ports — not a full port scan
    and TotalPackets between (3 .. 12)       // low packet count distinguishes knocking from scanning
| extend KnockDurationSec = datetime_diff('second', WindowEnd, WindowStart)
| where KnockDurationSec between (1 .. 30) // tight timing window characteristic of automated knock sequences
| extend DetectionBranch = "RapidSequentialPortsDenied"
| project TimeGenerated = WindowStart, SourceIP, DeviceName, DeviceProduct,
         DistinctPortsHit, PortSequence, TotalPackets, KnockDurationSec, DetectionBranch;

// Branch 3: Endpoint — execution of known port-knocking client tools
let KnockClientTool =
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("knock", "knock.exe", "fwknop", "fwknop.exe")
    or (FileName in~ ("hping3", "hping3.exe", "nping") and ProcessCommandLine has_any ("--syn", "-S", "--tcp"))
    or ProcessCommandLine has_any ("--knock-port", "-knock", "/etc/knockd.conf", "knockd.conf")
| extend DetectionBranch = "KnockClientToolExecution"
| project TimeGenerated = Timestamp, Computer = DeviceName, AccountName, FileName,
         ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionBranch;

union kind=outer KnockdActivity, NetworkKnockSequence, KnockClientTool
| sort by TimeGenerated desc
high severity medium confidence

Three-branch detection for T1205.001 Port Knocking. Branch 1 monitors Linux Syslog for knockd/fwknopd daemon messages indicating knock sequences in progress or port-open actions — the highest-fidelity signal when a knock daemon is present. Branch 2 analyzes CommonSecurityLog (CEF/firewall logs) for rapid sequential denied connection attempts to 3–8 distinct ports within 30 seconds from the same source IP, differentiating knock sequences from port scans by the tight timing and low packet count. Branch 3 detects execution of known knock client utilities (knock, fwknop, hping3 with SYN flags) on endpoints via DeviceProcessEvents.

Data Sources

Network Traffic: Network Traffic FlowNetwork Traffic: Network Connection CreationProcess: Process CreationFirewall: Firewall Rule ModificationLinux Syslog

Required Tables

SyslogCommonSecurityLogDeviceProcessEvents

False Positives & Tuning

  • Legitimate administrators using knockd or fwknopd to protect SSH access on servers — extremely common on hardened Linux hosts exposed to the internet
  • Security scanners and vulnerability assessment tools (Nessus, Qualys, Rapid7) that probe multiple ports in sequence during authorized scans
  • Network monitoring and probing tools that check port availability across a range, which may resemble a knock sequence in firewall deny logs
  • Developers or sysadmins manually testing firewall rules by attempting connections to multiple ports in succession
  • Load balancer health checks or service mesh probes that contact multiple backend ports in a brief window
Download portable Sigma rule (.yml)

Other platforms for T1205.001


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 1Install and Configure knockd Daemon on Linux

    Expected signal: Syslog entries from knockd daemon: '<timestamp> <host> knockd: Starting...' and 'knockd: listening on lo'. Package manager log entries in /var/log/dpkg.log or /var/log/yum.log for knockd installation. Auditd execve events for apt-get/yum and knockd process creation. File creation event for /tmp/knockd-test.conf. If using MDE Linux agent: DeviceProcessEvents with FileName=knockd.

  2. Test 2Send Port Knock Sequence Using knock Client

    Expected signal: DeviceProcessEvents (MDE Linux agent): FileName=knock, ProcessCommandLine='knock 127.0.0.1 7000 8000 9000 -v'. Sysmon for Linux Event ID 3 (if deployed): three outbound network connections to 127.0.0.1 on ports 7000, 8000, 9000. Network flow logs will show three SYN packets with no SYN-ACK response (ports are closed), followed optionally by a successful connection to port 4444 if knockd is configured.

  3. Test 3Simulate Port Knock Using hping3 Crafted SYN Packets

    Expected signal: DeviceProcessEvents: four invocations of hping3 with -S flag and different -p port values. Each hping3 execution creates a raw socket (AF_PACKET or SOCK_RAW) visible in auditd socket syscall events. Network flow: four SYN packets to 127.0.0.1 on ports 200, 80, 22, 53 in rapid succession — matches the exact cd00r default knock sequence documented in the MITRE reference.

  4. Test 4Simulate Port Knock Sequence from Windows Using PowerShell TCP Connections

    Expected signal: Sysmon Event ID 3 (Network Connection): three network connection events from powershell.exe to 127.0.0.1 on ports 7000, 8000, 9000 within 500ms. DeviceNetworkEvents in MDE: three ConnectionFailed events from PowerShell to localhost. DeviceProcessEvents: powershell.exe with CommandLine containing 'TcpClient' and the port numbers. Windows Filtering Platform (WFP) audit log may capture the refused connection attempts.

Unlock Pro Content

Get the full detection package for T1205.001 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections