AN1449: Analytic 1449
Closed-port knock sequence from a remote IP followed by on-host firewall change (iptables/nftables) or daemon starts listening (socket open) and a successful TCP/UDP connect. Optional detection of libpcap/raw-socket sniffers spawning to watch for secret values.
Analyst context for executives and security teams
This analytic is about detecting a Linux host that appears to open access only after a closed-port “knock” sequence from a remote IP. For leaders, the decision value is that port knocking can hide remote access paths from routine scanning and change the incident picture: a system may look closed until a specific sequence causes a firewall change, daemon listener, or successful connection.
Executive priority
Prioritize this where Linux systems protect sensitive services, administrative access, or internet-facing workloads. The business question is whether SOC and incident response teams can prove when a host’s exposure changed, who connected afterward, and whether firewall/listener changes are authorized. This supports resilience, audit evidence, and incident scoping because hidden or conditional access paths can undermine assumptions made from static vulnerability scans or perimeter reviews.
Technical view
Validate visibility for the full sequence described by the ATT&CK analytic: closed-port connection attempts from a remote IP, followed by on-host firewall changes involving iptables or nftables, or a daemon beginning to listen on a socket, followed by a successful TCP or UDP connection. On Linux, IR and detection teams should correlate network events with host process, socket, and firewall-change telemetry. The object also notes optional detection of libpcap or raw-socket sniffers spawning to watch for secret values, so process creation and packet-capture activity are relevant where collected.
Likely telemetry
- Linux host firewall change evidence for iptables and nftables
- Network connection attempts to closed ports from remote IPs
- Socket/listener state changes showing a daemon beginning to listen
- Successful TCP or UDP connection records after the prior sequence
- Linux process creation telemetry for firewall tools, daemons, and optional libpcap/raw-socket sniffing processes
Detection direction
- Build correlation around sequence and timing, not any single event: closed-port knocks, then firewall or listener change, then successful connection.
- Tune for authorized administrative firewall changes and legitimate service restarts to reduce false positives.
- Check blind spots where only perimeter logs exist but Linux host firewall, process, or socket telemetry is missing.
- Validate whether UDP visibility is adequate, since the analytic explicitly includes TCP/UDP connect outcomes.
- If process telemetry is available, review spawning of packet-capture or raw-socket sniffing components as supporting context, not as a standalone conclusion.
Mitigation priorities
- Establish approved change paths for Linux firewall and daemon listener modifications, with logging sufficient for incident reconstruction.
- Restrict who and what can modify iptables or nftables rules on managed Linux systems.
- Maintain host and network telemetry retention long enough to correlate pre-change knocks with post-change access.
- Include conditional or hidden access mechanisms in Linux hardening reviews and incident response playbooks.
- Use this analytic as a validation target for managed detection or SOC coverage where Linux remote access exposure is material.
Analyst notes and limits
No ATT&CK tactic, technique relationship, or official detection logic was supplied beyond the analytic description. Treat this as a detection-engineering requirement and validation scenario rather than a complete rule. Local baselining is important because firewall updates, daemon restarts, and packet-capture tools can be legitimate in administrative or troubleshooting workflows.
The supplied object is limited to a Linux detection analytic with no relationships, no official detection section, and no attribution or exploitation context. It does not support claims about specific adversaries, active use, impact, or guaranteed detection coverage.
Analytic 1449
Closed-port knock sequence from a remote IP followed by on-host firewall change (iptables/nftables) or daemon starts listening (socket open) and a successful TCP/UDP connect. Optional detection of libpcap/raw-socket sniffers spawning to watch for secret values.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | c33fb7a18943… |
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 AN1449Open 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.