Remote procedure calls carry much of the lateral movement in a Windows estate, yet most teams log the connection and not the call. D3-RTA RPC Traffic Analysis is the MITRE D3FEND countermeasure for that gap: D3FEND defines it as "Monitoring the activity of remote procedure calls in communication traffic to establish standard protocol operations and potential attacker activities", places it in the Detect tactic under Network Traffic Analysis, and backs it with a set of MITRE Cyber Analytics Repository (CAR) analytics. This card explains what the technique looks for, the telemetry that makes it possible, how to verify detection coverage and where it falls short. It is written for detection engineers, network security monitoring teams and threat hunters.
Key takeaways
- D3-RTA watches what RPC is used for. D3FEND's analytics look for processes launched or scheduled remotely, system configuration changed remotely and unauthorised file reads.
- Decoding the call is what adds value. Port 135 and high-port flows show that RPC happened; the interface, named pipe and operation show whether it was a remote service creation, a scheduled task or WMI.
- Peer-to-peer RPC between workstations is the classic signal. MITRE's CAR-2014-05-001 treats workstation-to-workstation RPC as a likely sign of lateral movement.
- Much RPC never crosses a sensor. D3FEND notes that RPC over named pipes or loopback makes network collection difficult, so host telemetry has to fill the gap.
- The single ATT&CK link is inferred. D3FEND relates D3-RTA to T1558.003 Kerberoasting through the RPC Network Traffic artefact; its own CAR references point mainly at remote execution techniques.
D3-RTA at a glance
| Field | D3-RTA RPC Traffic Analysis |
|---|---|
| D3FEND ID | D3-RTA |
| Synonym | RPC Protocol Analysis |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Related siblings | D3-IPCTA IPC Traffic Analysis, D3-ANAA Administrative Network Activity Analysis, D3-RTSD Remote Terminal Session Detection |
| Digital artefact | RPC Network Traffic: traffic conforming to a standard RPC protocol between network nodes, not custom protocols |
| Example protocols D3FEND names | DCE/RPC, CORBA, ONC RPC, D-Bus, XML-RPC, JSON-RPC, SOAP, Apache Thrift |
| D3FEND references | CAR-2014-05-001, CAR-2014-11-007, CAR-2016-03-002, CAR-2014-03-005, CAR-2014-12-001, CAR-2015-04-002, CAR-2014-03-001, and a CrowdStrike patent on RPC call interception |
How it works
An RPC lets one computer run a function on another as if it were local. In Microsoft RPC, a client stub marshals parameters into Network Data Representation and the RPC runtime sends them to a server stub on the remote host. For Windows networks the protocol of interest is almost always DCE/RPC (MS-RPC), which runs in three common ways:
- Endpoint mapper and dynamic ports: the client contacts the RPC Endpoint Mapper on TCP 135, learns the port of the requested service (typically a dynamic port from 49152 upwards) and connects to it. CAR-2014-05-001 detects this two-step pattern by joining a flow to port 135 with a high-port to high-port flow between the same hosts within two seconds.
- Named pipes over SMB: the RPC rides inside SMB on TCP 445 to a named pipe such as
svcctl,atsvc,winregorlsarpc. CAR-2014-03-001 looks at SMB named pipe writes and namesWINREGandATSVCas pipes associated with adversary activity, whilespoolssis usually benign. - Local RPC: calls between processes on the same host never touch the network, which D3FEND flags as a collection limit.
The analysis then works at three levels: who talks RPC to whom (flow level), which interface they bind to (the interface UUID, which Zeek resolves to an endpoint name), and which operation they call (for example a service control or task scheduler function). CAR-2014-11-007 shows the interface-level approach: remote WMI over RPC binds to the DCOM interface IRemUnknown2, so filtering 135/tcp traffic for that interface finds WMI connections more precisely than looking for the string RPCSS, which also matches other DCOM services.
What to detect
| Behaviour | RPC evidence | CAR analytic | Related ATT&CK (v20) |
|---|---|---|---|
| RPC between peer workstations | Port 135 flow followed by a high-port flow between two workstations | CAR-2014-05-001 | T1021 Remote Services (T1021.002, T1021.003, T1021.006) |
| Remote WMI | Bind to IRemUnknown2 on a 135/tcp connection | CAR-2014-11-007, CAR-2014-12-001, CAR-2016-03-002 | T1047 Windows Management Instrumentation |
| Remote service creation and start | Service control manager interface over the svcctl pipe or dynamic port | CAR-2014-03-005 | T1569.002 Service Execution |
| Remotely scheduled tasks | Task scheduler interface over the atsvc pipe or dynamic port | CAR-2015-04-002 | T1053.005 Scheduled Task |
| Remote registry changes | Writes to the winreg pipe | CAR-2014-03-001 | T1021.002 SMB/Windows Admin Shares (transport) |
The ATT&CK column comes from the CAR analytics and from the techniques the behaviours describe; it is not D3FEND's inferred mapping. For the techniques themselves see T1047 Windows Management Instrumentation Defensive Guide, MITRE ATT&CK T1569 System Services, T1053 Scheduled Task/Job Defensive Guide and T1021 Remote Services.
ATT&CK techniques D3FEND relates to D3-RTA
Relationship type: inferred only. D3FEND states that its offensive mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026).
| ATT&CK ID | Technique | D3FEND relation | Practical note (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1558.003 | Kerberoasting | D3-RTA analyzes RPC Network Traffic, which D3FEND links to this technique | Kerberoasting is usually detected from Kerberos service ticket requests on domain controllers rather than from RPC decoding; treat RPC analysis as supporting context. See the Kerberoasting and AS-REP Roasting Defence Guide. |
See also MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide.
Where it is implemented
| Source | What it gives you | Limits |
|---|---|---|
| Network security monitoring with protocol decoding (for example Zeek) | Zeek's dce_rpc.log records timestamp, connection ID and 4-tuple, round-trip time, named_pipe, endpoint (resolved from the interface UUID) and operation | Zeek ignores some noisy operations by default (for example spoolss RpcSplOpenPrinter and several winreg calls); the named_pipe field may hold a port number instead of a pipe name |
| Network detection and response platforms | DCE/RPC and SMB decoding with built-in lateral movement analytics | Sensor placement decides coverage; east-west traffic between workstations is often unmonitored |
| Flow records (NetFlow, IPFIX, VPC flow logs) | The CAR-2014-05-001 port pattern | No interface or operation detail, so lower precision |
| Endpoint telemetry (EDR, ETW-based sensors) | Process-level view of RPC servers and clients, including local RPC that never crosses the network | Depends on the sensor; Windows Security event 5712 (Audit RPC Events) is documented by Microsoft as appearing never to occur |
| Application-layer RPC (JSON-RPC, XML-RPC, SOAP, gRPC) | API gateway, proxy and application logs of method names and callers | Inside TLS; inspect at the gateway or application, not on the wire |
Product categories are examples, not recommendations. See the Zeek Network Monitoring Guide and the NDR Guide.
Where identity fits
Most remote RPC in an enterprise comes from machine identities: management servers, backup agents, deployment platforms and monitoring service accounts that legitimately create services, query WMI or read registries across the estate. Baseline RPC by source host and account, not only by address. A service account that normally manages servers suddenly calling the task scheduler interface on workstations, or a workstation using the service control interface on peers, is far more telling than raw volume. See the Lateral Movement Guide.
Implementation steps
- Place sensors where RPC matters. Cover traffic to and from domain controllers and server segments, and sample east-west workstation traffic where possible; add host telemetry for segments without sensors.
- Turn on decoding. Enable DCE/RPC and SMB analysers so interface, pipe and operation are logged, not only flows.
- Baseline legitimate callers. List the management, backup and deployment systems that legitimately call service control, task scheduler, WMI and registry interfaces remotely, and the targets they manage.
- Start with high-value rules. Workstation-to-workstation RPC, remote service creation and remote task scheduling from hosts outside the baseline. Run them in alert-only mode first.
- Tune with an allowlist, not by removing rules. Suppress known source and interface pairs; review the allowlist regularly so new tools do not slip in unnoticed.
- Correlate with the host. Join RPC events to service creation, scheduled task creation and process start events on the target to confirm what happened.
How to verify it works
- Controlled tests: in a test segment, with approval, perform a remote service creation, a remote scheduled task and a remote WMI query from an administrative workstation, and confirm each produces the expected decoded record and alert.
- Field completeness: check that interface or endpoint names, pipes and operations are populated in a sample of RPC records, not just ports.
- Coverage map: list which segments and host groups have network decoding, which rely on host telemetry and which have neither.
- Noise review: track alert volume and false positive rate after each tuning change.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Server and domain controller segments with DCE/RPC decoding | Sensor coverage | Rising |
| Controlled remote execution tests detected | Detection effectiveness | Close to 100% |
| RPC records with interface and operation populated | Decoding quality | Rising |
| Remote execution alerts from sources outside the baseline that were true positives | Rule precision | Rising |
| Median time from RPC alert to host-side confirmation | Investigation speed | Falling |
Limits and bypasses
- Volume: D3FEND notes RPC is widely used and large environments need significant filtering; untuned rules are switched off within weeks.
- Encryption: RPC with packet privacy and SMB encryption hide interface and operation detail from network sensors; host telemetry becomes the primary source.
- Local and loopback RPC: never reaches a network sensor.
- Legitimate tools: attackers who use the organisation's own management platforms and accounts blend into the baseline; watch for new source and target pairs.
- Alternative channels: WinRM, SSH and remote desktop provide remote execution without DCE/RPC; D3-RTA is one of several detection techniques for lateral movement, not the whole answer.
Framework mapping
| Framework | Reference | Relationship to D3-RTA |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring | Monitoring network traffic for attacks and unauthorised use |
| NIST SP 800-53 Rev. 5 | AC-17 Remote Access | Monitoring and controlling remote access methods |
| NIST CSF 2.0 | DE.CM-01 Networks and network services are monitored to find potentially adverse events | Collection of RPC traffic |
| NIST CSF 2.0 | DE.AE-02 Potentially adverse events are analyzed to better understand associated activities | Analysis of decoded RPC activity |
D3FEND's references for D3-RTA are the CAR analytics and the patent listed above; the NIST rows are NHI Mgmt Group's mapping by intent.
Practitioner checklist
- Enable DCE/RPC and SMB decoding on sensors covering servers and domain controllers.
- Add host telemetry where network sensors cannot see RPC.
- Baseline legitimate remote management sources, accounts and interfaces.
- Alert on workstation-to-workstation RPC and remote service, task and WMI activity from outside the baseline.
- Correlate network RPC events with service, task and process events on targets.
- Test detections with approved, controlled remote execution in a test segment.
- Review allowlists and alert precision on a fixed schedule.
Standards and references
- MITRE D3FEND: RPC Traffic Analysis (D3-RTA)
- MITRE CAR: CAR-2014-05-001 RPC Activity
- MITRE CAR: CAR-2014-11-007 Remote WMI over RPC
- MITRE CAR: CAR-2014-03-001 SMB Write Request, Named Pipes
- Zeek: DCE/RPC analyser and dce_rpc.log
- Microsoft Learn: How RPC Works
- Microsoft Learn: Event 5712, a Remote Procedure Call was attempted
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Lateral Movement Guide · Zeek Network Monitoring Guide · D3-IPCTA IPC Traffic Analysis · MITRE D3FEND Guide