THREAT-DLPBypass-SubThresholdChunkedUpload

Data Transfer Size Limits — Sub-Threshold Chunked Uploads to Evade DLP Content Inspection

Exfiltration Last updated:

Most commercial DLP, CASB, and secure web gateway products only run deep content inspection (keyword/regex/fingerprint matching against the file body) on requests under a configurable maximum-inspectable-file-size — commonly somewhere in the 10-25MB range for many products, since inline inspection of arbitrarily large payloads is too expensive to do synchronously. Anything above that ceiling is typically either passed uninspected, inspected only by coarse metadata (file type, size, destination category), or queued for out-of-band analysis that lags the live request. An adversary or insider who knows — or empirically discovers by probing — where that ceiling sits can defeat content inspection entirely by fragmenting a sensitive file into a series of uploads each sized just under the threshold, so every individual request looks like an uninspected, policy-compliant transfer while the aggregate exfiltrates the whole dataset. This is a distinct manifestation of T1030 (Data Transfer Size Limits) from the archive/process-splitting variant already covered on this platform: it requires no compression utility with explicit volume flags and leaves no sequential .001/.002/.partN files on disk — a script can read arbitrary byte ranges from any source and PUT/POST each one directly over HTTPS. Because the splitting logic lives in network behavior rather than local file or process artifacts, the highest-fidelity detection signal sits at the web/proxy layer: a tight cluster of upload-sized requests from the same source to the same external destination, each landing in a narrow byte-size band immediately below the organization's known DLP/CASB inspection ceiling, with near-uniform sizes that are very unlikely to occur from organic browsing or normal application traffic.

What is THREAT-DLPBypass-SubThresholdChunkedUpload Sub-Threshold Chunked Uploads to Evade DLP Content Inspection?

Sub-Threshold Chunked Uploads to Evade DLP Content Inspection (THREAT-DLPBypass-SubThresholdChunkedUpload) is a sub-technique of Data Transfer Size Limits (T1030) in the MITRE ATT&CK framework. It maps to the Exfiltration tactic — the adversary is trying to steal data.

This page provides production-ready detection logic for Sub-Threshold Chunked Uploads to Evade DLP Content Inspection, covering the data sources and telemetry it touches: Network Traffic: Web Proxy / Secure Web Gateway logs, CASB / DLP forwarder events normalized into CommonSecurityLog. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Exfiltration
Microsoft Sentinel / Defender
kusto
let InspectionThresholdBytes = 10485760; // 10 MB — align to your DLP/CASB engine's configured max-inspectable-file-size
let NearThresholdFloor = InspectionThresholdBytes * 0.85;
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where isnotempty(RequestURL)
| where SentBytes between (NearThresholdFloor .. InspectionThresholdBytes)
| summarize
    UploadCount = count(),
    MinSent = min(SentBytes),
    MaxSent = max(SentBytes),
    TotalSent = sum(SentBytes),
    Destinations = make_set(DestinationHostName, 5),
    Urls = make_set(RequestURL, 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
  by SourceIP, DestinationIP
| where UploadCount >= 3
| extend SizeVarianceRatio = todouble(MaxSent - MinSent) / todouble(MaxSent)
| where SizeVarianceRatio < 0.15
| extend TotalSentMB = round(todouble(TotalSent) / 1048576, 2)
| project FirstSeen, LastSeen, SourceIP, DestinationIP, Destinations, Urls, UploadCount, MinSent, MaxSent, SizeVarianceRatio, TotalSentMB
| sort by TotalSentMB desc

Flags clusters of three or more outbound web/proxy uploads from the same source to the same external destination where every individual request's SentBytes falls in a narrow band (85%-100%) just under a configurable DLP/CASB content-inspection ceiling (default modeled at 10MB), with less than 15% size variance across the cluster — a pattern consistent with deliberate chunking to keep every request under the size at which content inspection engines stop scanning payloads. Requires CommonSecurityLog to be populated by a proxy, secure web gateway, or CASB forwarder that reports per-request sent byte counts.

high severity medium confidence

Data Sources

Network Traffic: Web Proxy / Secure Web Gateway logs CASB / DLP forwarder events normalized into CommonSecurityLog

Required Tables

CommonSecurityLog

False Positives

  • Video conferencing, screen-share, or telemetry-upload applications that legitimately chunk large payloads at a fixed size for protocol reasons unrelated to DLP evasion
  • Approved backup or sync agents (OneDrive, Dropbox Business, Box) that upload large files in fixed-size blocks as part of their normal resumable-upload protocol
  • Streaming media or large-file download managers whose segmented GET/PUT requests coincidentally land in the same byte-size band as the configured inspection threshold
  • Internal file-transfer or ETL tooling that chunks exports to a partner SFTP-over-HTTPS gateway on a fixed schedule as documented business process

Sigma rule & cross-platform mapping

The detection logic for Sub-Threshold Chunked Uploads to Evade DLP Content Inspection (THREAT-DLPBypass-SubThresholdChunkedUpload) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


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 1PowerShell Sub-Threshold Chunked HTTP POST Simulation

    Expected signal: Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents: powershell.exe establishing three connections to 127.0.0.1:8443 spaced ~3 seconds apart. Proxy/CASB log (if the test endpoint is placed behind a monitored proxy): three POST requests each with a body size of approximately 9,000,000 bytes.

  2. Test 2Linux curl Fixed-Size Chunk Upload Loop

    Expected signal: Process creation for curl (Sysmon-for-Linux Event ID 1 / auditd execve records) and three outbound network connection events to the test endpoint spaced ~3 seconds apart. Proxy/CASB log (if the endpoint is behind a monitored proxy): three POST requests each with a body size of approximately 9,000,000 bytes from the same source IP.

  3. Test 3macOS curl Fixed-Size Chunk Upload with Local Staging

    Expected signal: File creation events for /tmp/argus_source.bin and the split chunk files, followed by curl process creation and three outbound network connections spaced ~3 seconds apart, visible via Endpoint Security framework telemetry (es_event_type_notify_create, es_event_type_notify_exec) if a macOS EDR agent is deployed.


Response Playbook

Triage

  1. Confirm the organization's actual DLP/CASB/SWG max-inspectable-file-size setting and retune the detection's threshold constant to match it exactly — a generic 10MB default will under- or over-fire if the real ceiling differs.
  2. Pull the full list of URLs/destinations in the cluster and check whether the destination is an approved corporate file-sharing or backup service (in which case this may be legitimate chunked-upload protocol behavior) or an unrecognized/personal cloud, webmail, or file-hosting endpoint.
  3. Identify the source host and account, then check DeviceProcessEvents/Sysmon Event ID 1 in the preceding hour for the process that generated the uploads — a script interpreter, curl/rclone/custom binary invoked outside of any documented automation is high-signal; a recognized browser or sync-agent process lowers priority.
  4. Check for preceding bulk file access or archive-staging activity (large sequential file reads, or a newly created archive matching the aggregate size of the chunked uploads) that would corroborate a deliberate collect-then-exfiltrate sequence rather than routine application traffic.
  5. If proxy/TLS-inspection visibility into the request bodies exists, sample a subset of the near-threshold requests to confirm they contain fragments of a single logical file/dataset (e.g. consistent Content-Type, sequential byte ranges, or a shared session/upload-id header) rather than unrelated legitimate traffic that happens to share a size band.
  6. Correlate the destination IP/domain and source-account pattern across other hosts to determine whether this is an isolated incident or a broader campaign/insider pattern.

Containment

  1. Block the destination domain/IP at the proxy or firewall if it is not a recognized corporate service, and if TLS-inspected content confirms sensitive data, treat as a confirmed exfiltration event rather than a suspected one.
  2. Isolate the source endpoint via EDR network isolation if the initiating process is unrecognized or was launched from a user-writable/temp directory, pending forensic review.
  3. If an insider is suspected, coordinate with HR/Legal before taking any account-level action — do not unilaterally disable a user's access without following the organization's insider-threat escalation process.
  4. Raise or lower the DLP/CASB engine's max-inspectable-file-size as an interim compensating control if the current ceiling is confirmed to be the gap being exploited, understanding this trades inspection latency/cost against detection coverage.

Evidence Collection

  1. Full proxy/CASB log records for every request in the cluster (timestamps, exact byte counts, URLs, source/destination IPs, user-agent) to reconstruct the complete chunk sequence and total exfiltrated volume.
  2. Process creation and network-connection telemetry (Sysmon Event ID 1/3, DeviceProcessEvents/DeviceNetworkEvents) for the initiating process on the source host, including its full command line and parent process chain.
  3. Any locally staged source file or archive whose total size approximates the sum of the chunked uploads, plus its creation/access timestamps, to establish what was collected before transmission.
  4. If TLS inspection is available, the decrypted request bodies or at minimum Content-Type/Content-Range headers for a representative sample of the chunks, to confirm they are fragments of one dataset.

Escalation Criteria

  • ! TLS-inspected content or destination context confirms transfer of regulated data (PII, PHI, payment data), credentials, or source code — escalate for breach-notification assessment.
  • ! The destination is an unrecognized personal cloud storage, webmail, or file-hosting endpoint rather than an approved corporate service.
  • ! The initiating process is an unsigned binary or script running from a user-writable/temp directory rather than a documented automation tool or sync agent.
  • ! The affected account is privileged (domain admin, cloud admin, service account with broad data access) or the source host is a server holding sensitive repositories rather than a standard workstation.
  • ! The same chunking pattern is observed from multiple hosts or accounts within a short window, indicating coordinated or automated large-scale exfiltration rather than a single incident.

Investigation Guide

Forensic Artifacts

  • > Proxy / secure web gateway / CASB logs with per-request byte counts, URLs, and source/destination identifiers — the primary evidence source since this technique leaves minimal host-side artifacts.
  • > Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents for the outbound sessions, correlated by timestamp to the proxy log cluster.
  • > Sysmon Event ID 1 (Process Create) / DeviceProcessEvents for the initiating process, including command line and parent chain — critical since no compression tool with volume flags is required for this variant.
  • > Any locally staged source file, archive, or database export on the source host whose size approximates the sum of the chunked uploads.
  • > DLP/CASB policy configuration export showing the configured max-inspectable-file-size, needed to confirm the threshold the adversary was evading and to correctly tune this detection.

Tuning Guidance

The single highest-value tuning step is replacing the 10MB placeholder threshold with your actual DLP/CASB/SWG engine's configured max-inspectable-file-size — ask the DLP platform owner for this value rather than guessing, since vendors differ widely (some cap inspection well under 10MB, others well above 25MB) and a mismatched threshold makes this detection nearly useless. Next, build and maintain an allowlist of approved cloud-storage/file-sharing/backup destinations and sync-agent process names, since resumable-upload protocols used by legitimate services (OneDrive, Dropbox, Box, many backup agents) chunk uploads at fixed sizes by design and will otherwise dominate the alert queue. Start the SizeVarianceRatio at 0.15 and tighten toward 0.05 if your environment's legitimate segmented-upload traffic still produces noise — the lower the variance requirement, the more the detection favors deliberately-scripted chunking over organically variable application traffic. Consider raising the minimum UploadCount from 3 to 5+ in high-volume proxy environments to further suppress single-session false positives, and prioritize investigating clusters where the source process is not a recognized browser or sync agent over clusters where it is.


Hunting Queries

Hunts for the same near-threshold upload clustering, narrowed to destinations that are not on an approved corporate cloud-storage/file-sharing allowlist — sharply reduces false positives from sanctioned sync agents while preserving sensitivity to unapproved or personal-account destinations.

Hunting — KQL
kql
// Hunt: sub-threshold upload clusters to destinations outside an approved corporate-service allowlist
let InspectionThresholdBytes = 10485760;
let NearThresholdFloor = InspectionThresholdBytes * 0.85;
let ApprovedDestinations = dynamic(["sharepoint.com", "onedrive.live.com", "dropbox.com", "box.com"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SentBytes between (NearThresholdFloor .. InspectionThresholdBytes)
| where DestinationHostName !has_any (ApprovedDestinations)
| summarize UploadCount = count(), Urls = make_set(RequestURL, 10), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, DestinationHostName
| where UploadCount >= 3
| sort by UploadCount desc
Hunting — SPL
spl
index=proxy (sourcetype=cef OR sourcetype=web_proxy)
bytes_out>=8912896 bytes_out<=10485760
NOT dest IN ("*.sharepoint.com", "*.onedrive.live.com", "*.dropbox.com", "*.box.com")
| stats count as UploadCount, values(url) as Urls, earliest(_time) as FirstSeen, latest(_time) as LastSeen by src_ip, dest
| where UploadCount>=3
| sort - UploadCount

Correlates a near-threshold upload cluster with a large local file being created on the same host in the two hours beforehand — directly targets the collect-then-chunk-then-exfiltrate sequence and filters out cases where the uploads are generated by a long-running application rather than a one-off staged transfer.

Hunting — KQL
kql
// Hunt: near-threshold upload clusters preceded by large local file staging on the same host
let InspectionThresholdBytes = 10485760;
let NearThresholdFloor = InspectionThresholdBytes * 0.85;
let UploadClusters =
  CommonSecurityLog
  | where TimeGenerated > ago(7d)
  | where SentBytes between (NearThresholdFloor .. InspectionThresholdBytes)
  | summarize UploadCount = count(), TotalSent = sum(SentBytes), FirstUpload = min(TimeGenerated) by SourceIP
  | where UploadCount >= 3;
DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType == "FileCreated"
| join kind=inner (UploadClusters) on $left.LocalIP == $right.SourceIP
| where Timestamp between ((FirstUpload - 2h) .. FirstUpload)
| where FileSize > 8388608
| project Timestamp, DeviceName, FileName, FolderPath, FileSize, SourceIP, UploadCount, TotalSent, FirstUpload
| sort by Timestamp desc
Hunting — SPL
spl
index=proxy (sourcetype=cef OR sourcetype=web_proxy)
bytes_out>=8912896 bytes_out<=10485760
| stats count as UploadCount, sum(bytes_out) as TotalSent, earliest(_time) as FirstUpload by src_ip
| where UploadCount>=3
| rename src_ip as LocalIP
| join type=inner LocalIP
    [search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
     | eval LocalIP=host
     | where FileSize>8388608
     | table _time, host, TargetFilename, FileSize, LocalIP]
| where _time <= FirstUpload AND _time >= (FirstUpload - 7200)
| table _time, host, TargetFilename, FileSize, LocalIP, UploadCount, TotalSent, FirstUpload

Atomic Red Team Tests

Test 1 PowerShell Sub-Threshold Chunked HTTP POST Simulation
windows

Simulates DLP-evasive chunking by generating a synthetic payload and POSTing it to a local test endpoint in three requests each sized just under a configurable inspection threshold, replicating the near-uniform, near-threshold upload cluster this detection targets without contacting any real external service.

Command

powershell
$TestEndpoint = "https://127.0.0.1:8443/upload"
$ChunkSize = 9000000
for ($i = 0; $i -lt 3; $i++) {
  $Bytes = New-Object byte[] $ChunkSize
  (New-Object System.Random).NextBytes($Bytes)
  try {
    Invoke-WebRequest -Uri $TestEndpoint -Method POST -Body $Bytes -UseBasicParsing -TimeoutSec 10 -SkipCertificateCheck -Headers @{"X-Chunk-Index"="$i"}
  } catch {}
  Start-Sleep -Seconds 3
}
Write-Host 'Atomic test complete: 3 sub-threshold chunked POST requests generated'

Expected Telemetry

Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents: powershell.exe establishing three connections to 127.0.0.1:8443 spaced ~3 seconds apart. Proxy/CASB log (if the test endpoint is placed behind a monitored proxy): three POST requests each with a body size of approximately 9,000,000 bytes.

Expected Detection

The proxy-log KQL/SPL detection flags the cluster of three near-uniform, near-threshold-sized uploads to the same destination once routed through a monitored proxy or CASB; run this test against an inspected egress path rather than a raw loopback connection to validate the production query.

Test 2 Linux curl Fixed-Size Chunk Upload Loop
linux

Uses curl in a loop to upload three fixed-size random-data chunks to a local test endpoint, simulating the scripted byte-range chunking behavior (no compression tool, no volume flags) that a Linux-based implant or scripted exfil tool would use to stay under a DLP inspection ceiling.

Command

bash
for i in 1 2 3; do
  head -c 9000000 /dev/urandom > /tmp/argus_chunk_$i.bin
  curl -s -k -X POST --data-binary @/tmp/argus_chunk_$i.bin https://127.0.0.1:8443/upload -H "X-Chunk-Index: $i" -o /dev/null
  sleep 3
done
echo 'Atomic test complete: 3 sub-threshold chunked curl uploads generated'

Cleanup

bash
rm -f /tmp/argus_chunk_1.bin /tmp/argus_chunk_2.bin /tmp/argus_chunk_3.bin

Expected Telemetry

Process creation for curl (Sysmon-for-Linux Event ID 1 / auditd execve records) and three outbound network connection events to the test endpoint spaced ~3 seconds apart. Proxy/CASB log (if the endpoint is behind a monitored proxy): three POST requests each with a body size of approximately 9,000,000 bytes from the same source IP.

Expected Detection

Proxy-log detection flags the near-uniform, near-threshold upload cluster once traffic is routed through a monitored egress path. The file-staging hunting query fires on the three temporary chunk files created in /tmp immediately before the uploads.

Test 3 macOS curl Fixed-Size Chunk Upload with Local Staging
macos

Replicates the collect-then-chunk-then-upload sequence on macOS by staging a synthetic file locally, then uploading it in three fixed-size chunks via curl, validating both the network-layer detection and the file-staging correlation hunting query.

Command

bash
dd if=/dev/urandom of=/tmp/argus_source.bin bs=1024 count=27000 2>/dev/null
split -b 9000000 /tmp/argus_source.bin /tmp/argus_macchunk_
for f in /tmp/argus_macchunk_*; do
  curl -s -k -X POST --data-binary @"$f" https://127.0.0.1:8443/upload -o /dev/null
  sleep 3
done
echo 'Atomic test complete: staged file split and uploaded in 3 sub-threshold chunks via curl'

Cleanup

bash
rm -f /tmp/argus_source.bin /tmp/argus_macchunk_*

Expected Telemetry

File creation events for /tmp/argus_source.bin and the split chunk files, followed by curl process creation and three outbound network connections spaced ~3 seconds apart, visible via Endpoint Security framework telemetry (es_event_type_notify_create, es_event_type_notify_exec) if a macOS EDR agent is deployed.

Expected Detection

Proxy-log detection fires on the near-uniform, near-threshold upload cluster when routed through a monitored egress path. The file-staging correlation hunting query fires on the large source file created in /tmp shortly before the upload cluster begins.

Related Detections