--- name: detect-data-exfiltration description: "Detection and response for data exfiltration over DNS and HTTPS/web channels, and for egress volume anomalies (MITRE ATT&CK T1041, T1048, T1048.003, T1071.004, T1567). Built from the October 2026 compromised-LiteLLM incident, where a stealer POSTed credentials to a lookalike domain. Ships the sigma-pack proxy rule for the known lookalike-domain exfil plus baselined hunts for DNS tunnelling and download/upload-ratio anomalies, keyed off web proxy logs, DNS telemetry (Sysmon Event ID 22, Windows DNS Server Event ID 256, Zeek dns.log), and firewall or NetFlow byte counts, with tuning, false-positive notes, and D3FEND countermeasures. Use when investigating an unexpected outbound connection or credential-stealer beacon, writing DNS or HTTPS exfiltration detections, hunting for data sent to a lookalike domain or over odd protocols, triaging an egress volume spike, or hardening egress after an AI-gateway or supply-chain compromise." --- # Data Exfiltration - Detection and Response Exfiltration is the stage where stolen data actually leaves the estate, and attackers reach for the channels you already allow outbound: HTTPS to the open web and DNS to a resolver. Both are open almost everywhere, both carry encrypted or encoded payloads happily, and both blend into enormous volumes of legitimate traffic. This skill is defensive: it explains the technique only as far as detection and mitigation require, ships no stealer, tunnelling, or staging tooling, and treats the attacker's transport only as something to catch in your logs. ## TL;DR for defenders Turn on three egress log sources and keep them: **web/proxy access logs**, **DNS query logs**, and **firewall or NetFlow byte counts**. Then watch for three things. First, POSTs to a **known lookalike or never-before-seen domain** - the high-precision case, and the one the Sigma rule below pins to a named indicator. Second, **DNS queries with abnormal cardinality or label length** under a single parent domain, the tunnelling signal. Third, a **host whose outbound byte volume or upload-to-download ratio jumps above its own baseline**. The domain rule is a near-binary alarm; the DNS and volume analytics are hunts you baseline before you page on them. None is a silver bullet alone, so layer all three. ## Why it still matters in 2026 On October 21, 2026 a compromised **LiteLLM 1.107.0** release shipped a credential stealer that collected cloud, AI-provider, browser, SSH and GPG credentials plus rows from the proxy's `LiteLLM_CredentialsTable`, encrypted the bundle, and **POSTed it to `www.litellm.dev/healthcheck`**. `litellm.dev` is an attacker-controlled lookalike; the project's real domains are `litellm.ai` and `docs.litellm.ai`, so any request to it from your estate is worth a ticket. That incident is the worked example for this skill, and it sits one move downstream of the gateway RCE covered in the [LiteLLM command-injection writeup](https://umbrasec.dev/research/detecting-litellm-command-injection.html): an AI gateway holds provider API keys by design, so once an attacker lands on it - through CVE-2026-42271, a poisoned dependency, or a trojanised release - exfiltration of those secrets is the obvious next step. HTTPS and DNS are allowed outbound almost everywhere, which is exactly why exfil hides in them, and why the detection here keys off the destination and the shape of the traffic rather than the payload you cannot read. ## Log sources required Collect all three egress sources if you can; they sit at different points of the exfil path and cover each other's blind spots. - **Web / proxy access logs** from your forward proxy, TLS-inspecting gateway, CASB, reverse proxy, or egress firewall URL log. This is where the lookalike-domain rule runs. Capture method, host, full URI, and byte counts. - **DNS query logs** from the resolver or endpoint: **Windows Sysmon Event ID 22** (`DnsQuery`), **Windows DNS Server** analytical/audit logs (**Event ID 256** query received, **257** response), **Zeek `dns.log`**, or your recursive resolver's query log. This carries the tunnelling signal. - **Firewall / NetFlow / VPC flow logs** for volume: outbound byte counts per host and destination. **Zeek `conn.log`** (`orig_bytes`, `resp_bytes`) gives the same ratio on the wire. - **EDR / host process and network telemetry** on high-value hosts such as the AI gateway, so a stealer process and the connection it opens are tied to a parent binary and a user. Fields you will lean on: | Field | Source | Why it matters | |---|---|---| | `cs-host` / `Host` | proxy / web | The destination domain. Lookalike and newly registered domains are the exfil tell. | | `c-uri` / `cs-uri-stem` | proxy / web | Full path. A POST to `/healthcheck` or `/collect` on an odd host is suspicious. | | `cs-method`, `cs-bytes` / `sc-bytes` | proxy / web | A large `POST` body to an external host is the upload itself. | | `QueryName` | Sysmon 22 / DNS 256 / Zeek | Long, high-entropy, or high-cardinality subdomains under one parent = tunnelling. | | `qtype_name` / `QTYPE` | Zeek dns.log / DNS Server 256 (Sysmon 22 has no query-type field) | A spike in `TXT`, `NULL`, or `CNAME` lookups is a classic DNS-exfil carrier. | | `orig_bytes` : `resp_bytes` | Zeek `conn.log` / NetFlow | Upload far exceeding download, to one external peer, is the volume anomaly. | ## Detection Layered from highest precision to broadest, the same philosophy as every UMBRASEC writeup. The high-precision rule ships inline below; the DNS and volume analytics live under **Threat hunt**, because they must be baselined to your environment before they are safe to page on. The canonical copy of the rule lives in the UMBRASEC [sigma-pack](https://umbrasec.dev/tools/sigma-pack/). ### 1. Exfiltration to the known lookalike domain (high precision) The LiteLLM stealer's destination is a fixed, attacker-controlled lookalike of the project's real domain. Any request to it from your estate is exfiltration or, at best, an analyst poking the indicator. This is the near-binary alarm: the signal is the domain itself, not a behaviour, so it carries almost no false positives and should be retired the moment the domain changes hands. ```yaml # litellm-stealer-exfil.yml (canonical copy: https://umbrasec.dev/tools/sigma-pack/) title: LiteLLM 1.107.0 Stealer Exfiltration to Lookalike Domain id: 6f6f10d8-c46a-46dc-89ad-c5b9a800ee72 status: experimental description: > The credential stealer shipped in the compromised LiteLLM 1.107.0 release POSTs its encrypted bundle (cloud, AI-provider, browser, SSH and GPG credentials, plus rows from the proxy's LiteLLM_CredentialsTable) to www.litellm.dev/healthcheck. litellm.dev is an attacker-controlled lookalike; the project's real domains are litellm.ai and docs.litellm.ai, so any request to it from your estate is worth a ticket. Where your proxy retains request headers, the hardcoded "X-Token: XWiA8gZNa7NcX2XRoAEb" header and an Internet Explorer 7 user agent on a POST from a Python host confirm it. The second stage read a domain from a GitHub dead drop (letters9813/pythonclient-test) and would have fetched http:///codepy; the repo is gone and the drop was never populated beyond test values, so it is not matched here. Hosts logged with a port or with a trailing dot are matched. The URI selection covers proxies that only log the full URL. references: - https://docs.litellm.ai/blog/security-incident-oct-21-2026 - https://www.wiz.io/blog/litellm-compromised-steals-credentials - https://litellm.ai author: UMBRASEC date: 2026-10-23 modified: 2026-10-25 tags: - attack.exfiltration - attack.t1041 logsource: category: proxy detection: selection_host: cs-host: - 'litellm.dev' - 'litellm.dev.' selection_subdomain: cs-host|endswith: - '.litellm.dev' - '.litellm.dev.' selection_hostport: cs-host|startswith: - 'litellm.dev:' - 'litellm.dev.:' selection_subdomain_port: cs-host|contains: - '.litellm.dev:' - '.litellm.dev.:' selection_uri: c-uri|contains: - '//litellm.dev/' - '//litellm.dev:' - '//litellm.dev./' - '//litellm.dev.:' - '//www.litellm.dev/' - '//www.litellm.dev:' - '//www.litellm.dev./' - '//www.litellm.dev.:' selection_uri_bare: c-uri|endswith: - '//litellm.dev' - '//litellm.dev.' - '//www.litellm.dev' - '//www.litellm.dev.' condition: 1 of selection_* falsepositives: - Analysts or sandboxes deliberately resolving or fetching the indicator - If the domain ever changes hands, retire the rule. The signal is the domain, not behaviour level: high ``` ## Tuning and false positives - **Rule 1 (lookalike domain).** This fires on a fixed indicator, so the only benign cause is an analyst or sandbox deliberately resolving or fetching it, which is still worth a glance. The host selections match `cs-host` with or without a port or trailing dot; the `selection_uri` branch covers proxies that only record the full URL. If the domain is ever sinkholed or changes hands, retire the rule: the signal is the domain, not the behaviour. - **DNS hunt.** CDNs, endpoint-protection telemetry, DNS-based reputation lookups, and DoH bootstrap domains all produce long or high-cardinality queries legitimately. Baseline average query length and per-parent subdomain cardinality for a week, allowlist your top legitimate high-cardinality parents (large cloud and security vendors), then set thresholds above your noisiest benign talker. - **Volume hunt.** Backups, cloud sync (OneDrive, Dropbox, S3), software updates, and video calls all push large uploads. Allowlist sanctioned cloud-storage and backup destinations by domain or ASN, and alert on volume to **new or unsanctioned** destinations rather than on raw bytes alone. ## Threat hunt The lookalike rule catches a known indicator; these two hunts catch the technique when the destination is unknown or the attacker goes low and slow. Treat both as analytics to baseline in your SIEM, not as drop-in pager rules, and tune the thresholds to your own traffic. **A. DNS tunnelling (cardinality, length, record type).** Exfil over DNS encodes data into subdomain labels under one attacker-controlled parent, producing many distinct long labels and often a burst of `TXT` or `NULL` lookups. Over Sysmon Event ID 22 or Zeek `dns.log`, grouped by registered parent domain and host: ``` # pseudo-SPL - adapt field names to your schema; baseline before alerting EventCode=22 OR source="zeek_dns" | eval qlen=len(QueryName), parent= | stats dc(QueryName) as distinct_labels avg(qlen) as avg_len count(eval(qtype_name IN ("TXT","NULL"))) as rare_type_count # record type from Zeek dns.log or DNS Server 256; Sysmon 22 does not log it by parent, Computer | where distinct_labels > 100 OR avg_len > 50 OR rare_type_count > 50 ``` Rank hits by a parent domain that is newly registered, resolves to a single foreign IP, or has no legitimate business use. One host sending hundreds of unique long labels to a domain nobody else queries is the finding. **B. Egress volume and upload-ratio anomaly.** Compare each host's outbound bytes to its own recent baseline and flag the hosts whose upload dwarfs their download or spikes above normal, concentrated on one external peer. Over NetFlow, firewall logs, or Zeek `conn.log`: ``` # pseudo-SPL - bucket per host/destination/day, compare to a 30-day baseline | stats sum(orig_bytes) as out_bytes sum(resp_bytes) as in_bytes by src_ip dest_host _time_day | eventstats avg(out_bytes) as mean stdev(out_bytes) as sd by src_ip | eval ratio = out_bytes / (in_bytes + 1) | where out_bytes > (mean + 3*sd) OR (ratio > 10 AND out_bytes > 50000000) ``` For the slowest adversary who stays under every threshold, pivot on **destination novelty** instead of volume: correlate newly registered domains, direct-to-IP connections, and unusual TLS client fingerprints (JA3/JA4) against the host that holds data worth taking, such as the AI gateway that stores provider keys. ## Mitigation Detection buys time; these shrink the channel the data leaves by. Mappings below reuse the control codes from the UMBRASEC [detection and response guide](https://umbrasec.dev/guide/detection-and-response.html); a cell is "-" where no single framework control maps cleanly. The matching D3FEND countermeasure is named in the control text. | Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 | |---|---|---|---|---| | Turn on and retain egress logging (proxy, DNS, firewall allow/deny) | The prerequisite for every rule here; without it exfil is invisible (D3-NTA) | ML2/ML3 event-log requirements | A.8.15 Logging | DE.CM Continuous monitoring | | Monitor outbound for anomalies (new or lookalike domains, volume, DNS cardinality) | Someone or something actually watches the egress telemetry (D3-DNSTA, D3-NTA) | (Beyond E8 - detection gap) | A.8.16 Monitoring activities | DE.AE Adverse events; DE.CM | | EDR on the gateway and high-value hosts | Ties the stealer process to the connection it opens, catching exfil at the host | (Beyond E8 - detection gap) | A.8.7 Malware; A.8.16 Monitoring | DE.CM; DE.AE | | Egress filtering: allowlist outbound DNS and web destinations, block direct-to-IP and newly registered domains | Removes the open channel the attacker relies on (D3-OTF) | - | - | - | | Rotate exposed secrets and run IR on a confirmed hit | Contain and recover once data has left; assume provider keys are disclosed | (Beyond E8) | A.5.24-5.26 IR; A.5.28 Evidence | RS.MA; RC.RP Recovery | ## Honest limitations TLS inspection is what lets the proxy see the method, URI path, and headers (the POST to /healthcheck, the X-Token header); without it the host-based selections still work off the CONNECT host or SNI, but where you cannot break TLS you are limited to SNI and the destination IP, and an attacker using domain fronting or a shared CDN can hide the real host. The DNS hunt misses exfil carried over DoH or DoT unless you force internal resolvers and block external ones, and it is noisy near large cloud and security vendors until baselined. The volume hunt is blind to the genuinely low-and-slow actor who trickles data under the threshold, which is why destination-novelty and host-based detection matter alongside it. Rule 1 pins a single campaign's indicator and ages out the moment the domain moves, so it is a tripwire, not a strategy. Layer all three signals, baseline every threshold in report-only mode first, and pair detection with egress filtering so there is less channel to watch. ## ATT&CK and references - MITRE ATT&CK: [T1041 Exfiltration Over C2 Channel](https://attack.mitre.org/techniques/T1041/) (the canonical rule's mapping); [T1048 Exfiltration Over Alternative Protocol](https://attack.mitre.org/techniques/T1048/) and [T1048.003](https://attack.mitre.org/techniques/T1048/003/); [T1071.004 Application Layer Protocol: DNS](https://attack.mitre.org/techniques/T1071/004/); [T1567 Exfiltration Over Web Service](https://attack.mitre.org/techniques/T1567/). - MITRE D3FEND: D3-OTF Outbound Traffic Filtering; D3-DNSTA DNS Traffic Analysis; D3-NTA Network Traffic Analysis. - UMBRASEC writeup: [Detecting the LiteLLM Command Injection (CVE-2026-42271)](https://umbrasec.dev/research/detecting-litellm-command-injection.html) - the gateway-compromise context one move upstream of this exfil. - UMBRASEC [sigma-pack](https://umbrasec.dev/tools/sigma-pack/) - canonical copy of the rule above. - LiteLLM security incident, October 21, 2026 (docs.litellm.ai/blog/security-incident-oct-21-2026); Wiz research on the compromised release (wiz.io/blog/litellm-compromised-steals-credentials). **Scope note.** This is a defensive skill. It explains data exfiltration only to the depth needed to detect and mitigate it, keys its detections off destinations and traffic shape rather than any payload technique, and deliberately ships no stealer, tunnelling, or staging tooling. UMBRASEC publishes defense, not offense.