135, 593 - Pentesting MSRPC

Reading time: 10 minutes

Basic Information

The Microsoft Remote Procedure Call (MSRPC) protocol, a client-server model enabling a program to request a service from a program located on another computer without understanding the network's specifics, was initially derived from open-source software and later developed and copyrighted by Microsoft.

The RPC endpoint mapper can be accessed via TCP and UDP port 135, SMB on TCP 139 and 445 (with a null or authenticated session), and as a web service on TCP port 593.

135/tcp   open     msrpc         Microsoft Windows RPC

How does MSRPC work?

Initiated by the client application, the MSRPC process involves calling a local stub procedure that then interacts with the client runtime library to prepare and transmit the request to the server. This includes converting parameters into a standard Network Data Representation format. The choice of transport protocol is determined by the runtime library if the server is remote, ensuring the RPC is delivered through the network stack.

Identifying Exposed RPC Services

Exposure of RPC services across TCP, UDP, HTTP, and SMB can be determined by querying the RPC locator service and individual endpoints. Tools such as rpcdump facilitate the identification of unique RPC services, denoted by IFID values, revealing service details and communication bindings:

D:\rpctools> rpcdump [-p port] <IP>
**IFID**: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc version 1.0
Annotation: Messenger Service
UUID: 00000000-0000-0000-0000-000000000000
Binding: ncadg_ip_udp:<IP>[1028]

Access to the RPC locator service is enabled through specific protocols: ncacn_ip_tcp and ncadg_ip_udp for accessing via port 135, ncacn_np for SMB connections, and ncacn_http for web-based RPC communication. The following commands exemplify the utilization of Metasploit modules to audit and interact with MSRPC services, primarily focusing on port 135:

use auxiliary/scanner/dcerpc/endpoint_mapper
use auxiliary/scanner/dcerpc/hidden
use auxiliary/scanner/dcerpc/management
use auxiliary/scanner/dcerpc/tcp_dcerpc_auditor
rpcdump.py <IP> -p 135

All options except tcp_dcerpc_auditor are specifically designed for targeting MSRPC on port 135.

Notable RPC interfaces

• IFID: 12345778-1234-abcd-ef00-0123456789ab
• Named Pipe: \pipe\lsarpc
• Description: LSA interface, used to enumerate users.
• IFID: 3919286a-b10c-11d0-9ba8-00c04fd92ef5
• Named Pipe: \pipe\lsarpc
• Description: LSA Directory Services (DS) interface, used to enumerate domains and trust relationships.
• IFID: 12345778-1234-abcd-ef00-0123456789ac
• Named Pipe: \pipe\samr
• Description: LSA SAMR interface, used to access public SAM database elements (e.g., usernames) and brute-force user passwords regardless of account lockout policy.
• IFID: 1ff70682-0a51-30e8-076d-740be8cee98b
• Named Pipe: \pipe\atsvc
• Description: Task scheduler, used to remotely execute commands.
• IFID: 338cd001-2244-31f1-aaaa-900038001003
• Named Pipe: \pipe\winreg
• Description: Remote registry service, used to access and modify the system registry.
• IFID: 367abb81-9844-35f1-ad32-98f038001003
• Named Pipe: \pipe\svcctl
• Description: Service control manager and server services, used to remotely start and stop services and execute commands.
• IFID: 4b324fc8-1670-01d3-1278-5a47bf6ee188
• Named Pipe: \pipe\srvsvc
• Description: Service control manager and server services, used to remotely start and stop services and execute commands.
• IFID: 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57
• Named Pipe: \pipe\epmapper
• Description: DCOM interface, used for brute-force password grinding and information gathering via WM.

Identifying IP addresses

Using https://github.com/mubix/IOXIDResolver, comes from Airbus research is possible to abuse the ServerAlive2 method inside the IOXIDResolver interface.

This method has been used to get interface information as IPv6 address from the HTB box APT. See here for 0xdf APT writeup, it includes an alternative method using rpcmap.py from Impacket with stringbinding (see above).

Executing a RCE with valid credentials

It is possible to execute remote code on a machine, if the credentials of a valid user are available using dcomexec.py from impacket framework.

Remember to try with the different objects available

• ShellWindows
• ShellBrowserWindow
• MMC20

Port 593

The rpcdump.exe from rpctools can interact with this port.

Automated Fuzzing of MSRPC Interfaces

MS-RPC interfaces expose a large and often undocumented attack surface. The open-source MS-RPC-Fuzzer PowerShell module builds on James Forshaw’s NtObjectManager to dynamically create RPC client stubs from the interface metadata that is already present in Windows binaries. Once a stub exists the module can bombard each procedure with mutated inputs and log the outcome, making reproducible, large-scale fuzzing of RPC endpoints possible without writing a single line of IDL.

1. Inventory the interfaces

# Import the module (download / git clone first)
Import-Module .\MS-RPC-Fuzzer.psm1

# Parse a single binary
Get-RpcServerData -Target "C:\Windows\System32\efssvc.dll" -OutPath .\output

# Or crawl the whole %SystemRoot%\System32 directory
Get-RpcServerData -OutPath .\output

Get-RpcServerData will extract the UUID, version, binding strings (named-pipe / TCP / HTTP) and full procedure prototypes for every interface it encounters and store them in rpcServerData.json.

2. Run the fuzzer

'.\output\rpcServerData.json' |
    Invoke-RpcFuzzer -OutPath .\output `
                     -MinStrLen 100  -MaxStrLen 1000 `
                     -MinIntSize 9999 -MaxIntSize 99999

Relevant options:

• -MinStrLen / -MaxStrLen – size range for generated strings
• -MinIntSize / -MaxIntSize – value range for mutated integers (useful for overflow testing)
• -Sorted – execute procedures in an order that honours parameter dependencies so that outputs of one call can serve as inputs of the next (dramatically increases reachable paths)

The fuzzer implements 2 strategies:

1. Default fuzzer – random primitive values + default instances for complex types
2. Sorted fuzzer – dependency-aware ordering (see docs/Procedure dependency design.md)

Every call is written atomically to log.txt; after a crash the last line immediately tells you the offending procedure. The result of each call is also categorised into three JSON files:

• allowed.json – call succeeded and returned data
• denied.json – server responded with Access Denied
• error.json – any other error / crash

3. Visualise with Neo4j

'.\output\allowed.json' |
    Import-DataToNeo4j -Neo4jHost 192.168.56.10:7474 -Neo4jUsername neo4j

Import-DataToNeo4j converts the JSON artefacts into a graph structure where:

• RPC servers, interfaces and procedures are nodes
• Interactions (ALLOWED, DENIED, ERROR) are relationships

Cypher queries can then be used to quickly spot dangerous procedures or to replay the exact chain of calls that preceded a crash.

⚠️ The fuzzer is destructive: expect service crashes and even BSODs – always run it in an isolated VM snapshot.

Automated Interface Enumeration & Dynamic Client Generation (NtObjectManager)

PowerShell guru James Forshaw exposed most of the Windows RPC internals inside the open–source NtObjectManager module. Using it you can turn any RPC server DLL / EXE into a fully-featured client stub in seconds – no IDL, MIDL or manual unmarshalling required.

# Install the module once
Install-Module NtObjectManager -Force

# Parse every RPC interface exported by the target binary
$rpcinterfaces = Get-RpcServer "C:\Windows\System32\efssvc.dll"
$rpcinterfaces | Format-Table Name,Uuid,Version,Procedures

# Inspect a single procedure (opnum 0)
$rpcinterfaces[0].Procedures[0] | Format-List *

Typical output exposes parameter types exactly as they appear in MIDL (e.g. FC_C_WSTRING, FC_LONG, FC_BIND_CONTEXT).

Once you know the interface you can generate a ready-to-compile C# client:

# Reverse the MS-EFSR (EfsRpc*) interface into C#
Format-RpcClient $rpcinterfaces[0] -Namespace MS_EFSR -OutputPath .\MS_EFSR.cs

Inside the produced stub you will find methods such as:

public int EfsRpcOpenFileRaw(out Marshal.NdrContextHandle ctx, string FileName, int Flags) {
    // marshals parameters & calls opnum 0
}

The PowerShell helper Get-RpcClient can create an interactive client object so you can call the procedure immediately:

$client = Get-RpcClient $rpcinterfaces[0]
Connect-RpcClient $client -stringbinding 'ncacn_np:127.0.0.1[\\pipe\\efsrpc]' `
                     -AuthenticationLevel PacketPrivacy `
                     -AuthenticationType  WinNT  # NTLM auth

# Invoke the procedure → returns an authenticated context handle
$ctx = New-Object Marshal.NdrContextHandle
$client.EfsRpcOpenFileRaw([ref]$ctx, "\\\127.0.0.1\test", 0)

Authentication (Kerberos / NTLM) and encryption levels (PacketIntegrity, PacketPrivacy, …) can be supplied directly via the Connect-RpcClient cmdlet – ideal for bypassing Security Descriptors that protect high-privilege named pipes.

Context-Aware RPC Fuzzing (MS-RPC-Fuzzer)

Static interface knowledge is great, but what you really want is coverage-guided fuzzing that understands context handles and complex parameter chains. The open-source MS-RPC-Fuzzer project automates exactly that workflow:

1. Enumerate every interface/procedure exported by the target binary (Get-RpcServer).
2. Generate dynamic clients for each interface (Format-RpcClient).
3. Randomise input parameters (wide strings length, integer ranges, enums) while respecting the original NDR type.
4. Track context handles returned by one call to feed follow-up procedures automatically.
5. Fire high-volume calls against the chosen transport (ALPC, TCP, HTTP or named pipe).
6. Log exit statuses / faults / timeouts and export a Neo4j import file to visualise interface → procedure → parameter relationships and crash clusters.

Example run (named–pipe target):

Invoke-MSRPCFuzzer -Pipe "\\.\pipe\efsrpc" -Auth NTLM `
                   -MinLen 1  -MaxLen 0x400 `
                   -Iterations 100000 `
                   -OutDir .\results

A single out-of-bounds write or unexpected exception will be surfaced immediately with the exact opnum + fuzzed payload that triggered it – perfect starting point for a stable proof-of-concept exploit.

⚠️ Many RPC services execute in processes running as NT AUTHORITY\SYSTEM. Any memory-safety issue here usually translates to local privilege escalation or (when exposed over SMB/135) remote code execution.

References

• Automating MS-RPC vulnerability research (2025, Incendium.rocks)
• MS-RPC-Fuzzer – context-aware RPC fuzzer
• NtObjectManager PowerShell module
• https://www.cyber.airbus.com/the-oxid-resolver-part-1-remote-enumeration-of-network-interfaces-without-any-authentication/
• https://www.cyber.airbus.com/the-oxid-resolver-part-2-accessing-a-remote-object-inside-dcom/
• https://0xffsec.com/handbook/services/msrpc/
• MS-RPC-Fuzzer (GitHub)