RPC Activity
Hypothesis and description
Microsoft Windows uses its implementation of Distributed Computing Environment/Remote Procedure Call (DCE/RPC), which it calls Microsoft RPC, to call certain APIs remotely.
A Remote Procedure Call is initiated by communicating to the RPC Endpoint Mapper, which exists as the Windows service RpcEptMapper and listens on the port 135/tcp. The endpoint mapper resolves a requested endpoint/interface and responds to the client with the port that the service is listening on. Since the RPC endpoints are assigned ports when the services start, these ports are dynamically assigned from 49152 to 65535. The connection to the endpoint mapper then terminates and the client program can communicate directly with the requested service.
RPC is a legitimate functionality of Windows that allows remote interaction with a variety of services. For a Windows environment to be properly configured, several programs use RPC to communicate legitimately with servers. The background and benign RPC activity may be enormous, but must be learned, especially peer-to-peer RPC between workstations, which is often indicative of Lateral Movement.
According to ATT&CK, adversaries frequently use RPC connections to remotely
- Create/modify and execute services (CAR-2014-03-005)
- Schedule Tasks (CAR-2015-04-002)
- Query (CAR-2014-11-007) and Invoke (CAR-2014-12-001) - Windows Management Instrumentation (WMI)
Additional endpoints are detailed at here.
- Platforms
- Windows
- Domain
- Network
- Subtypes
- Netflow
- Submitted
- 2014-05-01
- Contributors
- MITRE
ATT&CK coverage
| Technique | Tactics | Coverage |
|---|---|---|
| T1021 Remote ServicesT1021.002, T1021.003, T1021.006 | Lateral Movement | Moderate |
1 technique, 4 ATT&CK ids including sub-techniques. Links open MITRE ATT&CK.
D3FEND techniques MITRE maps to this analytic
Data model references
Fields from the CAR data model (object/action/field) the analytic reads.
Pseudocode and implementations
Traffic to the RPC Endpoint Mapper will always have the destination port of 135. Assuming success, RPC traffic will continue to the endpoint. The endpoint and the client both bind to dynamically assigned ports (on Windows, this is typically greater than 49152). The traffic between the client and endpoint can be detected by looking at traffic to 135 followed by traffic where the source and destination ports are at least 49152.
flows = search Flow:Start
rpc_mapper = filter flows where (dest_port == 135)
rpc_endpoint = filter flows where (dest_port >= 49152 and src_port >= 49152)
rpc = join rpc_mapper, rpc_endpoint where (
(rpc_mapper.time < rpc_endpoint.time < rpc_mapper.time + 2 seconds) and
(rpc_mapper.src_ip == rpc_endpoint.src_ip and rpc_mapper.dest_ip == rpc_endpoint.dest_ip)
)
output rpcAcross MITRE's defensive frameworks
Linked through the 1 ATT&CK technique above.
Counter with D3FEND
Defensive techniques MITRE D3FEND maps to the same ATT&CK techniques.
- D3-STSession Termination1 shared
- D3-CAAConnection Attempt Analysis1 shared
- D3-APCAApplication Protocol Command Analysis1 shared
- D3-CSPPClient-server Payload Profiling1 shared
- D3-NTCDNetwork Traffic Community Deviation1 shared
- D3-NTFNetwork Traffic Filtering1 shared
- D3-NTSANetwork Traffic Signature Analysis1 shared
- D3-PHDURAPer Host Download-Upload Ratio Analysis1 shared
- D3-PMADProtocol Metadata Anomaly Detection1 shared
- D3-RTSDRemote Terminal Session Detection1 shared
- D3-UGLPAUser Geolocation Logon Pattern Analysis1 shared