T1205.001: Port Knocking
Adversaries may use port knocking to hide open ports used for persistence or command and control. To enable a port, an adversary sends a series of attempted connections to a predefined sequence of closed ports. After the sequence is completed, opening a port is often accomplished by the host based firewall, but could also be implemented by custom software.
This technique has been observed both for the dynamic opening of a listening port as well as the initiating of a connection to a listening server on a different system.
The observation of the signal packets to trigger the communication can be conducted through different methods. One means, originally implemented by Cd00r [1], is to use the libpcap libraries to sniff for the packets in question. Another method leverages raw sockets, which enables the malware to use ports that are already open for use by other programs.
Analyst context for executives and security teams
Port knocking matters because it can make persistence or command-and-control access look closed until a specific network signal is sent. For leaders, the risk is not simply an unusual firewall trick; it is that an environment may appear clean in routine port scans while hidden access paths remain available on Linux, macOS, Windows, or network devices.
Executive priority
Prioritize this where exposed systems, network devices, or high-value servers depend on firewall state and network monitoring for assurance. Ask whether teams can prove that firewall rule changes, daemon or service changes, and the first successful connection after unusual failed connection sequences are visible and retained. This technique is especially relevant to incident response readiness because absence of an always-open port is not enough evidence that remote access is absent.
Technical view
ATT&CK describes Port Knocking as a sub-technique of Traffic Signaling used for stealth, persistence, and command-and-control across Linux, macOS, Network Devices, and Windows. The supplied detection relationship, DET0302, points defenders toward correlating a port-knock pattern with a rule or daemon change and then the first successful connection. SOC and IR teams should validate visibility across packet or flow records, host firewall events, service/daemon changes, and subsequent inbound or outbound sessions. Because ATT&CK provides no official detection text for this object, local baselining and correlation design are required.
Likely telemetry
- Network flow records or packet metadata showing repeated attempted connections to closed or unusual ports
- Firewall, host firewall, or network device logs showing dynamic rule changes or allowed connection changes
- Endpoint logs showing service, daemon, or custom software changes around the time of network signaling
- Successful connection records immediately following a sequence of failed or denied connection attempts
- Packet capture or network sensor evidence where available, especially for high-value or exposed systems
Detection direction
- Validate the DET0302-style correlation: port-knock sequence, then rule or daemon change, then first successful connection.
- Tune for sequences of denied or failed connections that are followed by a new allowed connection, rather than treating failed connections alone as sufficient.
- Review blind spots where closed-port attempts are not logged, network device logs are not centralized, or host firewall changes are not collected.
- Account for legitimate administrative port-knocking or dynamic access-control mechanisms if used internally, and document approved sources, destinations, and sequences.
- During IR, do not rely only on point-in-time port scans; review historical network and firewall state changes.
Mitigation priorities
- Apply M1037 Filter Network Traffic: restrict ingress, egress, and lateral traffic with explicit firewall and endpoint filtering rules.
- Limit public-facing access to authorized sources where operationally feasible, especially for management services and high-value systems.
- Centralize and retain firewall, network device, and endpoint firewall logs so dynamic rule changes can be investigated.
- Harden change control for firewall rules, services, daemons, and network-access mechanisms.
- Where legitimate dynamic access is required, require documented ownership, monitoring, and periodic review.
Analyst notes and limits
ATT&CK relationships map this technique to PROMETHIUM, UNC3886, and software including metaMain, Mafalda, cd00r, and REPTILE. Use those relationships for threat-informed hunting context, not as proof that any local event is attributable to a specific group or tool. The cd00r reference is useful because it illustrates packet-sniffing based signaling, while the ATT&CK description also notes raw socket approaches.
The official ATT&CK object does not provide detection guidance, data sources, procedures, or mitigations beyond the supplied relationship to M1037 and DET0302. This take therefore focuses on conservative validation themes. Actual coverage depends on local logging of denied traffic, firewall changes, endpoint events, and network session history.
Port Knocking
Adversaries may use port knocking to hide open ports used for persistence or command and control. To enable a port, an adversary sends a series of attempted connections to a predefined sequence of closed ports. After the sequence is completed, opening a port is often accomplished by the host based firewall, but could also be implemented by custom software.
This technique has been observed both for the dynamic opening of a listening port as well as the initiating of a connection to a listening server on a different system.
The observation of the signal packets to trigger the communication can be conducted through different methods. One means, originally implemented by Cd00r [1], is to use the libpcap libraries to sniff for the packets in question. Another method leverages raw sockets, which enables the malware to use ports that are already open for use by other programs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1205 | Traffic Signaling | This object subtechnique of Traffic Signaling. |
Groups, software, and campaigns
G0056: PROMETHIUM
PROMETHIUM is an activity group focused on espionage that has been active since at least 2012. The group has conducted operations globally with a heavy emphasis on Turkish targets. PROMETHIUM has demonstrated similarity to another activity group called NEODYMIUM due to overlapping victim and campaign characteristics.[1][2][3]
G1048: UNC3886
UNC3886 is a China-nexus cyberespionage group that has been active since at least 2022, targeting defense, technology, and telecommunication organizations located in the United States and the Asia-Pacific-Japan (APJ) regions. UNC3886 has displayed a deep understanding of edge devices and virtualization technologies through the exploitation of zero-day vulnerabilities and the use of novel malware families and utilities.[1][2]
S1060: Mafalda
S1219: REPTILE
S1204: cd00r
cd00r is an open-source backdoor for UNIX and UNIX-variant operating systems that was orginally released in 2000. cd00r source code is primarily based on a packet-capturing program as it utilizes a sniffer to listen for specific sequences of network traffic or "secret knock" before executing the attacker's code.[1][2]
S1059: metaMain
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | aaa0b77b0d8c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Hartrell cd00r 2002
Hartrell, Greg. (2002, August). Get a handle on cd00r: The invisible backdoor. Retrieved October 13, 2018.
Open source URL -
[2]
mitre-attack T1205.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.