DET0213: Detection Strategy for Data Transfer Size Limits and Chunked Exfiltration
This detection strategy matters because it points to a common exfiltration problem: data theft may be broken into smaller transfers to avoid simple volume-...
Analyst context for executives and security teams
This detection strategy matters because it points to a common exfiltration problem: data theft may be broken into smaller transfers to avoid simple volume-threshold alerts. For leaders, the decision value is whether the organization can spot suspicious transfer patterns over time, not just single large uploads.
Executive priority
Prioritize this as an exfiltration monitoring and resilience question. Ask whether SOC, IR, and compliance teams can prove they monitor for repeated or chunked outbound data movement across relevant environments tied to T1030, including Linux, macOS, Windows, and ESXi where applicable. This is especially important for incident decision-making because small transfers may look benign unless correlated by source, destination, timing, user, host, and cumulative volume.
Technical view
The supplied detection strategy object has no official description, detection text, tactics, or platforms of its own. Its relationship says it detects T1030 Data Transfer Size Limits, an enterprise exfiltration technique where adversaries may exfiltrate data in fixed-size chunks or keep packet sizes below alert thresholds. SOC and detection teams should validate analytics that aggregate outbound transfer behavior over time rather than relying only on single-event size thresholds.
Likely telemetry
- Network flow records showing source, destination, protocol, byte counts, and timing
- Proxy, web gateway, firewall, VPN, and egress filtering logs where available
- Endpoint network connection telemetry for Linux, macOS, Windows, and ESXi environments where applicable
- DNS and destination reputation/context logs to help group repeated outbound activity
- Data loss prevention or file transfer monitoring events if deployed
Detection direction
- Test whether current alerts detect cumulative outbound volume made up of many smaller transfers, not only one large transfer.
- Correlate repeated transfers by host, user, destination, protocol, time window, and cumulative bytes.
- Tune thresholds by business role and known transfer patterns to reduce false positives from backups, software updates, replication, media workflows, and legitimate bulk data movement.
- Look for destinations, timing, or transfer regularity that are unusual for the user or system.
- Validate coverage separately for environments related to T1030: Linux, macOS, Windows, and ESXi where those platforms are in scope.
Mitigation priorities
- Establish baseline outbound transfer behavior for critical users, servers, and data stores.
- Ensure egress logging captures enough metadata and retention to support time-window correlation.
- Review alert logic that depends only on single-transfer or packet-size thresholds.
- Apply least-privilege access and data handling controls so unusual transfers are easier to investigate.
- Use network segmentation and controlled egress paths to improve monitoring consistency.
Analyst notes and limits
This take is based on DET0213 and its relationship to T1030 Data Transfer Size Limits. Because the ATT&CK detection strategy entry provides no official description or detection text, the practical guidance is derived conservatively from the related technique description and relationship context.
The object itself does not specify platforms, tactics, aliases, labels, official description, or official detection guidance. Platform and tactic references come only from the related T1030 technique. Local architecture, logging coverage, retention, and business transfer patterns are required to determine actual detection coverage.
Detection Strategy for Data Transfer Size Limits and Chunked Exfiltration
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1030 | Data Transfer Size Limits | This object detects Data Transfer Size Limits. |
All related ATT&CK context
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 | 2ce0ff09a33b… |
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 DET0213Open 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.