Most attacker traffic is encrypted or looks like ordinary protocol use, so the payload rarely gives it away, but its metadata often does: odd session timing, unusual byte ratios, rare TLS fingerprints or a client talking a protocol in a way no peer does. MITRE D3FEND names this countermeasure Protocol Metadata Anomaly Detection (D3-PMAD) and defines it as "Collecting network communication protocol metadata and identifying statistical outliers." It sits under the Detect tactic as a child of Network Traffic Analysis, and it analyses the Network Traffic artefact. This card explains what D3-PMAD does, which ATT&CK techniques D3FEND relates to it, which telemetry sources supply the metadata, how to prove the analytics fire, and where they fall short. It is written for detection engineers and NDR owners who already know the basics in the NDR Guide.
Key takeaways
- Metadata, not content. D3-PMAD works on packet headers and session attributes such as timing, sizes, counts, flags and handshake parameters, so it still works when the payload is encrypted.
- Outliers need a peer group. D3FEND describes grouping metadata by shared characteristics and comparing the groups, so the quality of the baseline (which hosts, which period, which protocol) decides the quality of the alerts.
- The ATT&CK links are inferred. D3FEND relates D3-PMAD to 38 ATT&CK sub-techniques with IDs, from proxies and encrypted channels to Kerberoasting and DCSync, because they all produce network traffic. That is a list of where the analytic could see activity, not a coverage claim.
- Storage is a design decision. D3FEND's own considerations warn that enterprise metadata sets are large and that storage, indexing, querying and aging must be planned before deployment.
- Verify with replayed and synthetic traffic. An anomaly model that has never fired on a known test case cannot be distinguished from one that is blind, so scheduled tests are part of the control.
D3-PMAD at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PMAD (d3f:ProtocolMetadataAnomalyDetection) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Digital artefact | Network Traffic (D3FEND relation: analyzes) |
| Sibling techniques | Includes Relay Pattern Analysis (D3-RPA), Network Traffic Community Deviation (D3-NTCD), Inbound Session Volume Analysis (D3-ISVA), Remote Terminal Session Detection (D3-RTSD) and others under Network Traffic Analysis |
| D3FEND references | Three Vectra Networks patents: detecting threats using metadata vectors, using passive cluster mapping, and using daily network traffic community outliers |
| Typical data sources | Network sensor logs (Zeek, Suricata), NetFlow and IPFIX exports, cloud flow logs, NDR platform metadata |
| Effort | Medium for flow-based outlier rules on existing telemetry; high for a tuned, multi-protocol behavioural model |
| Main limitation | Detects what is statistically unusual, not what is malicious; attackers who blend into normal patterns pass |
How it works
D3FEND describes four steps. Protocol metadata is collected and processed, in real time or after the fact. The metadata can include packet header information or session information such as the time between requests and responses. It is then grouped by shared characteristics and the groups are compared with each other. When particular metadata differs significantly from the rest, an alert flags the network event as anomalous.
The three references show the range of designs. In D3FEND's analysis of the metadata vectors patent, communications are clustered by metadata (for example counts of matching requests and responses) and a cluster that grows past a threshold raises an alarm, which can catch a bot sending the same payload repeatedly to one destination port. The passive cluster mapping patent places client activity in a feature space, including activity involving a Kerberos domain controller, and flags points that sit too far from a cluster's centre. The community outliers patent builds a connectivity graph of hosts, groups hosts that behave alike, and alerts when a host deviates from its group's baseline.
In practice, the metadata features fall into a few families:
- Volume and shape: bytes and packets in each direction, the ratio between them, session duration and the number of sessions per host pair.
- Timing: inter-arrival times, request and response gaps, regularity across sessions (the basis of beacon detection).
- Handshake and state: TCP flag sequences, connection state at close, TLS client and server parameters, SSH negotiation details.
- Protocol use: protocol on an unexpected port, unusual request methods or record types, protocol parser anomalies.
- Relationship: who talks to whom, how rare that pair is in the environment, and whether the host behaves like its peers.
Where the metadata comes from
D3-PMAD is a technique, not a product. The table lists telemetry classes with the metadata each one documents. Products and services are named as examples of each class, listed alphabetically within cloud flow logs, and are not recommendations.
| Telemetry class | Documented metadata | Notes for PMAD |
|---|---|---|
| Zeek connection logs | conn.log records duration, orig_bytes, orig_pkts, conn_state (for example SF for a normal close) and a history string of originator (upper case) and responder (lower case) packet events | Rich session shape and state; protocol logs (dns, ssl, http) add per-protocol features. See the Zeek Network Monitoring Guide |
| Suricata EVE JSON | flow events with pkts_toserver, bytes_toserver, age, state and end reason; anomaly events of type decode, stream or applayer for unexpected protocol behaviour | The anomaly event type is a ready-made protocol metadata signal; Suricata warns anomaly logging can slow processing on noisy networks. See the Suricata IDS Guide |
| NetFlow and IPFIX exports | Flow records from routers, switches and firewalls; IPFIX is specified in RFC 7011 (STD 77, September 2013, obsoletes RFC 5101) | Wide coverage at low cost; no application detail. See the NetFlow and IPFIX Flow Telemetry Guide |
| Cloud flow logs: AWS VPC Flow Logs | Default v2 fields include srcaddr, dstaddr, ports, protocol, packets, bytes, start, end and action; optional tcp-flags, pkt-srcaddr, flow-direction and traffic-path | Aggregation interval up to 10 minutes by default, 1 minute optional |
| Cloud flow logs: Azure virtual network flow logs | Flow tuples with direction, flow state (B, C, E, D), encryption status, and packets and bytes sent and received | Collected at one-minute intervals |
| Cloud flow logs: Google Cloud VPC Flow Logs | Records aggregated by 5-tuple connection, with optional metadata annotations | Aggregation interval 5 seconds by default (up to 15 minutes); primary sampling is dynamic, secondary sampling configurable |
| TLS and TCP fingerprinting | Fingerprints such as JA4 (TLS client) and related JA4+ methods for TLS server, HTTP, SSH and TCP | Only JA4 is BSD 3-Clause; the other JA4+ methods use the FoxIO License 1.1, which restricts commercial resale |
| NDR platforms | Vendor-built protocol parsers and behavioural models over the same metadata | Faster start; check which features and baselines are documented. See the NDR Buyer's Guide |
Sampling and aggregation change what an outlier looks like. A 10-minute flow record cannot show sub-minute beacon regularity, and sampled cloud flows can miss a short, low-volume session entirely. Match the analytic to the resolution of the source.
ATT&CK techniques D3FEND relates to D3-PMAD
Relationship type: inferred only. D3FEND relates these techniques to D3-PMAD because D3-PMAD analyzes Network Traffic and each technique produces or uses network traffic (D3FEND 1.6.0, checked November 2026). The page also lists parent techniques such as BITS Jobs and Data Encoding without sub-technique IDs; only the rows with IDs are shown. Every ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques (inferred via Network Traffic) | What protocol metadata can show |
|---|---|---|
| Command and control | T1071.001 Web Protocols, T1071.002 File Transfer Protocols, T1071.003 Mail Protocols, T1071.004 DNS, T1090.001 Internal Proxy, T1090.002 External Proxy, T1090.003 Multi-hop Proxy, T1090.004 Domain Fronting, T1573.001 Symmetric Cryptography, T1573.002 Asymmetric Cryptography, T1205.001 Port Knocking | Regular timing, rare TLS fingerprints, odd request and response size ratios, unusual DNS query shapes, connection sequences to closed ports |
| Exfiltration | T1048.001, T1048.002, T1048.003 Exfiltration Over Alternative Protocol sub-techniques, T1567.001 Exfiltration to Code Repository, T1567.002 Exfiltration to Cloud Storage | Outbound byte volume far above the host's peers, upload-heavy ratios to services the host never used |
| Credential access | T1557.001 Name Resolution Poisoning and SMB Relay, T1557.003 DHCP Spoofing, T1110.003 Password Spraying, T1110.004 Credential Stuffing, T1003.006 DCSync, T1558.003 Kerberoasting | Replication traffic from a non-domain-controller, bursts of authentication sessions, broadcast name resolution answered by an unexpected host |
| Lateral movement | T1021.001 Remote Desktop Protocol, T1021.004 SSH, T1550.001 Application Access Token, T1550.004 Web Session Cookie | New host pairs for remote protocols, session shape unlike the admin peer group |
| Initial access and execution | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1204.001 Malicious Link | Follow-on connections to rare destinations shortly after mail or web activity |
| Persistence, privilege escalation and stealth | T1098.001 Additional Cloud Credentials, T1546.003 Windows Management Instrumentation Event Subscription, T1546.008 Accessibility Features, T1542.005 TFTP Boot, T1218.003 CMSTP | Network side effects only, such as unexpected TFTP or remote management traffic; host telemetry is the primary source |
| Impact | T1565.002 Transmitted Data Manipulation, T1498.001 Direct Network Flood, T1498.002 Reflection Amplification, T1499.002 Service Exhaustion Flood | Volume and rate outliers, asymmetric request and response sizes typical of reflection |
Deeper detection content for the largest groups is in MITRE ATT&CK T1071 Application Layer Protocol, the T1090 Proxy Defensive Guide, MITRE ATT&CK T1573 Encrypted Channel and T1048 Exfiltration Over Alternative Protocol.
Where identity fits
Several of the inferred techniques are identity attacks seen on the wire: Kerberoasting, DCSync, password spraying and replay of application access tokens. Service accounts and workload identities make good peer groups because their traffic is repetitive. A service account that normally talks to one database and suddenly requests many Kerberos service tickets, or a CI runner token used from a new network path, is exactly the kind of outlier D3-PMAD finds. See the MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide.
Implementation steps
- Choose the vantage points. Internet egress, data centre core, domain controller segments and cloud VPCs cover most of the inferred techniques. Record what each sensor or flow source can and cannot see, including encrypted east-west traffic.
- Fix resolution and retention first. Decide aggregation intervals, sampling and retention per source, following D3FEND's warning on storage, indexing, querying and aging. Beacon and timing analytics need fine-grained records; volume analytics tolerate coarse ones.
- Normalise and enrich. Map fields from each source to one schema, and add asset role, owner and identity (user or service account) so hosts can be grouped into meaningful peer groups.
- Start with a few explainable analytics. For example: outbound byte ratio outliers per peer group, rare TLS client fingerprint per host role, new remote protocol host pairs, and replication or ticket-request volume from non-domain-controllers. Each needs a written hypothesis and the ATT&CK row it supports.
- Baseline in alert-only mode. Run for two to four weeks (an example period, not a standard), review every alert, and record benign causes such as backups, patch distribution and scanners. Exclude by documented reason, not by silencing whole subnets.
- Write triage guidance. An analyst needs the feature that was anomalous, the peer group it was compared with, and the host and identity involved, plus a pivot to full session or host telemetry.
- Roll back safely. Analytics are detective, so rollback means disabling or re-thresholding a rule. Keep versioned rule definitions so a noisy change can be reverted without losing the earlier tuning.
How to verify it works
- Replay known traffic: replay captured, approved test traffic (for example a sanctioned beacon simulation or a recorded large upload) into a sensor in a lab or on a span port and confirm the expected analytic fires.
- Authorised emulation: include network behaviours in purple team exercises, such as regular outbound callbacks, a new SSH host pair or a Kerberos service ticket burst from a test account, and record which ones produced alerts.
- Telemetry health: alert on missing or late records from each source; a flow exporter that stopped sending makes every analytic silent.
- Baseline drift review: quarterly, check that peer groups still reflect reality after re-architecture, cloud migration or new SaaS use.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Test cases detected in scheduled replay or emulation | All defined cases, each quarter | Proves the analytics see what they claim |
| Vantage points with healthy telemetry | Above 99% of expected sources reporting daily | Silent sources create blind spots |
| Share of anomaly alerts closed as benign after pilot | Falling quarter on quarter | Shows tuning and peer groups are working |
| Inferred ATT&CK rows with a written analytic and a test | Rising quarter on quarter | Turns the D3FEND list into tested coverage |
| Median time from anomaly to analyst decision | Tracked per severity | Anomaly alerts lose value if they sit unread |
Limits, bypasses and failure patterns
- Blending in: traffic sent through popular cloud services, with jittered timing and normal sizes, can sit inside the peer group's distribution. Pair D3-PMAD with reputation and destination analytics. See the Beaconing and C2 Detection Guide.
- Poisoned baselines: if an intruder is already present while the baseline is learned, their traffic becomes normal. Review the top talkers and rare destinations manually before accepting a baseline.
- Coarse records: long aggregation intervals and sampling hide short or low-volume sessions, so a low-and-slow channel may never become an outlier.
- Peer groups that are too broad: comparing a build server with laptops makes everything on the build server look anomalous, and teams then exclude it, which removes the hosts with the most valuable credentials.
- Volume without context: an alert that says only "anomalous bytes" with no identity, asset role or comparison group is closed without investigation.
- Unplanned storage growth: metadata volume grows with every new segment and cloud account, and retention is cut quietly when costs rise, which shortens the history available for investigation.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring of network communications for attacks and indicators |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation | Generating the flow and session records the analytics depend on |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Monitoring communications at external and key internal boundaries |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Networks and network services are monitored; potentially adverse events are analysed |
| MITRE D3FEND | Network Traffic Analysis, D3-PMAD | Parent and technique |
Related countermeasures
- Relay Pattern Analysis (D3-RPA): a sibling that looks for internal hosts relaying traffic to the internet. See D3-RPA Relay Pattern Analysis.
- Inbound Session Volume Analysis (D3-ISVA): volume analytics for inbound floods. See D3-ISVA Inbound Session Volume Analysis.
- Remote Terminal Session Detection (D3-RTSD): a narrower analytic for remote terminal sessions. See D3-RTSD Remote Terminal Session Detection.
- Network Traffic Community Deviation (D3-NTCD): peer group deviation, which shares one of D3-PMAD's references. See D3-NTCD Network Traffic Community Deviation. The parent Network Traffic Analysis is covered in the MITRE D3FEND Guide.
Practitioner checklist
- List every metadata source with its vantage point, aggregation interval, sampling and retention.
- Plan storage, indexing, querying and aging before turning on new sources.
- Enrich records with asset role and identity so peer groups are meaningful.
- Write each analytic with a hypothesis, a peer group and the ATT&CK rows it supports.
- Pilot in alert-only mode and document every exclusion with a reason.
- Alert on missing or late telemetry from each source.
- Run replay or emulation tests every quarter and record which analytics fired.
- Review baselines after major network or cloud changes.
- Pair anomaly analytics with reputation, signature and host telemetry rather than relying on them alone.
Standards and references
- MITRE D3FEND: Protocol Metadata Anomaly Detection (D3-PMAD)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- IETF: RFC 7011 Specification of the IP Flow Information Export (IPFIX) Protocol
- Zeek: conn.log reference
- Suricata: EVE JSON format
- AWS: VPC Flow Logs records
- Microsoft Learn: Virtual network flow logs overview
- Google Cloud: VPC Flow Logs
- FoxIO: JA4+ network fingerprinting
Related NHI Mgmt Group resources: NDR Guide · NetFlow and IPFIX Flow Telemetry Guide · Zeek Network Monitoring Guide · Beaconing and C2 Detection Guide · MITRE D3FEND Guide