AN0843: Analytic 0843
A source performs a short closed-port sequence; the host then modifies iptables/nftables/ufw rules or starts a daemon binding a new socket, followed by a successful connection from the same source.
Analyst context for executives and security teams
This analytic describes a Linux pattern where a source sends a short sequence of connection attempts to closed ports, after which the host changes firewall rules or starts a service listening on a new socket, and the same source then connects successfully. For leaders, the practical concern is not the port sequence itself; it is whether a Linux system can silently open access after a trigger and whether the SOC can prove that firewall or daemon changes were expected.
Executive priority
Treat this as a validation point for Linux network access governance and incident response readiness. Security leaders should ask whether firewall rule changes, new listening services, and unusual connection sequences are logged centrally, reviewed, and tied to approved change activity. This matters for business continuity because unexpected exposure of a Linux service can create an unplanned remote access path that may bypass normal access-control assumptions.
Technical view
SOC and detection teams should correlate three evidence classes on Linux hosts: a short sequence of failed or closed-port connection attempts from one source, a local change to iptables/nftables/ufw rules or a daemon binding a new socket, and a later successful connection from the same source. Because ATT&CK does not provide official detection logic for AN0843, teams should validate local data quality, time-window selection, and whether host and network timestamps can support this sequence reliably.
Likely telemetry
- Linux firewall rule change evidence for iptables, nftables, or ufw
- Host logs showing daemon or service start activity
- Network telemetry showing connection attempts to closed ports
- Network telemetry showing subsequent successful connection from the same source
- Socket/listening-port inventory or process-to-port binding data
Detection direction
- Build correlation around sequence and timing, not a single event: closed-port attempts, host-side rule or socket change, then successful connection from the same source.
- Tune out approved administrative change windows and known automation that legitimately modifies Linux firewall rules or starts services.
- Validate visibility on both host and network sides; a network sensor alone may miss the local firewall or daemon change, while host logs alone may miss the closed-port sequence.
- Confirm that NAT, proxies, or load balancers do not obscure the source identity needed to link the initial sequence and later successful connection.
- Prioritize alerts where the new listening socket or firewall change is not tied to an approved deployment, maintenance action, or documented service owner.
Mitigation priorities
- Maintain change control for Linux firewall rules and service start behavior, with enough evidence to distinguish approved changes from unexpected exposure.
- Restrict administrative permissions that can modify iptables, nftables, ufw, or service configuration.
- Centralize Linux host logs and network connection records so incident responders can reconstruct the sequence described by the analytic.
- Continuously inventory expected listening services and alert on new or unauthorized sockets.
- Review segmentation and access-control assumptions for Linux systems that should not dynamically expose new services.
Analyst notes and limits
AN0843 is a detection analytic rather than a technique object. The supplied ATT&CK fields specify Linux as the platform and describe a correlation pattern, but provide no tactics, technique relationships, official detection logic, or mitigation text. Use this as a hypothesis for coverage validation and incident triage, not as proof of malicious activity by itself.
This take is limited to the supplied ATT&CK object, external reference, and absence of relationship context. It does not establish prevalence, attribution, active exploitation, affected products, or guaranteed detection coverage. Local architecture, logging configuration, approved change processes, and source-address preservation are required to determine materiality.
Analytic 0843
A source performs a short closed-port sequence; the host then modifies iptables/nftables/ufw rules or starts a daemon binding a new socket, followed by a successful connection from the same source.
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 | 87fcc2f7cab1… |
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 AN0843Open 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.