AN0031: Analytic 0031
Outbound traffic with anomalous payload sizes and patterns from non-networking processes, often observed via packet inspection or connection logs.
Analyst context for executives and security teams
Analytic 0031 is a Linux-focused detection analytic for spotting outbound network traffic with unusual payload sizes or traffic patterns coming from processes that are not normally responsible for networking. Its practical value is in finding activity that may hide in allowed outbound connections, where process context and traffic shape are often more important than destination reputation alone.
Executive priority
This matters because outbound traffic from unexpected Linux processes can indicate gaps in egress visibility, workload baselining, and incident triage readiness. Leaders should ask whether Linux servers and workloads have enough packet, connection, and process telemetry to explain unusual outbound behavior, and whether SOC teams can distinguish legitimate application behavior from suspicious non-networking process activity during an incident.
Technical view
For SOC and detection teams, the validation focus is Linux telemetry that links outbound connections to the originating process and characterizes payload size or traffic pattern anomalies. Because the ATT&CK object provides no tactic, technique relationships, or official detection logic, teams should treat this as a behavior-oriented analytic requiring local baselines for normal process-to-network behavior. Detection quality will depend on correlating packet inspection or connection logs with host process metadata and tuning for expected application, backup, monitoring, or administrative activity.
Likely telemetry
- Linux process execution and process metadata
- Outbound network connection logs with source host, destination, port, and timing
- Packet inspection or flow telemetry that can represent payload sizes and traffic patterns
- Process-to-socket or endpoint network telemetry linking connections to process names or identifiers
- Asset and workload context to identify which processes are expected to initiate network traffic
Detection direction
- Validate that outbound Linux connections can be attributed to the originating process, not just the host.
- Baseline normal payload sizes and communication patterns for server roles and workloads before treating anomalies as high-confidence events.
- Prioritize alerts where non-networking processes generate unusual outbound traffic patterns or payload sizes.
- Tune expected activity from legitimate services, monitoring agents, package managers, backup tools, and administrative scripts to reduce false positives.
- Document blind spots where packet inspection, connection logging, or process-to-network correlation is unavailable.
Mitigation priorities
- Improve Linux egress visibility first: collect connection logs, process context, and where appropriate packet or flow-derived payload pattern data.
- Define expected network behavior for critical Linux workloads and flag deviations from non-networking processes.
- Use least-privilege and workload hardening practices to reduce the number of processes that can initiate unnecessary outbound communications.
- Apply network egress controls and segmentation where business requirements allow, using detection findings to prioritize policy refinement.
- Preserve relevant telemetry for incident response so analysts can reconstruct process, host, and outbound traffic context.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and has no relationship context. The description supports Linux-only analysis of anomalous outbound payload sizes and patterns from non-networking processes, observed through packet inspection or connection logs. Local environment baselines are essential because the object does not provide thresholds, query logic, or known-good process lists.
Official detection content is not provided, tactics are not specified, and no related ATT&CK techniques, software, groups, or mitigations were supplied. This take should therefore be used as defensive validation guidance rather than as a claim of complete detection coverage or specific adversary behavior.
Analytic 0031
Outbound traffic with anomalous payload sizes and patterns from non-networking processes, often observed via packet inspection or connection logs.
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 | d31cd94166ba… |
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 AN0031Open 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.