AN0597: Analytic 0597
Outbound connections from non-network-facing processes repeatedly send similarly sized payloads within uniform time intervals.
Analyst context for executives and security teams
This analytic is about spotting Linux processes that do not normally provide network services but are making repeated outbound connections with highly regular timing and similar payload sizes. For leaders, the value is not in treating this as a standalone proof of compromise, but in using it to validate whether network and endpoint monitoring can identify suspicious beacon-like behavior from unexpected processes before an incident becomes harder to contain.
Executive priority
Prioritize this as a coverage and resilience question: do security teams have enough Linux endpoint and network visibility to distinguish normal scheduled activity from unusual repeated outbound traffic by non-network-facing processes? This matters for incident triage, managed detection quality, and audit evidence around monitoring controls, especially in Linux server environments where outbound traffic may be less tightly governed than inbound exposure.
Technical view
For SOC, detection engineering, and IR teams, validate whether Linux process context can be correlated with outbound connection patterns, payload-size similarity, and uniform timing intervals. Because no ATT&CK tactic or official detection logic is supplied, treat AN0597 as a behavioral analytic concept rather than a complete rule. Focus testing on whether telemetry can identify the initiating process, classify whether it is expected to be network-facing, and compare connection cadence and payload sizes over time.
Likely telemetry
- Linux process execution and process metadata
- Outbound network connection records with source process context where available
- Network flow metadata including destination, timing, byte counts, and packet or payload-size indicators
- Host-based network telemetry from Linux endpoints or servers
- Asset or service inventory identifying which processes are expected to be network-facing
Detection direction
- Validate that outbound connections can be tied back to Linux processes, not only hosts or IP addresses.
- Baseline expected network-facing processes per Linux server role to reduce false positives from legitimate agents, schedulers, updaters, monitoring tools, or backup software.
- Look for repeated outbound activity with consistent intervals and similarly sized transfers, then enrich with process identity, parent process, destination, and asset role.
- Tune carefully for periodic legitimate traffic; uniform timing alone should not be treated as conclusive.
- Document blind spots where network telemetry lacks process attribution or where encrypted traffic limits payload-size interpretation.
Mitigation priorities
- Maintain an accurate inventory of Linux services and processes that are expected to initiate outbound network connections.
- Restrict unnecessary outbound access where business operations allow, especially from systems or processes that should not communicate externally.
- Improve endpoint and network logging so responders can correlate process identity with outbound connection behavior.
- Use monitoring coverage tests to confirm that repeated, uniform outbound activity from unexpected Linux processes would generate reviewable evidence.
- Feed findings into incident response playbooks so analysts know how to validate process legitimacy before escalation.
Analyst notes and limits
AN0597 is a detection analytic object, not a technique description. The supplied description supports a behavioral focus on repeated outbound Linux network activity from non-network-facing processes. No relationship context, tactic mapping, procedure examples, or official detection implementation was provided, so local baselining and telemetry validation are essential.
This take is limited to the official STIX fields and the single external MITRE reference supplied. It does not establish adversary attribution, active exploitation, impact, or guaranteed detection. The object names Linux as the platform, but does not specify tactics, related techniques, data sources, or a complete detection query.
Analytic 0597
Outbound connections from non-network-facing processes repeatedly send similarly sized payloads within uniform time intervals.
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 | 98a13b788607… |
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 AN0597Open 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.