AN0596: Analytic 0596
Adversary uses a process to establish outbound connections that transmit uniform packet sizes at a consistent interval, avoiding threshold-based network alerts.
Analyst context for executives and security teams
This analytic describes a Windows process making outbound network connections with uniform packet sizes at consistent intervals, a pattern that can be used to avoid simple threshold-based network alerts. For leaders, the practical issue is whether the organization can detect low-and-slow, regular outbound traffic patterns rather than only high-volume or obvious network spikes.
Executive priority
Prioritize this as a validation point for SOC and incident response readiness where Windows endpoints are important to business operations. It helps test whether monitoring can support decisions during a suspected compromise when traffic is intentionally quiet, periodic, and designed to blend under basic alert thresholds. The main business value is confirming that network and endpoint telemetry are sufficient for investigation, not assuming perimeter volume alerts are enough.
Technical view
SOC and detection teams should validate whether they can correlate Windows process activity with outbound connection behavior, packet-size consistency, and regular timing intervals. Because no official detection logic is provided, teams should treat this as a detection engineering requirement rather than a ready-made rule. Useful analysis should focus on process-to-network relationships, periodicity, destination patterns, and deviations from the normal behavior of approved Windows applications.
Likely telemetry
- Windows endpoint process execution metadata
- Process-to-network connection telemetry
- Network flow records with byte and packet counts
- Packet size or session metadata where available
- Timestamps sufficient to analyze consistent connection intervals
Detection direction
- Validate that outbound network monitoring is not limited to volume or threshold spikes.
- Look for Windows processes that make repeated outbound connections at highly regular intervals with similar packet sizes.
- Tune against known business software that legitimately performs heartbeat, polling, synchronization, monitoring, or update checks.
- Correlate network patterns with process identity and host context to reduce false positives.
- Assess blind spots where encrypted traffic, NAT, proxy aggregation, or incomplete endpoint telemetry prevents process-level attribution.
Mitigation priorities
- Ensure endpoint and network telemetry can link Windows processes to outbound connections.
- Baseline approved periodic outbound communications from business, monitoring, backup, update, and security tools.
- Review egress control and logging coverage so unusual destinations or unauthorized processes are investigated.
- Use incident response procedures that include low-volume periodic traffic analysis, not only high-volume exfiltration or scanning indicators.
- Maintain audit evidence showing what telemetry is collected, retained, and reviewed for this behavior.
Analyst notes and limits
This is a detection analytic, not a technique or software entry. The supplied ATT&CK object identifies Windows as the platform and describes a behavioral network pattern, but it does not provide tactics, detection pseudocode, mitigations, procedures, or relationships. Local baselining is essential because many legitimate services use periodic outbound communications.
The source fields do not support claims about active exploitation, adversary attribution, impact, prevalence, or guaranteed detection. No relationship context or official detection logic was supplied, so implementation detail must come from local telemetry, environment baselines, and defensive engineering decisions.
Analytic 0596
Adversary uses a process to establish outbound connections that transmit uniform packet sizes at a consistent interval, avoiding threshold-based network alerts.
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 | 22fed222c825… |
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 AN0596Open 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.