A workstation that normally pulls far more data than it sends, and suddenly starts pushing gigabytes outward, is one of the few exfiltration signals that survives encryption. MITRE D3FEND names this countermeasure Per Host Download-Upload Ratio Analysis (D3-PHDURA) and defines it as "Detecting anomalies that indicate malicious activity by comparing the amount of data downloaded versus data uploaded by a host." It sits under the Detect tactic as a child of Network Traffic Analysis, and its digital artefact is Network Traffic. This card explains how the ratio is built, which ATT&CK techniques D3FEND relates it to, where it can be implemented with flow and connection logs, how to verify it fires, and where it breaks. It is written for detection engineers and network security analysts who already run some form of flow collection.
Key takeaways
- The signal is direction, not content. D3-PHDURA compares bytes sent with bytes received per host over a time window, so it works on metadata from flow logs and connection logs and does not need decrypted payloads.
- Baselines are per host. D3FEND's description builds the pull versus push baseline for a given host over a chosen period, for example three hours, one day or one week, and alerts on deviations over a threshold.
- D3FEND's direct mappings are mostly discovery and traffic manipulation. Through the Network Traffic artefact the ontology relates it to nine Enterprise techniques, including T1018, T1046, T1135, T1205 and T1557; the D3FEND site adds exfiltration techniques as wider inferred relations.
- Server roles invert the ratio. File servers, web servers, backup agents and build runners are upload-heavy by design, so role-aware baselines or exclusions decide whether the analytic is usable.
- Slow and spread-out transfers evade it. Low-and-slow exfiltration, transfers split across many hosts and uploads to sanctioned cloud services all blend into normal ratios.
D3-PHDURA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PHDURA (d3f:PerHostDownload-UploadRatioAnalysis) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Digital artefact | Network Traffic (D3FEND relation: analyzes Network Traffic) |
| Input data | Per-flow byte counts with direction: NetFlow or IPFIX, cloud flow logs, Zeek conn.log, firewall session logs |
| Output | An alert when a host's upload to download ratio, or upload volume, departs from its own baseline |
| D3FEND reference | Vectra Networks patent US20160191563A1, on detecting insider threats from data exchange patterns in network metadata |
| Effort | Low if flow data is already in a SIEM or data lake; medium for role-aware baselines across a large estate |
How it works
D3FEND's knowledge base article describes three steps: aggregate pull and push volumes from traffic metadata, build a baseline per host over a set period, and alert on anomalies above a threshold. Its reference patent from Vectra Networks adds two design points. First, the baseline can be kept per host and per resource the host talks to, not only as one overall ratio. Second, alerting can be filtered to raise alarms only when external hosts receive large transfers, which cuts noise from internal backup and replication traffic.
- Collect: per-connection byte counts in each direction, tagged with the internal host. In Zeek, the conn.log fields orig_bytes and resp_bytes record payload bytes sent by the originator and responder, and local_orig and local_resp mark whether each side is inside Site::local_nets. In AWS VPC Flow Logs, the bytes field gives bytes per flow and flow-direction (ingress or egress, from log format version 5) gives direction relative to the interface.
- Aggregate: for each host and window, sum bytes uploaded and bytes downloaded. Keep the ratio and the absolute upload volume, because a ratio alone over-reacts on hosts with very little traffic.
- Baseline: compute a per-host typical range, for example a rolling median and percentile band over 14 to 30 days (an NHI Mgmt Group example, not a D3FEND value). Group hosts by role so new hosts inherit a sensible starting baseline.
- Alert: fire when both the ratio and the upload volume exceed the band, and enrich with destination, destination reputation, process (from EDR, where available) and user.
D3FEND's considerations warn that full packet capture for this purpose needs large storage and heavy compute, and that the window should follow the threat model. Flow records are usually enough: the analytic needs byte counts, not payloads.
ATT&CK techniques D3FEND relates to D3-PHDURA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-PHDURA. The rows below come from the D3FEND ontology (version 1.6.0, checked November 2026): D3-PHDURA analyzes Network Traffic, and these ATT&CK techniques produce, may produce or may modify Network Traffic. D3FEND describes such relations as inferred and experimental. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Relation to Network Traffic | What a ratio analytic can realistically see |
|---|---|---|---|
| T1018 | Remote System Discovery | produces | Weak signal: sweeps create many small flows; connection counts suit it better than byte ratios |
| T1046 | Network Service Discovery | produces | Weak signal: port scans move few bytes; pair with connection attempt analysis |
| T1135 | Network Share Discovery | may produce | Weak on its own; the follow-on bulk copy from shares changes the ratio of the collecting host |
| T1205 | Traffic Signaling | produces | Very low volume; not a realistic ratio detection |
| T1205.001 | Port Knocking | produces | Very low volume; not a realistic ratio detection |
| T1218.003 | CMSTP | may produce | Only the network side effects, such as a payload download or later upload |
| T1550.001 | Application Access Token | may produce | Bulk API pulls with a stolen token show on the cloud side, not on the host ratio |
| T1557 | Adversary-in-the-Middle | produces | A host relaying traffic for others can show an unusual symmetric ratio |
| T1565.002 | Transmitted Data Manipulation | may modify | Little or no volume change; not a realistic ratio detection |
The ontology also links Network Traffic to ATT&CK for ICS techniques: T0830 Adversary-in-the-Middle, T0840 Network Connection Enumeration, T0842 Network Sniffing, T0846 Remote System Discovery, T0848 Rogue Master, T0885 Commonly Used Port, T0888 Remote System Information Discovery, T0894 System Binary Proxy Execution and T0895 Autorun Image. In OT networks, where traffic is highly regular, per-host ratio baselines are often more stable than in IT.
The D3FEND website lists a wider set through sub-artefacts of Network Traffic, including Exfiltration Over Alternative Protocol sub-techniques (T1048.001, T1048.002, T1048.003) and Exfiltration Over Web Service sub-techniques (T1567.001 to code repositories, T1567.002 to cloud storage). That is where the ratio analytic earns its keep, and it matches the insider data transfer focus of D3FEND's reference patent. Our view at NHI Mgmt Group: treat the discovery rows as a placement hint and build the analytic for outbound bulk transfer. See the T1048 Exfiltration Over Alternative Protocol and T1567 Exfiltration Over Web Service pages for those techniques.
Where it is implemented
| Implementation class | Data used | Strengths | Watch for |
|---|---|---|---|
| SIEM or data lake analytics on flow data | NetFlow or IPFIX from routers and firewalls; firewall session logs with sent and received byte counts | Uses data most networks already export; full control of windows and thresholds | Sampled NetFlow under-counts small flows; NAT hides the internal host unless logs are taken inside the NAT |
| Network sensor with connection logs | Zeek conn.log orig_bytes, resp_bytes, local_orig, local_resp | Per-connection direction is explicit; easy to join with DNS and TLS logs for destination context | Zeek notes orig_bytes for TCP comes from sequence numbers and can be inaccurate for large connections; check missed_bytes for packet loss |
| Cloud flow logs | For example AWS VPC Flow Logs bytes and flow-direction fields | Covers workloads with no on-premises sensor | Aggregation interval is 10 minutes by default (1 minute optional, and always 1 minute or less on Nitro instances), which sets the shortest useful window |
| Network detection and response (NDR) products | Vendor sensors and models | Built-in per-host baselines and role learning | Model behaviour is vendor specific; confirm what volume thresholds and windows it uses |
| Endpoint telemetry | Per-process network bytes where the endpoint agent records them | Ties the upload to a process and user | Coverage only where the agent runs; not all agents record byte counts |
The parent technique, Network Traffic Analysis, covers the collection architecture for all of these. Per-user rather than per-host transfer analytics are covered in D3-UDTA User Data Transfer Analysis, and inbound volume in D3-ISVA Inbound Session Volume Analysis.
Implementation steps
- Confirm the data. Pick one source per network zone that records bytes in both directions and the internal host address before NAT. Check that it covers egress points: internet gateways, VPN concentrators, cloud egress and proxies.
- Define host roles. Tag hosts as user endpoint, server, backup, build or CI runner, proxy, and so on, from the asset inventory. Ratio baselines are only meaningful within a role.
- Start with outbound to external. Follow the reference patent's filter: first alert only when the destination is outside the organisation (local_resp false in Zeek, or a destination outside your address ranges). Add east-west transfers later for staging detection.
- Run in shadow mode. Compute baselines for two to four weeks without alerting. Review the top deviators each week and record why each was benign.
- Tune by fixing the cause. Exclude known upload-heavy destinations by name, such as the sanctioned backup target, rather than raising thresholds globally. Keep the exclusion list owned and reviewed.
- Enable alerting with enrichment. Each alert should carry host, user, top destinations by bytes, destination reputation and, where EDR is present, the sending process.
- Write the triage path. Confirm the destination, the process and the data. If it is unexplained, contain the host and follow the Data Exfiltration Playbook.
- Roll back cleanly. If the analytic floods the queue, return it to shadow mode rather than deleting it, so the baseline history is kept.
Where identity fits
Upload-heavy hosts are often run by non-human identities: backup agents, sync clients, CI runners and integration servers holding API keys. A stolen key used from one of those hosts looks like normal upload behaviour. Record which service account or workload identity owns each upload-heavy host, so that an alert can be checked against that identity's usual destinations.
How to verify it works
- Synthetic transfer test: from an approved test endpoint, upload a known volume (for example several hundred megabytes) to an approved external test destination at a time when that host is normally quiet. Confirm the alert arrives with the correct host, destination and byte count.
- Window test: repeat the test spread over a full day in small chunks. Record whether the analytic catches it; this tells you your real low-and-slow threshold.
- Data path check: confirm daily that each flow source is still sending. A silent exporter disables the analytic for a whole zone.
- Emulation: include a staged exfiltration step in authorised adversary emulation and record time to alert.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Egress points with flow data feeding the analytic | 100% | An unmonitored egress path is an open exfiltration route |
| Synthetic transfer tests detected | 100% of bulk tests | Proves the end-to-end path works |
| Smallest detected spread-out transfer | Tracked and falling | Shows the real sensitivity floor |
| Alerts closed as benign with a recorded cause | Falling month on month after tuning | Measures baseline quality |
| Hosts with a role tag | Over 95% | Role-aware baselines depend on it |
Limits, bypasses and failure patterns
- Low and slow: transfers throttled to fit inside the host's normal band, or spread across days, stay under any ratio threshold. Pair with destination-based analytics.
- Sanctioned cloud destinations: uploads to the organisation's own cloud storage or code hosting tenant, or a lookalike tenant on the same service, carry the same destination addresses as business traffic.
- Distributed exfiltration: data staged on many hosts and sent in small amounts from each keeps every host's ratio normal.
- Blind spots from NAT and proxies: flow logs taken outside NAT or at a proxy show the proxy as the uploader, not the host. Collect inside the NAT, or join proxy logs.
- Thresholds set once: host behaviour drifts with new software and working patterns; baselines that are not rolling go stale.
- Server roles left in the default model: backup, replication and web servers generate permanent false positives that train analysts to ignore the rule.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring the system to detect attacks and unauthorised connections |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Monitoring and control at external boundaries, where egress volume is measured |
| NIST CSF 2.0 | DE.CM-01 | Networks and network services are monitored to find potentially adverse events |
| MITRE D3FEND | Network Traffic Analysis, D3-PHDURA | Parent and technique |
Related countermeasures
- D3-NTCD Network Traffic Community Deviation: compares a host with its peer group rather than with its own history.
- D3-UDTA User Data Transfer Analysis: the same volume idea keyed on the user.
- D3-CAA Connection Attempt Analysis: a better fit than byte ratios for the discovery techniques in the table above.
- MITRE D3FEND Guide: the framework overview.
Practitioner checklist
- Confirm every egress point has flow or connection data with bytes in both directions.
- Collect inside NAT, or join proxy logs, so the internal host is known.
- Tag hosts by role from the asset inventory before baselining.
- Alert on ratio and absolute upload volume together, not ratio alone.
- Start with external destinations, then extend to east-west staging.
- Keep an owned, reviewed list of sanctioned upload destinations.
- Run a synthetic bulk transfer test monthly and a spread-out test quarterly.
- Record which non-human identity owns each upload-heavy host.
Standards and references
- MITRE D3FEND: Per Host Download-Upload Ratio Analysis (D3-PHDURA)
- Vectra Networks: System for detecting threats using scenario-based tracking of internal and external network traffic (US20160191563A1)
- MITRE ATT&CK: T1048 Exfiltration Over Alternative Protocol
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-4, SC-7)
- Zeek: conn.log field definitions (base/protocols/conn/main.zeek)
- AWS: VPC Flow Logs records
Related NHI Mgmt Group resources: Data Exfiltration Guide · ATT&CK Exfiltration Tactic · D3-UDTA User Data Transfer Analysis · MITRE D3FEND Guide