Detecting T1030 Data transfer size limits

How T1030 data transfer size limits shows up in exfiltration

For a SOC lead, the uncomfortable pattern is this: outbound volume looks normal for each session, yet data still leaves the environment in pieces. T1030 Data Transfer Size Limits is the technique where an adversary splits stolen data into transfers capped at a set size, so that no single transfer stands out against volume thresholds, alert baselines or per-session limits. It sits under the Exfiltration tactic (TA0010), which MITRE describes as the adversary trying to steal data. The technique is about how the data is shaped on the wire, so it is usually one step in a larger exfiltration path rather than a standalone event.

This page targets MITRE ATT&CK Enterprise version 20.0, and the platforms in scope are Linux, macOS, Windows and ESXi. Confirm the platform coverage for your own estate against the technique page in the version you map to, because platform lists and sub-technique structure can change between releases. Across intrusions, T1030 tends to appear after collection has already staged data, when an adversary moves archives or database extracts out through an existing channel. Your first decision is which channels in your environment could carry that pattern, for example outbound web, DNS, remote administration or cloud sync paths, and whether you can see transfer sizes and timing on each of them.

The practical risk is that per-event alerting alone will not catch this. Plan for analysis across a window of sessions to the same destination, and confirm with your monitoring team whether your current telemetry keeps enough flow-level history to support that. Ask your detection engineers which data components they currently map for network activity, since the detection approach on the next sections depends on them.

Which telemetry reveals size-limited transfers

This table maps the data components most relevant to T1030 to Linux, macOS, Windows and ESXi, and names an open-source collector for each. Read it as a starting point for deciding which sensors to deploy and which platform gaps to confirm in your own environment before writing detection logic.

Data component	Signal to look for	Open-source collector	Platform notes
Network Connection Creation (DC0082)	Many short sessions from one host to the same destination, each with similar byte counts	Wazuh agent, Zeek conn logs, Velociraptor hunts on socket state	Confirm endpoint socket visibility on Linux, macOS and Windows; ESXi may need network-side collection
Network Traffic Flow (DC0078)	Repeated outbound flows of comparable size on a regular interval, bounded by per-session limits	Zeek conn.log, Suricata flow records, Security Onion dashboards	Best coverage is at a network sensor on the egress path; confirm sensor placement for ESXi management traffic
Process Creation (DC0032)	A process that repeatedly opens outbound connections and splits data into chunks	Wazuh process monitoring, Velociraptor artifacts, Sysmon on Windows	Available on Linux, macOS and Windows agents; confirm audit configuration on each host class
Network Traffic Content (DC0085)	Payload structure that repeats in fixed-size segments when deep inspection is permitted	Suricata with payload inspection, Zeek file and protocol analyzers	Often limited by encryption; confirm which traffic your policy allows you to decrypt or inspect
Process-to-socket relationship	A single process holding many short connections to one external address	Velociraptor, Wazuh inventory, Zeek connection join with host telemetry	Requires endpoint and network records to share timestamps and host identifiers; confirm time sync across sources
ESXi host telemetry	Outbound flows from management or hypervisor addresses that break a normal pattern	Zeek or Suricata on the management network, syslog forwarding to Wazuh	Agent-based endpoint collection is usually not available on ESXi; confirm forwarding options in your vendor documentation

Detection logic for size-limited exfiltration

T1030 Data transfer size limits describes adversaries splitting stolen data into chunks so that no single transfer stands out. The cards below describe detection ideas that look for the aggregate pattern across flows, sessions and hosts rather than any single large transfer. Each idea needs thresholds tuned against your own baselines and a documented list of benign sources that will trigger it.

Sliding window byte aggregation

Sum outbound bytes per source host and destination over several sliding windows, such as short, medium and long intervals, using Network Traffic Flow records. Size-limited transfers often stay under a per-connection limit but accumulate steadily over hours. Set the threshold per host role from a baseline of at least several weeks, and alert when a host exceeds its own historical percentile rather than a single global number. Expect false positives from backup jobs, replication, and large software deployments, so keep an allowlist of known destinations with owners.

Uniform chunk size detection

Look for many outbound flows from one host that carry payloads of nearly identical size over a short period. Deliberate chunking often produces a narrow size distribution, while normal web, API and sync traffic varies widely. Use Network Traffic Content or flow byte counts where available, and flag clusters only when the count of similar flows crosses a baseline you have measured. Tune the size bucket width carefully. Encrypted CDN responses, video streaming and telemetry agents can all produce tight distributions, so confirm the destination before escalating.

Session count anomalies

Track the number of new outbound sessions per host and per destination within a window, using Network Connection Creation events. A host that normally opens a handful of connections to a destination but suddenly opens hundreds of short-lived sessions may be sending data in pieces across many connections. Compare against the host's own history and its peer group. Common false positives include package managers, container image pulls, monitoring agents that reconnect frequently, and load balancers with connection pooling. Record the expected session pattern for each server class so analysts can separate normal bursts from suspicious ones.

Process to egress correlation

On Linux, macOS and Windows endpoints, correlate Process Creation and file access events with outbound network activity from the same process. A process that reads many files from a sensitive path and then produces steady outbound traffic in small increments warrants review. Keep the correlation keyed on process lineage and user context, not process name alone. Legitimate sources include backup clients, sync tools, browsers and developer tooling, so build an inventory of approved egress-capable binaries per role and treat deviations from it as the signal.

ESXi management plane egress baselines

Establish a baseline of outbound traffic from ESXi hosts and vCenter management interfaces, which normally talk only to known update, licensing, and monitoring endpoints. Any sustained outbound volume from these hosts, even modest, deserves attention because management networks rarely need broad internet egress. Alert on volume increases against this baseline and on new destinations. Expect false positives from vendor patch downloads, time synchronization, and approved backup agents, so document each permitted destination and its owner before setting thresholds.

How to validate the T1030 detection in a lab

This sequence tests whether the T1030 Data transfer size limits detection fires as designed in a private lab or cyber range, and it produces a written record of telemetry, latency, false positives and tuning actions for the detection backlog. It is run against a named ATT&CK version so results stay comparable after future releases.

Write the hypothesis and fix the ATT&CK version
Start by writing a short hypothesis that states which behavior the detection should catch, on which platforms (Linux, macOS, Windows or ESXi), and which data components it relies on, such as Network Connection Creation and Network Traffic Flow. Name the ATT&CK version the detection maps to, and confirm that the technique and its detection strategy still exist in that version. ATT&CK releases can rename, deprecate or revoke techniques, so check the MITRE ATT&CK updates pages before you start. The step is done when the hypothesis, platform list and version are signed off by the detection owner.
Define scope and agree the emulation plan in writing
Set the boundaries of the exercise: which lab hosts, network segments and accounts are in scope, which telemetry sources must be healthy, and what must never leave the range. Agree the emulation plan in writing with the asset owner and the security operations lead, including who approves the run, who can halt it, and how stakeholders are notified. Ask the range provider to confirm isolation controls in writing before any traffic is generated. The step is done when the signed plan is stored with the test record and the asset owner has confirmed the scope.
Verify telemetry health before the run
Confirm that the log and network sources the detection depends on are collecting and parsing correctly in the lab, including the agent or sensor feeding network connection records and flow records. Check that timestamps are synchronized across sources so latency can be measured later. A missing source is a gap in the test, not a detection failure, so record its state before the run. The step is done when a baseline check shows each required data component is present on every in-scope platform.
Run the emulation without publishing commands
A named operator executes the approved emulation plan inside the isolated range while a second person observes and keeps a time-stamped log of start and stop times, targets and any deviations. Keep the operational details in the restricted test record rather than in shared documentation, so the public or team wiki carries only the outcome. Stop the run immediately if traffic reaches systems outside scope. The step is done when the operator's log and the observer's log match and the run is closed in the test record.
Record which telemetry fired and when
Pull the alerts, events and flow records generated during the run window and map each one to the hypothesis. Note which data components produced evidence, on which hosts and at what time, and whether the expected alert fired, fired late, fired for a different reason, or did not fire. Keep raw records alongside the summary so a reviewer can re-check the mapping. The step is done when every expected detection outcome has a recorded result, even if the result is a miss.
Measure detection latency and false positives
Calculate the time between the first emulated activity and the first alert, per platform and per data source, and record it in the test report. Review all alerts raised during the baseline and run windows to separate true positives from false positives caused by normal lab activity, such as scheduled backups or software updates. Ask your team to define in advance what latency and false-positive rate they consider acceptable, since no industry figure is assumed here. The step is done when latency and false-positive counts are recorded for each in-scope platform.
Document gaps and log tuning changes in the backlog
Write up each gap, including missing telemetry, rule logic that did not match, thresholds that were too high or too low, and platforms with no coverage. For each gap, create a backlog item with an owner, a proposed change and a retest requirement, and link it to the ATT&CK mitigation records such as Network Intrusion Prevention, so preventive controls are reviewed alongside detection. Rerun the emulation after tuning to confirm the change works without creating new noise. The step is done when every gap has a tracked item and the retest result is attached to the original test record.

Preventive controls with ATT&CK mitigation IDs

Preventive controls can reduce how much data an adversary moves out in a single transfer, but each one sees a different slice of the traffic. The cards below pair the primary mitigation for this page with related controls, and note what each one can and cannot see. Confirm every mapping against the ATT&CK 20.0 technique page before you rely on it.

Network Intrusion Prevention (M1031)

Primary mitigation for this page. Network-based prevention sits inline or on a tap with blocking enabled, and can alert on or drop egress that matches signatures or anomaly rules, such as unusually large outbound volumes from a host that normally sends little. For T1030, the useful question is whether the sensor can measure bytes per session or per time window, not only match known bad patterns. Check whether the sensor is inline or passive, because a passive sensor can alert but cannot stop the transfer.

Filter Network Traffic (M1037)

Egress filtering at firewalls, proxies and cloud security groups limits which destinations and ports a host can reach at all. Size limits are not the main goal here, but a default-deny outbound policy removes many of the channels a large transfer would need. Confirm with your network team which segments can reach the internet directly and which must pass through a monitored proxy. Filtering alone will not see the size of an allowed transfer.

Data Loss Prevention (M1057)

Data loss prevention tools inspect content and policy context at endpoints, email, web gateways or cloud services, and can flag or block sensitive data leaving the organization. They are most useful for T1030 when the transferred data is classified or regulated, because they can recognize the content rather than only its volume. Their visibility depends on decryption, agent coverage and content types they can parse. Confirm which channels each DLP control covers before assuming coverage.

Encrypted traffic inspection

Most egress now runs over TLS, so a prevention sensor that cannot decrypt traffic can still count bytes and session durations but cannot read payloads. Decryption raises legal, privacy and performance questions that must be settled before deployment, including which destinations are exempt. Ask your vendor or platform team whether size-based rules still work on pinned or excluded connections. Document the exclusions, since they become blind spots in your T1030 detection.

Confirm mappings against ATT&CK 20.0

Mitigation mappings can change between ATT&CK releases, so the IDs above should be checked on the T1030 technique page for the version you target. Record the version, the date you checked and the person who confirmed it in your control evidence. This matters for compliance readiness because auditors will ask how each control maps to the technique. Treat any mismatch as a gap to resolve, not a detail to ignore.

Triage when a size-limit exfiltration alert fires

Start by answering three questions before anything is contained: where the outbound volume is going, who owns that destination, and which process and identity produced it. Resolve the destination IP or domain against your asset inventory, DNS logs and cloud provider ranges, and record the owner, purpose and whether it is an approved backup, update or SaaS endpoint. Then pull identity and process context for the source host from Network Connection Creation and Process Creation events, looking for the account that owned the session, the parent process, and whether the transfer was split into many smaller flows that together exceed a normal volume for that host. A size-limit alert on its own shows a threshold was crossed, not that data left the organization, so the triage record should state the evidence supporting each answer.

Next, scope the activity beyond the first host. Search Network Traffic Flow records for other internal hosts talking to the same destination over the same window, and check whether the same account or process appears elsewhere. Preserve evidence before any change: export the relevant flow records, endpoint process and network telemetry, and any file access logs for the affected directories, and hash or snapshot the host if your procedure calls for it. Check whether the data classes involved, such as customer records, credentials, source code or regulated health or payment data, are stored on the source host or in the directories touched. Ask the incident commander to decide on containment with that information in hand, including whether to block the destination, isolate the host or disable the account, and record who approved the decision and when.

Before escalating, rule out the known benign causes. Backup jobs, software update channels, log shipping and replication commonly produce large outbound transfers on a schedule, so compare the alert against a documented baseline of expected destinations, volumes and time windows for each host group, and confirm the change record for the job or update window. Where a baseline is missing, that gap is itself a finding: the alert cannot be closed as benign on memory. Feed every outcome back into tuning. Confirmed false positives should become allowlist entries with an owner, an expiry date and a reference to the baseline, while true positives should adjust thresholds, add the destination to watchlists and update the cyber range scenario so the next rehearsal exercises the same path.

Rehearsing T1030 detection in a private cyber range

This range uses a small set of Linux and macOS hosts on an isolated network segment with synthetic user data and no route to production systems. Endpoint agents forward process and network connection events to the Wazuh or Security Onion stack, and Zeek or Suricata sit on the segment to record flow volume. The blue team receives injects describing a host that begins sending an unusually large amount of data outbound in a pattern that does not match its normal baseline, delivered as scripted traffic generated by the range operators.

Range topology: Two to three endpoints, one egress sensor and a log collector, all on a segment with synthetic accounts and data.
Injects: Scripted outbound transfer volumes that are split into chunks, supplied to the team as a timeline and not as commands.
Good detection: Network flow and connection events reach the SIEM within the expected window, and the rule that compares volume against baseline fires with the host, user and destination enriched.
Good severity: The alert is rated according to asset criticality and whether the destination is on an approved list, not only on volume.
Good response: Triage notes record the baseline comparison, the containment decision is logged with its owner, and after-action items name any missing telemetry such as file or process context.

Check that the time from transfer start to alert matches the rule design and that every enrichment field is populated before closing the exercise.

Questions SOC leads ask about detecting T1030

How do I set byte-volume windows without drowning in false positives?

Start from a per-asset baseline rather than a single global threshold, then alert on sustained deviation within a time window. Build the baseline from several weeks of Network Connection Creation and Network Traffic Flow records for each host group, separating backup servers, file transfer hosts, developer workstations and ordinary endpoints. Keep the window short enough to catch chunked transfers and long enough to avoid firing on normal bursts such as software updates. Tune by tagging known large-transfer workflows as expected and reviewing every suppression on a fixed schedule, so suppressions do not quietly hide real activity. Document the baseline period and the thresholds in your detection record so an auditor or a new analyst can see why each value exists.

Does Zeek or Suricata give better visibility for chunked transfers?

They answer different questions, so most teams run both. Zeek produces connection-level summaries, including byte counts per direction and connection duration, which suits volume-window logic across many small sessions. Suricata's signature and flow engine is better suited to matching protocol patterns and alerting on specific sessions in near real time. For chunked transfers spread across many connections, Zeek's connection logs usually carry the signal that matters, because a single session may look small. Confirm in your own environment which fields your sensor version exports and how long connection logs are retained, since the answer depends on the deployed versions and sensor placement.

How does encrypted traffic affect detection of size limits?

Encryption hides payload content, but it does not hide sizes, timing, or direction, so volume-based detection still works on encrypted sessions. Network Traffic Content analytics will be weak on TLS traffic unless you use TLS inspection with appropriate legal and privacy approval. Without inspection, rely on Network Traffic Flow and connection metadata such as destination reputation, server name indication, certificate details and outbound byte ratios. Expect more noise from legitimate cloud sync and SaaS traffic, so pair volume thresholds with destination context. Confirm with your legal and privacy teams before enabling any inspection, because the rules differ by jurisdiction and by employee monitoring policy.

How do I handle ESXi telemetry gaps?

Treat ESXi as a known blind spot until you have confirmed what it sends. Hypervisor hosts often generate fewer endpoint-style logs than Linux or Windows, so volume detection should lean on network-side sources: flow records from the virtual switch or upstream firewalls, and connection logs from sensors placed on the management and storage networks. Forward host and vSphere logs to your SIEM through a supported syslog path, then check that the events you depend on actually arrive. Document which signals are missing for ESXi so that coverage gaps are visible to the team and to assessors rather than assumed away. Verify the supported log sources with your vendor's current documentation for your version.

How do I keep this detection current across ATT&CK v19 and v20 changes?

Pin every detection to the ATT&CK version it targets, and record that version in the rule metadata. ATT&CK releases can rename, deprecate or revoke techniques, so a mapping that was correct for one version may need review after the next. The v19 release notes were published on April 28, 2026, and v20 on October 13, 2026, so check each release's notes against your technique mapping and against the STIX bundle for the version you use. Assign an owner to review the mapping after each release, and log changes to thresholds and data sources in version control. Verify the current release notes on the ATT&CK updates page before each review.

How do I test size-limit detections repeatably?

Build a scripted test plan in a private cyber range that generates known transfer volumes across defined durations, source hosts and protocols, then record the expected alert outcome for each case. Repeat the same plan after every rule change to catch regressions, and include benign high-volume cases such as backups so you measure false positives as well as detections. Keep the traffic generators, seed data and expected results under version control so a result can be reproduced months later. Store each run's output with the rule version and ATT&CK version used. This gives your team and your assessors evidence of both detection and tuning, without relying on a one-time test.

How DeployOpen builds T1030 detections and range exercises

DeployOpen approaches T1030 Data transfer size limits as a fixed-scope engagement inside your own environment. We agree the telemetry, platforms and ATT&CK version in writing, then build and rehearse detections on open-source tooling that your team can operate after handover.

How we scope

Confirm which platforms are in scope, such as Linux, macOS, Windows and ESXi, and which log sources each one can provide.
Record the ATT&CK version the detections target, since releases can rename or deprecate techniques.
Agree deliverables, timelines and exclusions in writing before any detection work begins, as all engagements are fixed-scope.

How we build

Map network connection and network traffic flow telemetry to detection logic for T1030 in plain language and open-source formats.
Tune thresholds against your normal bulk transfer patterns, such as backups and data replication, to reduce false positives.
Review the Network Intrusion Prevention mitigation against your existing sensors and document any gaps that remain.

How we hand over

Deliver detection content, validation notes and a response runbook written for your SOC analysts and engineers.
Run a private cyber range exercise that replays benign and simulated size-limited transfers against the detections.
Document known blind spots, such as encrypted traffic without content visibility, so owners can decide on compensating controls.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement ends.
Retainers can cover re-validation when your ATT&CK version changes or when log sources and sensors are upgraded.
Ask any provider to confirm which of these items is one-time work and which recurs before you sign.

T1030 Data transfer size limits