Exploit delivery, command and control and data theft all change the shape of the bytes moving between a client and a server, even when the content is encrypted. MITRE D3FEND names the detection that looks for those changes Client-server Payload Profiling (D3-CSPP) and defines it as "Comparing client-server request and response payloads to a baseline profile to identify outliers." It sits under the Detect tactic as a child of Network Traffic Analysis, and its digital artefact is Network Traffic. This card covers what D3-CSPP measures, which ATT&CK techniques D3FEND relates it to, how to build it from flow and sensor data, how to prove it works and where it fails. It is written for detection engineers and network security monitoring teams who already know the basics in the NDR Guide.
Key takeaways
- It profiles shape, not content. D3FEND's description lists request and response sizes, entropy, frequency and rhythm as the features, so the technique still works on TLS traffic where payload inspection does not.
- The baseline is per server, across clients. D3FEND describes profiling many clients talking to a single server, so the useful question is "does this exchange look like the others this server handles?"
- D3FEND relates it to discovery, traffic signalling and adversary-in-the-middle. Through the shared Network Traffic artefact, D3FEND links D3-CSPP to nine ATT&CK techniques including T1046 Network Service Discovery, T1205.001 Port Knocking and T1557 Adversary-in-the-Middle.
- False positives come from people. D3FEND's own considerations warn that changing user behaviour, irregular working hours and users moving between workstations all disturb the profile.
- It needs byte counts in both directions. Flow records with separate originator and responder byte and packet counts (Zeek conn.log, Suricata flow events) are the minimum data; one-way or sampled flows weaken it badly.
D3-CSPP at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CSPP (d3f:Client-serverPayloadProfiling) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Digital artefact | Network Traffic (D3FEND relation: analyzes) |
| Features named by D3FEND | Request and response sizes, entropy, frequency, rhythm |
| D3FEND reference | Vectra Networks patent EP3293937A1, "Method and system for detecting malicious payloads" |
| Typical data sources | Network sensor flow logs, NDR platforms, cloud flow logs, web and API gateway logs |
| Effort | Medium: needs bidirectional flow data, a baseline period and tuning per server class |
| Main limitation | Catches only exchanges that look different from the server's normal; an attacker who mimics normal sizes and timing is missed |
How it works
D3FEND describes three steps: profile the request and response payloads that many clients exchange with one server, build a baseline of their characteristics, then flag outliers because they may indicate malicious payload delivery and later exploitation of the server. The Vectra patent D3FEND cites lists the inputs: client and server identity, the payloads in both directions, the amount of data transferred, the duration of the exchange and the delay between request and response. MITRE's analysis of that patent summarises the method as flow data plus unsupervised machine learning to create a baseline, with abnormal network metadata raising an alert.
In practice the features fall into four groups.
- Size: request bytes, response bytes and the ratio between them per exchange. A web application that normally answers small requests with larger pages looks very different when a client sends a large request and gets a tiny response, which is a common shape for exploit attempts and some command channels.
- Entropy: how random the payload bytes are, where the payload is visible. Encrypted or compressed data inside a protocol that normally carries plain text stands out. On TLS sessions entropy is uniformly high, so this feature only helps on clear-text protocols or after decryption.
- Frequency: how often a client talks to the server. A client that suddenly makes hundreds of requests, or a new client that has never been seen, departs from the profile.
- Rhythm: the timing pattern of requests and the delay between request and response. Regular intervals with little jitter are the classic sign of automated beaconing; an unusual server think time can show a server doing unexpected work.
The baseline is built per server or per server class (all API gateways, all file servers), not across the whole network. Comparing an exchange with what the same server normally sees is what keeps the false positive rate manageable.
ATT&CK techniques D3FEND relates to D3-CSPP
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-CSPP. Every row below is an inferred relationship derived through the shared Network Traffic artefact: D3-CSPP analyzes Network Traffic, and these ATT&CK techniques produce, may produce or may modify it (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via Network Traffic) | What payload profiling can notice |
|---|---|---|---|
| T1018 | Remote System Discovery | Technique produces Network Traffic | A client making many short exchanges with servers it has never contacted |
| T1046 | Network Service Discovery | Technique produces Network Traffic | Tiny requests with empty or error responses, far below the server's normal response size |
| T1135 | Network Share Discovery | Technique may produce Network Traffic | Bursts of small enumeration exchanges against file servers from a client that normally reads documents |
| T1205 | Traffic Signaling | Technique produces Network Traffic | Packets with unusual sizes or content that do not match the service on the port |
| T1205.001 | Port Knocking | Technique produces Network Traffic | A short, fixed sequence of connection attempts with no payload before a real session opens |
| T1218.003 | CMSTP | Technique may produce Network Traffic | An unexpected download exchange from a host that rarely fetches content from that server |
| T1550.001 | Application Access Token | Technique may produce Network Traffic | API calls with request sizes, rates or timing unlike the application's normal clients |
| T1557 | Adversary-in-the-Middle | Technique produces Network Traffic | Changed response latency or sizes when traffic is relayed through an intermediary |
| T1565.002 | Transmitted Data Manipulation | Technique may modify Network Traffic | Response sizes that drift from the server's profile for the same request types |
Through the same artefact D3FEND also infers ATT&CK for ICS relations, including T0830 Adversary-in-the-Middle, T0848 Rogue Master, T0885 Commonly Used Port and T0888 Remote System Information Discovery. The D3FEND site also shows a longer experimental list derived from sub-artefacts of Network Traffic, including T1071.001 Web Protocols, T1071.004 DNS, T1573 Encrypted Channel sub-techniques, T1048 exfiltration sub-techniques and T1110.003 Password Spraying. Treat all of these as a hint about where to look, not a coverage claim. For the discovery techniques, the deeper defensive guidance is in MITRE ATT&CK T1046 Network Service Discovery and T1018 Remote System Discovery; for interception, see MITRE ATT&CK T1557 Adversary-in-the-Middle and for signalling MITRE ATT&CK T1205 Traffic Signaling.
Where it is implemented
Tools are listed alphabetically within each row and as examples of a class, not recommendations.
| Implementation class | Data used | Fields that carry the profile | Fits when |
|---|---|---|---|
| Open-source network sensors (Suricata, Zeek) plus a SIEM or data platform | Bidirectional flow records from a tap or SPAN port | Zeek conn.log: orig_bytes, resp_bytes, orig_pkts, resp_pkts, duration, history. Suricata EVE flow events: bytes_toserver, bytes_toclient, pkts_toserver, pkts_toclient, age | You run your own sensors and can write baseline queries |
| Beacon and long-connection analytics on sensor logs | Zeek logs | Connection timing and size patterns; RITA, for example, reads Zeek logs and reports beaconing, long connections and DNS tunnelling | You want the rhythm feature without building it yourself |
| Network detection and response platforms | Packet capture and flow metadata, often with TLS fingerprints | Vendor-specific models of per-host and per-server behaviour | Large estates that want maintained models; see the NDR Buyer's Guide |
| Cloud flow logs | Provider flow records | For AWS VPC Flow Logs, the default record includes packets, bytes, start and end per flow; no payload | Workloads in cloud networks where you cannot place a sensor |
| Application and API gateways | Request logs | Request and response size, latency and status per client identity | The server is an API and you want profiles per client credential |
Endpoint telemetry helps attribution: Sysmon Event ID 3 records TCP and UDP connections with the originating process (it is off by default and needs a NetworkConnect filter), so an outlier flow can be tied to the process that made it. Sensor deployment and log handling are covered in the Zeek Network Monitoring Guide and Suricata IDS Guide.
Where identity fits
API traffic is mostly machine to machine. When an API gateway logs the client identity (an OAuth client ID, an API key ID or a workload identity), payload profiles can be built per non-human identity instead of per IP address. A stolen token used from attacker tooling usually calls the API with different request sizes, rates and timing from the workload that owns it, which is the practical form of the T1550.001 relationship above. The D3-WSAA Web Session Activity Analysis card covers the session side of the same idea.
Implementation steps
- Pick the servers worth profiling. Start with internet-facing web and API servers, domain controllers and file servers. Group them into classes so each class shares a baseline.
- Confirm the data. Check that sensors see both directions of traffic for those servers and that flow records carry separate originator and responder byte and packet counts. Asymmetric routing, sampling and load balancer hairpins break the profile.
- Build the baseline. Collect at least several weeks of flows (an example period, not a standard) so weekly cycles are included. For each server class, record distributions of request bytes, response bytes, response to request ratio, session duration and requests per client per hour.
- Define outlier rules. Start with simple statistics such as exchanges above a high percentile of request size with a response below a low percentile, or new clients with high request rates. Add the rhythm feature (regular intervals with low jitter) for outbound sessions.
- Run in alert-only mode. Send outliers to a review queue for two to four weeks. Tune out known causes such as backups, software updates and monitoring probes by adding them to the baseline, not by raising thresholds for everyone.
- Enrich and route. Join outliers with process data from the endpoint, the client identity from the gateway and threat intelligence on the remote address before an analyst sees them.
- Roll back cleanly. Keep each rule versioned. If a rule floods the queue, disable that rule only and keep collecting data so the baseline stays current.
How to verify it works
- Replay test: in an authorised test, send a scripted burst of small requests to a profiled server from an approved test host (a stand-in for discovery) and confirm the outlier rule fires with the right server and client.
- Beacon test: run a benign scheduled job from a test host that calls a test server at a fixed interval and confirm the rhythm analytic flags it.
- Data completeness check: weekly, compare the count of flows for each profiled server with the previous week; a sudden drop usually means a sensor or span port problem, not a quiet network.
- Baseline drift review: after application releases, check whether the profile changed and rebaseline if the change is legitimate.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Profiled servers with bidirectional flow data | 100% of the chosen classes | One-way data makes ratios meaningless |
| Outlier alerts per profiled server per week after tuning | Low single digits | Shows the baseline fits real behaviour |
| Share of outlier alerts closed as true or useful findings | Tracked and rising | Precision of the analytic |
| Synthetic replay and beacon tests detected | 100% | End-to-end proof the rules and data path work |
| Days since last rebaseline for each server class | Within the release cycle | Stale baselines create noise |
Limits, bypasses and failure patterns
- Mimicry: an attacker who shapes requests and responses to match normal sizes and adds jitter to timing can stay inside the profile. Payload profiling raises the cost of hiding but does not remove it.
- Encryption removes entropy as a feature: on TLS every payload looks random, so only size, count and timing remain unless traffic is decrypted at a gateway.
- People change: D3FEND lists changing behaviour, inconsistent working hours and users logging in from different workstations as false positive sources. Profiles for servers used by people need wider bands than server to server profiles.
- Cost: D3FEND notes that collecting network activity to generate metrics is computationally intensive. Profiling every server is rarely affordable; choose the classes that matter.
- Blind spots in the sensor layout: east to west traffic inside a hypervisor or a cloud VPC never crosses a physical sensor, so the profile is built only on what the sensor sees.
- Poisoned baselines: if an intruder is already active during the baseline period, their traffic becomes normal. Review the largest and most regular flows in the baseline before trusting it.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring the system to detect attacks and indicators of potential attacks |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | Review of the flow records the profile is built from |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Monitoring communications at managed interfaces, where sensors usually sit |
| 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-CSPP | Parent and technique |
Related countermeasures
- Per Host Download-Upload Ratio Analysis (D3-PHDURA): the same size idea applied per host rather than per server. See D3-PHDURA.
- Network Traffic Community Deviation (D3-NTCD): compares a host with its peer group. See D3-NTCD.
- Protocol Metadata Anomaly Detection (D3-PMAD): profiles protocol fields rather than payload shape. See D3-PMAD.
- Inbound Session Volume Analysis (D3-ISVA): watches inbound volume for flooding. See D3-ISVA Inbound Session Volume Analysis.
- Connection Attempt Analysis (D3-CAA): the failed-connection view of discovery. See D3-CAA.
Practitioner checklist
- Choose server classes to profile and record why each was chosen.
- Confirm sensors see both directions and flow records keep separate originator and responder counts.
- Baseline long enough to include weekly cycles and review the baseline for existing intrusions.
- Profile size, ratio, frequency and timing; use entropy only where payloads are visible.
- Run new rules in alert-only mode and tune by adding known jobs to the baseline.
- Tie outlier flows to processes (Sysmon Event ID 3 or EDR) and to client identities at the gateway.
- Run scheduled replay and beacon tests and record the results.
- Rebaseline after major releases and track flow volume per server for sensor health.
Standards and references
- MITRE D3FEND: Client-server Payload Profiling (D3-CSPP)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-4)
- Zeek: conn.log documentation
- Suricata: EVE JSON format
- Active Countermeasures: RITA project
- Microsoft Learn: Sysmon
- AWS: VPC Flow Logs records
Related NHI Mgmt Group resources: NDR Guide · Zeek Network Monitoring Guide · MITRE D3FEND Guide · MITRE ATT&CK T1046 Network Service Discovery