DET0302: Port-knock → rule/daemon change → first successful connect (T1205.001)
This detection strategy is about catching the moment port knocking turns from hidden access into usable access: a knock sequence, followed by a firewall ru...
Analyst context for executives and security teams
This detection strategy is about catching the moment port knocking turns from hidden access into usable access: a knock sequence, followed by a firewall rule or daemon change, followed by the first successful connection. For leaders, the value is not simply identifying unusual network traffic; it is validating whether hidden persistence or command-and-control access could be enabled without normal service exposure.
Executive priority
Prioritize this where externally reachable systems, network devices, or high-value servers are part of business-critical operations. The decision question is whether the organization can prove that covert access-enablement paths are monitored across host firewalls, service changes, and network connections. This supports incident response readiness, resilience planning, and audit evidence for change control and monitoring around remote access paths.
Technical view
The related ATT&CK technique is T1205.001 Port Knocking, associated with stealth, persistence, and command-and-control across Linux, macOS, Network Devices, and Windows. SOC and detection engineering teams should validate whether they can correlate three evidence classes: attempted connections to closed or uncommon ports, host firewall or daemon/configuration changes that expose or enable a service, and the first successful inbound or outbound connection after that change. Because the official detection field is not provided, local implementation should be treated as a hypothesis to test rather than a guaranteed analytic.
Likely telemetry
- Network connection attempts, including denied or closed-port traffic where available
- Host firewall rule change logs
- Service or daemon configuration change logs
- Process execution or system management events related to firewall/service changes
- Successful connection logs following a rule or daemon change
Detection direction
- Validate correlation between a knock-like sequence and a subsequent access-enabling change, rather than alerting only on isolated port scans or firewall edits.
- Tune for administrative change windows and approved automation to reduce false positives from legitimate firewall or service management.
- Confirm visibility on denied connection attempts; many environments log successful flows but not the failed attempts needed to identify the knock sequence.
- Look for the first successful connection after a rule or daemon change, especially when the newly reachable service was not previously exposed.
- Apply the logic to supported related platforms only where telemetry exists: Linux, macOS, Windows, and network devices.
Mitigation priorities
- Ensure firewall, service, and daemon changes are centrally logged and tied to authorized change control.
- Restrict who can modify host firewall rules, network device rules, and service configurations.
- Monitor externally reachable and business-critical assets first, then expand coverage to internal systems where covert persistence would materially affect response.
- Retain enough network and host telemetry to reconstruct the sequence of denied attempts, configuration change, and successful connection during incident response.
- Review remote access exposure and remove unnecessary listening services or dynamic access mechanisms.
Analyst notes and limits
This take is based on the detection strategy name, external reference DET0302, and its relationship to ATT&CK technique T1205.001 Port Knocking. The strongest defensive value comes from sequence correlation across network and host/control-plane evidence, not from any single log source.
The supplied ATT&CK object has no official description, no official detection text, and no platforms or tactics directly on the detection-strategy object. Platform and tactic context comes only from the related T1205.001 technique. Local telemetry availability and approved administrative workflows must determine final detection design and severity.
Port-knock → rule/daemon change → first successful connect (T1205.001)
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.001 | Port Knocking Sub-technique | This object detects Port Knocking. |
All related ATT&CK context
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 | 1.0 | Current bundle | 56070f90d6e5… |
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]
mitre-attack DET0302Open 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.