AN0030: Analytic 0030
Processes generating large outbound connections with disproportionate send/receive ratios, often to uncommon ports or hosts, potentially inserting meaningless data into protocol payloads.
Analyst context for executives and security teams
AN0030 is a Windows-focused detection analytic for processes that send unusually large amounts of outbound data compared with what they receive, especially when communicating with uncommon ports or hosts. For security leaders, its value is in testing whether the organization can spot suspicious outbound data movement patterns before they become an incident decision point.
Executive priority
Prioritize this analytic as a validation of outbound visibility and response readiness. It can help inform business-risk questions such as: do we know which Windows systems are sending large volumes externally, can the SOC distinguish expected business transfers from unusual process-level activity, and is there enough evidence to support incident response or audit review when outbound data movement is questioned?
Technical view
SOC and detection engineering teams should validate whether Windows process-level network activity can be correlated with outbound byte counts, destination host rarity, destination port rarity, and send/receive ratios. Because no ATT&CK tactic, technique relationship, or official detection logic is supplied, this should be treated as a behavioral analytic candidate rather than a complete rule. Tuning should account for legitimate high-volume senders such as backup, file transfer, update, telemetry, or business application processes.
Likely telemetry
- Windows process execution and process identity metadata
- Network connection telemetry with source process where available
- Outbound byte counts and inbound byte counts per process/connection
- Destination IP, hostname, domain, and port information
- Historical baselines for common destinations, hosts, ports, and process communication patterns
Detection direction
- Validate that telemetry can measure disproportionate outbound send/receive ratios at the process level, not only at the host or firewall level.
- Baseline common Windows processes, business applications, destinations, and ports before alerting on volume alone.
- Prioritize uncommon destination ports or hosts as enrichment signals, as stated in the analytic description.
- Review false positives from sanctioned large uploads, synchronization tools, backup agents, software distribution, and managed services.
- Because no relationship context is supplied, avoid mapping alerts to a specific tactic or intrusion stage without local investigation evidence.
Mitigation priorities
- Ensure egress monitoring and logging are enabled where Windows endpoints communicate externally.
- Maintain allowlists or expected-use baselines for approved high-volume outbound services and destinations.
- Use network segmentation and outbound access governance to reduce unnecessary external communication paths.
- Confirm incident response procedures can quickly identify the originating process, user context, destination, and business owner for unusual outbound transfers.
- Use findings from this analytic to improve data handling, outbound control, and compliance evidence where large external transfers are material.
Analyst notes and limits
This object is a detection analytic, not a full ATT&CK technique. The supplied description supports a focus on anomalous outbound process communications on Windows, especially high send/receive ratios and uncommon ports or hosts. There are no supplied relationships, aliases, labels, or official detection logic, so local baselining and enrichment are essential.
The ATT&CK object provides a short description only and no official detection procedure, tactic mapping, related techniques, or relationship context. Conclusions about malicious intent, data loss, attribution, or confirmed detection coverage require environment-specific telemetry and investigation.
Analytic 0030
Processes generating large outbound connections with disproportionate send/receive ratios, often to uncommon ports or hosts, potentially inserting meaningless data into protocol payloads.
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 | 004fec8cddb5… |
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 AN0030Open 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.