AN1377: Analytic 1377
Creation of outbound connections on alternate ports or using covert transport (e.g., ICMP, DNS) from non-network-intensive processes, following known disruption or blocked traffic.
Analyst context for executives and security teams
This analytic is about spotting Linux systems that appear to shift outbound communications to unusual ports or covert transports such as ICMP or DNS after normal traffic has been disrupted or blocked. For leaders, the practical value is resilience: if an attacker or unauthorized tool can keep communicating after controls interrupt expected traffic, containment and incident response decisions may be weaker than they appear.
Executive priority
Prioritize this as a validation point for egress control, SOC visibility, and incident containment evidence on Linux assets. The key business question is whether the organization can prove that blocked traffic actually stays blocked, or whether systems can continue outbound communication through alternate ports or protocols that are less monitored. This matters for incident decision-making, audit defensibility around network controls, and operational resilience during containment actions.
Technical view
For SOC and detection teams, validate whether Linux telemetry can correlate three conditions: a prior disruption or blocked outbound connection, subsequent outbound connections on alternate ports or covert-style transports such as ICMP or DNS, and process context showing the source is a non-network-intensive process. Because ATT&CK provides no official detection logic and no relationship context for this analytic, local baselining is essential. Focus on process-to-network mapping, normal per-process communication profiles, and sequences where a process changes transport behavior after a block event.
Likely telemetry
- Linux process execution and process identity metadata
- Host network connection telemetry showing destination, port, protocol, and process association
- Firewall, proxy, or network control logs showing blocked or disrupted outbound traffic
- DNS query logs with originating host and, where available, process or endpoint correlation
- ICMP flow or packet metadata where collected
Detection direction
- Validate correlation between blocked/disrupted outbound traffic and later outbound activity by the same host or process over alternate ports or ICMP/DNS.
- Baseline Linux processes that normally generate network traffic so alerts can focus on non-network-intensive processes initiating unusual outbound communication.
- Tune for sequence and context rather than protocol alone; DNS and ICMP can be legitimate and may generate false positives without process and timing context.
- Check blind spots around host-to-network attribution, encrypted or summarized flow records, missing ICMP logging, and DNS logs that cannot be tied back to a host or process.
- Because no ATT&CK tactics or relationships are supplied, do not assume the intrusion stage; use this analytic as containment-evasion or abnormal-egress evidence requiring investigation.
Mitigation priorities
- Confirm egress filtering policies cover alternate ports and protocols, not only commonly abused destination ports.
- Ensure Linux endpoint telemetry can associate outbound connections with processes before relying on this analytic operationally.
- Review DNS and ICMP monitoring coverage, retention, and alert routing for incident response use.
- During containment exercises, test whether blocked traffic attempts are followed by alternate outbound communication and whether analysts can see that sequence.
- Document control evidence and detection limitations for audit, risk acceptance, and incident response playbooks.
Analyst notes and limits
This is a detection analytic object for Linux only. The official description is narrow and sequence-oriented: alternate-port or covert-transport outbound connections from non-network-intensive processes after known disruption or blocked traffic. There are no supplied relationships, aliases, labels, tactics, or official detection logic, so implementation should be driven by local telemetry and baselines.
The supplied ATT&CK fields do not provide detection logic, data source mappings, related techniques, threat actors, software, campaigns, or mitigations. Any assessment of coverage, severity, prevalence, or active exploitation requires local environment evidence and additional intelligence not included in this object.
Analytic 1377
Creation of outbound connections on alternate ports or using covert transport (e.g., ICMP, DNS) from non-network-intensive processes, following known disruption or blocked traffic.
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 | 1d980b4c9a77… |
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 AN1377Open 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.