Knowledge is Power
BARE METAL CYBERKnowledge is Power

Sitewide Search

Search Bare Metal Cyber

Search courses, individual lessons, wiki entries, books, podcasts, magazine articles, Daily Cyber News, and Darwin.

MITRE D3FEND™ Learning Center

D3-RTA — RPC Traffic Analysis

Monitoring the activity of remote procedure calls in communication traffic to establish standard protocol operations and potential attacker activities.

1Enterprise inferred
1Parent technique
1Related artifact
8Source references

Detect · D3FEND ontology 1.6.0 · Active

Open official technique ↗
Official D3FEND definition

Definition

Monitoring the activity of remote procedure calls in communication traffic to establish standard protocol operations and potential attacker activities.

Official D3FEND knowledge-base content

How it works

A remote procedure call (RPC) enables one computer to execute a specific function on another computer, as if it were a local application process. There are numerous RPC specifications and implementations. RPC capabilities can be abused by attackers in order to achieve a variety of tactical objectives including execution, persistence, initial access, and more. RPC proxies may be used to collect and store RPC traffic. RPCs can occur over network sockets or named pipes.

Analytics look for unauthorized behavior such as:

Example RPC Protocols:

  • Processes being launched or scheduled remotely
  • System configurations being changed remotely
  • Unauthorized file read activity
  • DCE/RPC
  • CORBA
  • Open Network Computing Remote Procedure Call
  • D-Bus
  • XML-RPC
  • JSON-RPC
  • SOAP
  • Apache Thrift

Considerations

  • RPC is widely used in enterprise environments, and significant data filtering may be required in large environments to enable analytic processing.
  • RPC traffic may occur over a pipe, or within a host over loopback interface, thus making network collection difficult.
Bare Metal Cyber interpretation

Implementation perspective

RPC Traffic Analysis should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes RPC Network Traffic.

Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.

Questions to ask

  • Which events, states, or artifacts must be observed for the analysis to work?
  • What analytic logic, threshold, comparison, or signature turns observations into a finding?
  • How are expected false positives, blind spots, and environmental variations documented?
  • Who receives the result, and what action is expected when the technique produces a finding?

Evidence and validation

  • Telemetry and data-source configuration records
  • Analytic logic, thresholds, signatures, and version history
  • Test cases demonstrating expected positive and negative results
  • Alert, triage, escalation, and tuning records

Common failure patterns

  • Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
  • The technique produces alerts without an accountable triage and response process.
  • Detection coverage is claimed from product deployment without testing the relevant analytic behavior.

This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.

Ontology hierarchy

Technique hierarchy

Direct child techniques

None listed at this level.

D3FEND graph relationships

Artifacts and ontology entities

These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.

Explicit technique relationships

analyzesRPC Network Traffic
Show inferred artifact relationship paths (1)
RPC Traffic AnalysisanalyzesRPC Network Traffic
Inferred and experimental

Offensive-technique relationships

These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.

ATT&CK Enterprise (1)
T1558.003KerberoastingCredential Access
Source record

Authoritative sources

Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.