THREAT-Exfil-ArchiveSplitDLPThresholdEvasion Elastic Security · Elastic

Detect Archive Volume-Splitting and Fixed-Chunk Transfers to Evade DLP/Network Size-Threshold Alerting in Elastic Security

Most corporate DLP appliances and egress proxies alert on a single transfer or an aggregate daily transfer that crosses a configured size threshold (commonly 10MB, 25MB, or 50MB per-connection triggers, or a daily-total cap on a per-user or per-host basis). Adversaries who know or can infer these thresholds deliberately keep every individual transfer just under the trigger point by splitting collected data into fixed-size archive volumes before exfiltration — APT28 has been observed constraining exfil chunks to stay under configured DLP alert sizes during Ukraine-focused intrusions, LuminousMoth caps individual uploads at roughly 5MB when exfiltrating over Google Drive, Threat Group-3390 (Emissary Panda/APT27) has used volume-split RAR/7-Zip archives ahead of staged transfers, and Play ransomware affiliates split staged loot into uniform archive parts before the double-extortion exfil phase that precedes encryption. Because none of these chunks individually crosses a size-based alert threshold, and because the transfers are frequently spread across a sustained window rather than sent as a single burst, this technique defeats naive 'alert on large transfer' DLP rules that do not aggregate related connections by destination or by process. Detection therefore has to correlate two signals a single-transfer DLP rule cannot see on its own: (1) command-line or file-system evidence that data was deliberately split into equal-sized volumes immediately before egress, and (2) a burst of multiple outbound transfers to the same external destination whose sizes cluster tightly around a value just below a known DLP/proxy threshold rather than exhibiting the size variability of normal user traffic.

MITRE ATT&CK

Tactic
Exfiltration

Elastic Detection Query

Elastic Security (Elastic)
eql 
sequence by host.id with maxspan=24h
  [process where event.type == "start"
    and process.name in~ ("7z", "7za", "7zr", "7z.exe", "7za.exe", "7zr.exe", "rar", "rar.exe", "winrar.exe")
    and process.command_line : ("* -v*", "* /v*", "*-volume*")
  ]
  [network where event.type == "connection" and network.direction == "outbound"
    and destination.ip != null
    and network.bytes > 1048576
  ]
high severity medium confidence

Elastic EQL sequence correlating an archive volume-split process event with a subsequent outbound network connection carrying more than 1MB, within a 24-hour window per host. Intended as a first-pass sequence filter; analysts should further bucket the resulting network.bytes values against the organization's configured DLP thresholds (10MB/25MB/50MB) and cluster multiple connections to the same destination.ip, mirroring the KQL/SPL threshold-bucketing and size-spread logic, since EQL sequence queries do not natively support the aggregation math used there.

Data Sources

Elastic Endpoint SecurityElastic Agent network integration

Required Tables

logs-endpoint.events.process-*logs-endpoint.events.network-*

False Positives & Tuning

  • Backup software chunking uploads at a fixed size close to but under a proxy or API limit
  • Cloud storage sync clients using fixed multipart upload block sizes
  • CI/CD artifact upload tooling with a fixed chunk size

Other platforms for THREAT-Exfil-ArchiveSplitDLPThresholdEvasion

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 1Split archive into DLP-threshold-adjacent volumes and upload each below a monitored size

    Expected signal: Sysmon Event ID 1 for 7z.exe with CommandLine containing '-v9646899b'. Sysmon Event ID 11 for the .7z.001 through .7z.004 chunk files. Sysmon Event ID 3 / proxy logs for 4 outbound POST connections to the test endpoint with near-identical byte counts just under 10MB.

  2. Test 2Unix split-based chunking with repeated near-threshold curl uploads

    Expected signal: Linux auditd/Sysmon-for-Linux process events for split with '-b 24117145'. File creation events for argus_dlp_chunk_00 through argus_dlp_chunk_04. Network connection events for repeated curl POST requests with near-identical payload sizes just under 25MB to the same destination.

  3. Test 3WinRAR volume-split with delayed, spread-out uploads to avoid burst-based detection

    Expected signal: Sysmon Event ID 1 for WinRAR.exe with '-v48234291b'. Sysmon Event ID 11 for the .part1.rar through .part4.rar files. Proxy/network logs showing 4 uploads near the 50MB threshold spread across roughly 90 seconds rather than a tight burst.

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

Response Playbook

Triage

  1. Confirm the archive-splitting command line in full and note the declared volume size — compare it against the organization's known DLP/proxy alert thresholds (commonly 10MB, 25MB, 50MB per-connection, or a daily aggregate cap) to establish whether the chunk size looks deliberately tuned to stay just under a specific control.
  2. Pull the correlated outbound connection list for the same host and destination IP in the following hours — confirm the transfer count, per-transfer size, and whether sizes cluster tightly (low spread) rather than varying like normal user traffic.
  3. Identify the destination — is it a known-benign corporate egress point (approved cloud storage, backup target) or an unfamiliar external IP/domain with no prior traffic history from this host?
  4. Check whether the same account or host has any DLP/proxy alerts that fired just below the threshold but were suppressed as 'not large enough to page' — this is exactly the blind spot this technique is designed to exploit, so review near-miss logs even if no single alert fired.
  5. Review process ancestry for the splitting tool — was it launched interactively, by a script, or by a remote-access/C2 tool? Adversaries automating this pattern typically script both the split and the subsequent upload rather than running them by hand.
  6. Check for preceding staging or collection activity (bulk file copy, database export, credential dumping) in the 1-2 hours before the split — this technique is a late-stage exfil-preparation step, not a standalone event.

Containment

  1. If transfers to the destination are still in progress, block the destination IP/domain at the perimeter firewall and proxy immediately, and isolate the endpoint via EDR network isolation if active exfiltration is confirmed.
  2. Add the matched DLP-threshold-evasion pattern (multiple near-identical-size transfers to one destination) as a correlation rule in the DLP/proxy platform itself, not just the SIEM, so future occurrences are flagged at the control point rather than only in hindsight.
  3. If a compromised account is identified, disable it, revoke active sessions/tokens, and rotate credentials that may have been staged for exfiltration.
  4. Preserve the split archive files in place for forensic collection before any cleanup — they may need to be catalogued for breach-notification scoping.
  5. If the destination is an attacker-controlled cloud storage or dead-drop endpoint, request takedown/legal preservation from the provider using the destination details captured during evidence collection.

Evidence Collection

  1. Full command line and timestamp of the archive-splitting invocation, plus the resulting chunk files (hash each, record sizes and timestamps).
  2. Firewall/proxy connection logs for every transfer in the correlated burst — destination IP/domain, per-connection byte count, protocol, and timing, to reconstruct the total volume actually exfiltrated.
  3. Process creation logs (Sysmon Event ID 1 / Security 4688) for the splitting tool and its full parent process chain.
  4. Any known DLP/proxy near-miss or suppressed-alert logs for the same host/account in the relevant window — these often exist even when no page-worthy alert fired.
  5. Prefetch entries for the compression tool (7Z.EXE-*.pf, RAR.EXE-*.pf) confirming execution even if command-line logging is incomplete.
  6. Shell history (PSReadLine, .bash_history) that may reveal the exact splitting and upload commands used, especially if scripted end-to-end.

Escalation Criteria

  • !The chunk size and per-connection destination pattern match a known DLP or proxy threshold configured in this environment, indicating the adversary had specific knowledge of (or successfully inferred) internal control tuning.
  • !The correlated transfer burst totals a volume consistent with a meaningful dataset (multiple gigabytes) rather than a handful of small files.
  • !The destination is confirmed external and not an approved corporate egress point, particularly if it resolves to infrastructure associated with a known ransomware affiliate or APT group.
  • !Evidence of prior collection/staging activity (bulk copy, database export, credential access) precedes the split, indicating a targeted, multi-stage intrusion rather than incidental large-file handling.
  • !The same threshold-evasion pattern appears on multiple hosts within a short window, indicating coordinated exfiltration ahead of a broader event such as ransomware deployment or a data-leak extortion demand.

Investigation Guide

Related Techniques

T1030 — Data Transfer Size Limits (the parent technique; this scenario is the DLP-threshold-evasion-specific application of it)T1560 — Archive Collected Data (data is typically archived before being split into volumes)T1560.001 — Archive via Utility (7-Zip/WinRAR create the archive that is subsequently split)T1074.001 — Local Data Staging (files staged locally before splitting and transfer)T1048 — Exfiltration Over Alternative Protocol (the channel carrying the size-capped chunks)T1567.002 — Exfiltration to Cloud Storage (cloud upload APIs are a common destination for threshold-evading chunks)T1029 — Scheduled Transfer (chunks may additionally be spread across a schedule to further evade rate-based alerting)

Forensic Artifacts

  • >NTFS $MFT records for sequentially named chunk files, including entries that persist after deletion.
  • >Windows Prefetch for the compression tool (7Z.EXE-*.pf, RAR.EXE-*.pf) confirming execution and referenced paths.
  • >Firewall/proxy egress logs showing the clustered near-threshold transfer burst — the single most important artifact for confirming this specific scenario versus generic archive splitting.
  • >DLP platform near-miss or suppressed-alert logs, if the DLP product retains sub-threshold events rather than discarding them.
  • >Shell history (PSReadLine ConsoleHost_history.txt, .bash_history) potentially containing the full splitting and upload command sequence.
  • >Windows Event Log Security 4663 / Sysmon Event ID 11 for chunk file creation timestamps used to establish the staging timeline.

Tuning Guidance

Before enabling this in blocking or high-priority alerting mode, catalogue the organization's actual DLP/proxy per-connection and daily-aggregate thresholds and substitute them for the placeholder 10MB/25MB/50MB values in both the KQL and SPL detections — the technique only works against thresholds an adversary can infer, so matching your real configured values dramatically increases signal quality. Exclude known backup, replication, and approved cloud-sync hosts by device name and destination, since fixed-chunk uploads are a normal behavior for that class of software; the distinguishing factor for true positives is a NEW destination or host with no prior sanctioned chunked-transfer history. Because DLP threshold configurations themselves are sensitive (revealing them tunes adversary evasion further), treat the specific threshold values used in this detection's configuration as internal and do not publish them outside the security team.

Hunting Queries

Standalone network-only hunt for the threshold-clustering pattern without requiring a matched archive-splitting process event — useful when the split occurred off-host, via a pre-staged tool, or before process logging began. Broadening the lookback to 14 days catches slower, deliberately spread-out exfiltration.

Hunting — KQL
kql 
// Hunt: repeated outbound transfers per host/destination clustering tightly below common DLP thresholds, without requiring a prior splitting command match
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where ActionType == "ConnectionSuccess" and RemoteIPType == "Public"
| where SentBytes > 1048576
| summarize TransferCount = count(), MinSent = min(SentBytes), MaxSent = max(SentBytes),
      FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by DeviceName, InitiatingProcessFileName, RemoteIP
| where TransferCount >= 4
| extend SizeSpreadRatio = todouble(MaxSent - MinSent) / todouble(MaxSent)
| where SizeSpreadRatio < 0.10
| extend NearTenMB = MaxSent < 10485760 and MaxSent > 9646899,
         NearTwentyFiveMB = MaxSent < 26214400 and MaxSent > 24117145,
         NearFiftyMB = MaxSent < 52428800 and MaxSent > 48234291
| where NearTenMB or NearTwentyFiveMB or NearFiftyMB
| sort by TransferCount desc
Hunting — SPL
spl 
index=firewall OR index=proxy earliest=-14d
NOT (dest_ip="10.*" OR dest_ip="172.16.*" OR dest_ip="192.168.*")
bytes_out>1048576
| stats count as TransferCount, min(bytes_out) as MinSent, max(bytes_out) as MaxSent, earliest(_time) as FirstSeen, latest(_time) as LastSeen by host, dest_ip
| where TransferCount>=4
| eval SizeSpreadRatio=round((MaxSent-MinSent)/MaxSent,3)
| where SizeSpreadRatio<0.10
| eval NearThreshold=if((MaxSent<10485760 AND MaxSent>9646899) OR (MaxSent<26214400 AND MaxSent>24117145) OR (MaxSent<52428800 AND MaxSent>48234291), 1, 0)
| where NearThreshold=1
| sort - TransferCount

Hunts specifically for volume sizes matching common DLP/proxy threshold values (10/25/50/100MB) in the splitting command itself, which is a higher-confidence indicator of deliberate threshold-tuning than generic archive splitting for media-size compatibility.

Hunting — KQL
kql 
// Hunt: archive-splitting commands with unusually small volume sizes (stronger evasion signal than large media-compatibility splits)
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("7z.exe", "7za.exe", "7zr.exe", "rar.exe", "winrar.exe")
| where ProcessCommandLine matches regex @"(?i)[\s/-]v(10|25|50|100)m\b"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\7z.exe" OR Image="*\\7za.exe" OR Image="*\\7zr.exe" OR Image="*\\rar.exe" OR Image="*\\WinRAR.exe")
CommandLine="*v10m*" OR CommandLine="*v25m*" OR CommandLine="*v50m*" OR CommandLine="*v100m*"
| table _time, host, User, Image, CommandLine
| sort - _time

Atomic Red Team Tests

Test 1 Split archive into DLP-threshold-adjacent volumes and upload each below a monitored size
windows

Creates a test archive split into 9.5MB volumes (just under a common 10MB DLP alert threshold) using 7-Zip, then performs multiple HTTP uploads of each chunk to a local test endpoint to simulate the correlated splitting-plus-clustered-transfer pattern this detection targets.

Command

powershell 
fsutil file createnew %TEMP%\argus_dlp_source.bin 39845888 && "C:\Program Files\7-Zip\7z.exe" a -v9646899b %TEMP%\argus_dlp_chunks.7z %TEMP%\argus_dlp_source.bin && for %f in (%TEMP%\argus_dlp_chunks.7z.*) do curl -s -k -m 5 -X POST --data-binary @"%f" https://127.0.0.1:8443/upload -o nul

Cleanup

powershell 
del /f /q "%TEMP%\argus_dlp_source.bin" "%TEMP%\argus_dlp_chunks.7z.001" "%TEMP%\argus_dlp_chunks.7z.002" "%TEMP%\argus_dlp_chunks.7z.003" "%TEMP%\argus_dlp_chunks.7z.004" 2>nul

Expected Telemetry

Sysmon Event ID 1 for 7z.exe with CommandLine containing '-v9646899b'. Sysmon Event ID 11 for the .7z.001 through .7z.004 chunk files. Sysmon Event ID 3 / proxy logs for 4 outbound POST connections to the test endpoint with near-identical byte counts just under 10MB.

Expected Detection

KQL/SPL correlation fires: the 7z.exe volume-split command matches the process signal, and the 4 clustered near-10MB-threshold transfers to the same destination within the following minutes satisfy the TransferCount>=4 and SizeSpreadRatio<0.10 conditions.

Test 2 Unix split-based chunking with repeated near-threshold curl uploads
linux

Uses the Linux split utility to divide a synthetic file into 25MB-adjacent chunks, then uploads each chunk with curl to simulate the threshold-evasion transfer pattern on a Linux host, exercising the detection's Unix split branch and network-clustering logic together.

Command

bash 
dd if=/dev/urandom of=/tmp/argus_dlp_source.bin bs=1M count=100 2>/dev/null && split -b 24117145 -d /tmp/argus_dlp_source.bin /tmp/argus_dlp_chunk_ && for f in /tmp/argus_dlp_chunk_*; do curl -s -k -m 5 -X POST --data-binary @"$f" https://127.0.0.1:8443/upload -o /dev/null; done

Cleanup

bash 
rm -f /tmp/argus_dlp_source.bin /tmp/argus_dlp_chunk_*

Expected Telemetry

Linux auditd/Sysmon-for-Linux process events for split with '-b 24117145'. File creation events for argus_dlp_chunk_00 through argus_dlp_chunk_04. Network connection events for repeated curl POST requests with near-identical payload sizes just under 25MB to the same destination.

Expected Detection

The Unix-split branch of the process-side detection matches, and the correlated network burst (4+ transfers, tight size clustering under the 25MB threshold bucket) triggers the join condition in both the KQL and SPL queries.

Test 3 WinRAR volume-split with delayed, spread-out uploads to avoid burst-based detection
windows

Simulates a more patient adversary variant that splits an archive with WinRAR into 50MB-adjacent volumes but uploads each chunk with a deliberate delay between transfers, testing whether the hunting query's 14-day lookback still surfaces the pattern when the burst-oriented 24-hour correlation window in the primary detection would not.

Command

powershell 
fsutil file createnew %TEMP%\argus_dlp_source2.bin 193002496 && "C:\Program Files\WinRAR\WinRAR.exe" a -v48234291b %TEMP%\argus_dlp_chunks2.rar %TEMP%\argus_dlp_source2.bin && for %f in (%TEMP%\argus_dlp_chunks2.part*.rar) do (curl -s -k -m 5 -X POST --data-binary @"%f" https://127.0.0.1:8443/upload -o nul & timeout /t 30 /nobreak >nul)

Cleanup

powershell 
del /f /q "%TEMP%\argus_dlp_source2.bin" "%TEMP%\argus_dlp_chunks2.part1.rar" "%TEMP%\argus_dlp_chunks2.part2.rar" "%TEMP%\argus_dlp_chunks2.part3.rar" "%TEMP%\argus_dlp_chunks2.part4.rar" 2>nul

Expected Telemetry

Sysmon Event ID 1 for WinRAR.exe with '-v48234291b'. Sysmon Event ID 11 for the .part1.rar through .part4.rar files. Proxy/network logs showing 4 uploads near the 50MB threshold spread across roughly 90 seconds rather than a tight burst.

Expected Detection

Primary KQL/SPL detection fires if the spread stays within its 24-hour join window; the 14-day standalone network-clustering hunting query is the reliable catch for cases where uploads are spread far enough apart that analysts expect the primary detection's burst assumption to miss them, validating the value of the separate hunting query.

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 LimitsT1560Archive Collected DataT1560.001Archive via UtilityT1074.001Local Data StagingT1048Exfiltration Over Alternative ProtocolT1567.002Exfiltration to Cloud StorageT1029Scheduled Transfer

Same Tactic: Exfiltration

Popular Detections