Data Transfer Size Limits (T1030) is exfiltration designed to stay under your thresholds: stolen data is split into fixed-size chunks, or the transfer rate is capped, so no single file, packet or session looks big enough to alert on. ATT&CK v20 lists T1030 under Exfiltration (TA0010) for Windows, Linux, macOS and ESXi, with more than 20 procedure examples from ransomware groups, state actors and commodity tools. The technique attacks a specific design choice in many security stacks: volume-based rules that fire on a large upload. This page covers how chunking and throttling are used in real intrusions, the v20 detection strategy, aggregation rules that defeat chunking, and controls on the archivers and sync tools that do the splitting. It is written for detection engineers and network security teams. For the wider exfiltration picture, see the Data Exfiltration Guide; this page does not repeat it.
Key takeaways
- Per-transfer thresholds are what T1030 defeats. Count bytes per source, destination and identity over hours and days, not per file or per session.
- Chunk sizes range from bytes to megabytes. ATT&CK v20 records 23-byte DNS chunks (Helminth), 1,500-byte blocks (OopsIE), parts under 1 MB (APT28) and 3 MB archive parts (C0026), so no single size signature works.
- Uniformity is the v20 signal. Detection strategy DET0213 looks for outbound transfers of similar size at consistent intervals from processes that do not normally talk to the network.
- Splitting usually happens on disk first. Multi-part archives (.part1.rar, .001, .z01) created in bulk are an earlier, quieter signal than the network transfer.
- Legitimate tools do the chunking. Rclone's chunker overlay and bandwidth limits, WinRAR volumes and C2 framework settings are all recorded in ATT&CK; control who can run them and from where.
What T1030 is in ATT&CK v20
ATT&CK describes Data Transfer Size Limits as exfiltrating data in fixed-size chunks instead of whole files, or limiting packet sizes below certain thresholds, to avoid triggering network data transfer threshold alerts. Version 1.2 (last modified 16 September 2026) has no sub-techniques and one mitigation, Network Intrusion Prevention (M1031).
In practice there are three forms, often combined:
- File splitting: an archive is cut into volumes before transfer, for example LuminousMoth splitting archives into parts to bypass a 5 MB limit and Play splitting victims' files into chunks.
- Protocol-level chunking: the implant sends data in small fixed blocks, such as POSHSPY's 2,048-byte uploads or Kessel fitting chunks into DNS query subdomains.
- Rate limiting: the transfer is throttled so bandwidth stays low, as in campaign C0015 limiting Rclone's bandwidth and StealBit exfiltrating at a configured rate.
T1030 usually sits beside archiving (T1560), staging (T1074) and a channel technique such as Exfiltration Over Web Service (T1567) or Exfiltration Over Alternative Protocol (T1048). Each has its own page: see T1560 and T1074 Archive and Stage Collected Data Defensive Guide and T1567 Exfiltration Over Web Service.
How adversaries use it: recorded cases
| Group, campaign or software | Recorded in ATT&CK v20 or source | Form |
|---|---|---|
| Play (G1040) | CISA's December 2023 advisory states the actors often split compromised data into segments and use tools like WinRAR to compress files, then use WinSCP to transfer data to actor-controlled accounts | File splitting |
| APT28 (G0007) | Split archived exfiltration files into chunks smaller than 1 MB (2021 joint advisory on a GRU brute force campaign) | File splitting |
| C0026 (suspected Turla) | Split encrypted archives of stolen files into 3 MB parts before exfiltration | File splitting |
| LunarWeb (S1141) | Splits data over 1.33 MB into random-sized parts between 384 and 512 KB | Variable chunk size |
| APT41 (G0096) | Divides post-exploitation file transfers into fixed-size chunks to evade detection | Fixed chunks |
| Helminth (S0170) and Kessel (S0487) | Split data into small chunks carried in DNS queries (Helminth up to 23 bytes) | Protocol-level chunking over DNS |
| Rclone (S1040) and C0015 | Rclone's chunker overlay splits large files to circumvent size limits; in C0015 the actors limited Rclone's bandwidth during exfiltration | Splitting and throttling |
| StealBit (S1200) | Can be configured to exfiltrate files at a specified rate to evade network detection | Throttling |
| Cobalt Strike (S0154) and Mythic (S0699) | Break large data sets into smaller chunks; Mythic supports custom chunk sizes | C2 framework chunking |
Rclone documents the chunker overlay as splitting files larger than the chunk_size setting (default 2 GiB) and reassembling them on download; the feature exists to work around storage provider limits, which is why it is also useful to an adversary. See the Detecting Rclone and File-Sync Exfiltration Tooling guide, the Play Ransomware Profile and the APT28 (Fancy Bear) Threat Actor Profile.
What to detect and where
ATT&CK v20 detection strategy DET0213 (Data Transfer Size Limits and Chunked Exfiltration) has three analytics. ESXi is a listed platform for the technique, but v20 has no ESXi-specific analytic; use network flow data at the hypervisor management network boundary for those hosts.
| Analytic | Platform | Behaviour | Log sources named in v20 |
|---|---|---|---|
| AN0596 | Windows | A process makes outbound connections sending uniform packet sizes at consistent intervals, avoiding threshold alerts | Sysmon 3 and 22; NetFlow, sFlow or packet capture |
| AN0597 | Linux | Processes that are not normally network-facing repeatedly send similarly sized payloads at uniform intervals | auditd connect and sendto; outbound flow records |
| AN0598 | macOS | Processes, including LaunchAgents or unexpected users, sending data externally in consistent fixed sizes | Unified log network events; Endpoint Security connect events |
Tunable elements
| v20 element | Use |
|---|---|
| PacketSizeThreshold, TransferSizeMedian | The size around which repeated transfers count as uniform (v20 example: 512 or 1,024 bytes) |
| PayloadLengthVariance | How close sizes must be to count as fixed (v20 example: plus or minus 5%) |
| IntervalRepeatWindow, RepeatFrequencyThreshold | How many evenly spaced transfers in what period |
| ProcessNetworkBaseline, KnownServicePorts | Binaries expected to make outbound connections, and expected protocols per port |
Aggregation rules that defeat chunking
Uniformity analytics catch fixed blocks; aggregation catches everything else, including variable chunk sizes such as LunarWeb's. As NHI Mgmt Group recommendations:
- Cumulative bytes out per host and destination over 1, 6 and 24 hours, compared with that host's own baseline. A file server that has never uploaded more than a few megabytes to a destination and now sends 2 GB in 3 MB pieces stands out at 24 hours.
- Cumulative bytes out per identity: for cloud storage and SaaS, sum uploads per user or service account across sessions, so chunked uploads through many sessions add up.
- Upload to download ratio: most workstations and many servers download far more than they upload; a sustained reversal toward a rare destination is a strong signal.
- DNS volume per domain: many unique subdomains or high query volume to one registered domain indicates chunked data in DNS. See the T1572 Protocol Tunnelling Defensive Guide.
- Long-lived low-rate sessions: throttled transfers stretch over hours; long connections with steady low throughput to an unusual destination deserve review.
Endpoint signals before the transfer
| Signal | Why it matters |
|---|---|
| Bulk creation of multi-part archives (.part1.rar, .r00, .001, .z01, .7z.001) in staging folders | File splitting nearly always happens on disk first |
| Archiver command lines with volume options run by a service account or on a server | Administrators rarely create split archives on production servers |
| Rclone, WinSCP or similar sync tools appearing on hosts that have never run them, especially with chunker or bandwidth limit configuration | ATT&CK records both tools in chunked exfiltration |
| A process reading many files then making many similar-size outbound connections | Ties collection to chunked transfer in one lineage |
Where identity fits
Chunked exfiltration to cloud storage is authenticated: the adversary uses an account, an access key or an OAuth token for the destination, and often a compromised internal service account to read the data. Two identity controls change the outcome:
- Per-identity volume baselines: service accounts used by backup and sync jobs have stable volumes; a chunked transfer through one of them raises its 24 hour total even when every request is small.
- Tenant restrictions on sanctioned storage: allowing uploads only to your own tenant of a cloud storage service means a chunked upload to an attacker's account of the same service fails, however small each piece is. See the T1537 Transfer Data to Cloud Account Defensive Guide.
Mitigations
| Control | Setting or action | Effect on T1030 |
|---|---|---|
| M1031 Network Intrusion Prevention (ATT&CK v20) | Signatures for known C2 and malware traffic | Blocks known families and tool traffic patterns. See M1031 Network Intrusion Prevention |
| Egress filtering (NHI Mgmt Group recommendation) | Default-deny outbound from servers; restrict direct DNS to internal resolvers | Chunk size is irrelevant if the destination is unreachable. See Cloud Egress Filtering |
| Application control (NHI Mgmt Group recommendation) | Allow archivers and file sync tools only for approved users and hosts | Removes the common splitting and transfer tools from servers |
| Data loss prevention (NHI Mgmt Group recommendation) | Content inspection on sanctioned channels with cumulative thresholds | Inspects content rather than size. See M1057 Data Loss Prevention |
How to roll out and test
- Baseline outbound volume per host, destination and identity for 30 days, starting with file servers, database servers and hosts holding sensitive data.
- Deploy endpoint archive rules first: multi-part archive creation and archivers or sync tools on servers are low noise.
- Add cumulative volume rules at 1, 6 and 24 hours in report-only mode, then the DET0213 uniformity analytic, tuning known agents and backup jobs.
- Emulate safely: in an approved test ring, split a canary archive into 1 MB volumes and upload them to a controlled external server over several hours, once at fixed size and once throttled. Use an authorised emulation framework mapped to T1030 and canary data only.
- Promote and maintain: move to alerting once each layer fires on the tests. Roll back to report-only if a new backup product floods the rules, and add it by host, account and destination together.
Metrics
- Emulation detection: fixed-chunk, variable-chunk and throttled tests detected, and the time from first chunk to alert.
- Servers with archivers or sync tools allowed: count, trending down.
- Hosts and identities with an outbound volume baseline: percentage of sensitive systems covered.
- Unexplained cumulative volume alerts: count per week after tuning, each triaged.
Common failure patterns
- Single-transfer thresholds: a rule that fires on uploads over 100 MB never sees 3 MB parts.
- Short aggregation windows: throttled transfers spread over hours slip under hourly totals.
- Fixed-size signatures only: variable chunking, such as LunarWeb's random part sizes, defeats uniformity rules on their own.
- Ignoring DNS: data carried in small DNS queries never shows up in web proxy volume.
- Allowing sync tools everywhere: Rclone and WinSCP on production servers give an intruder a ready-made chunking and transfer tool.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1030, TA0010, DET0213 (AN0596 to AN0598), M1031 | Technique, detection analytics and mitigation |
| MITRE ATT&CK v20 | T1560, T1074, T1567, T1048, T1537 | Archiving, staging and transfer channels (each has its own page) |
| NIST SP 800-53 Rev 5 | SC-7, SI-4, AC-4, CM-7 | Boundary protection, monitoring, information flow enforcement, least functionality |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02, PR.DS-02 | Network monitoring, event analysis, data in transit |
Practitioner checklist
- Replace single-transfer thresholds with cumulative bytes out per host, destination and identity at 1, 6 and 24 hours.
- Alert on bulk creation of multi-part archives and on archivers with volume options on servers.
- Restrict Rclone, WinSCP and similar tools to approved hosts and users.
- Deploy the DET0213 uniformity analytic with tuned size variance and repeat frequency.
- Monitor DNS query volume and unique subdomains per registered domain.
- Apply default-deny egress to servers and tenant restrictions on sanctioned cloud storage.
- Test with fixed-size, variable-size and throttled canary transfers.
Standards and references
- MITRE ATT&CK: T1030 Data Transfer Size Limits
- CISA: #StopRansomware Play Ransomware (AA23-352A)
- MITRE ATT&CK: S1040 Rclone
- Rclone: Chunker overlay documentation
- MITRE ATT&CK: M1031 Network Intrusion Prevention
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: ATT&CK Exfiltration Tactic · Data Exfiltration Guide · T1029 Scheduled Transfer · T1041 Exfiltration Over C2 Channel · Detecting Rclone and File-Sync Exfiltration Tooling · NetFlow and IPFIX Flow Telemetry Guide