Skip to content

RPC (Remote Procedure Call)

The Protocol That Runs Everything and Secures Nothing

The Genesis of Corporate Chaos

Let me tell you about the most important protocol you've never properly understood. It's 1984, and some engineers at Sun Microsystems are thinking, "What if programs could call functions on other computers as easily as they call local functions?" Thus, Remote Procedure Call (RPC) was born - the networking equivalent of teaching your programs to use the telephone.

Microsoft looked at this idea and said, "Hold my Windows 3.1 installation disk," then proceeded to implement MS-RPC (a fork of DCE/RPC) so deeply into Windows that removing it would be like trying to remove flour from a baked cake. Every time you log into Windows, browse network shares, print a document, or basically breathe near a Windows machine, you're using RPC.

Here's the kicker: RPC isn't just one protocol. It's a framework that says, "I don't care HOW you transport my calls - use TCP, UDP, named pipes, carrier pigeons, whatever - just make sure that function gets called on that remote machine." It's protocol-agnostic in the same way a desperate parent is vehicle-agnostic when late for school pickup.

The Architecture: Organized Chaos in Motion

The RPC Stack: A Layer Cake of Complexity

Application: "I need to call this function remotely!"
     ↓
RPC Runtime: "Let me serialize that for you"
     ↓
RPC Protocol: "I'll handle the communication details"
     ↓
Transport (TCP/UDP/SMB/HTTP): "I'll actually move the bits"
     ↓
Network: *confused screaming*

The Key Players in Our Drama:

RPC Endpoint Mapper (Port 135): Think of Port 135 as the reception desk at a massive corporate building. You walk up and say, "I need to talk to the print spooler," and the receptionist says, "Oh, they're in room 49523 today." Except this receptionist never verifies who you are or why you need that information.

Dynamic RPC Ports (49152-65535): These are like pop-up shops in a mall. Services grab whatever port is available, set up shop, and start accepting connections. The only way to find them? Ask the Endpoint Mapper. It's basically hide-and-seek where the seeker has a map.

Named Pipes (\pipe): The "I don't want to deal with firewalls" option. RPC over named pipes travels over SMB (port 445), disguising itself as file sharing traffic. It's like smuggling function calls inside a filing cabinet.

RPC Interfaces: Every RPC service has a UUID (Universally Unique Identifier) that identifies what it does. It's like a business card that says:

Hi, I'm the Task Scheduler!
UUID: 86D35949-83C9-4044-B424-DB363231FD0C
I live at: ncacn_ip_tcp:192.168.1.10[49155]

The Beautiful Disaster of RPC Protocols

MS-RPC vs DCE/RPC: The Family Feud

DCE/RPC (Distributed Computing Environment) was the original. MS-RPC is Microsoft's "enhanced" version, where "enhanced" means "we added our own authentication and made it incompatible with everything else." It's like taking a recipe and adding "a Microsoft twist" - suddenly it only works in Windows kitchens.

The Transport Protocols: Choose Your Fighter

RPC over TCP (ncacn_ip_tcp):

  • Direct, fast, and firewall-friendly (if you open 50,000 ports)
  • Used by: Domain Controllers, Exchange, most modern services
  • Port 135 + dynamic ports = firewall administrator nightmare

RPC over Named Pipes (ncacn_np):

  • Tunnels through SMB (port 445)
  • Authentication built-in via SMB
  • Perfect for lateral movement: "I'm just accessing a file share, officer!"

RPC over HTTP (ncacn_http):

  • Microsoft's answer to "but what about firewalls?"
  • Wraps RPC in HTTP like a burrito of confusion
  • Used by: Outlook Anywhere, Exchange
  • Ports 593 (RPC over HTTP endpoint mapper) and 80/443

Local RPC (ncalrpc):

  • For local inter-process communication
  • Uses ALPC (Advanced Local Procedure Call)
  • Still vulnerable to privilege escalation shenanigans

Why RPC is an Attacker's Swiss Army Knife

The Core Problem: RPC is Everywhere and Trusts Everyone

RPC's fundamental design philosophy seems to be "authentication is someone else's problem." It's like building a house with no locks and saying, "Well, the neighborhood has a gate."

The Authentication Disaster:

  • NULL sessions (yes, still a thing in 2024)
  • Pass-through authentication (your credentials, their service)
  • NTLM relay paradise (RPC loves accepting relayed credentials)
  • Kerberos delegation (when you want to be someone else)

The Enumeration Goldmine

RPC enumeration is like having X-ray vision into Windows infrastructure:

bash

# The classic RPC enumeration
rpcclient -U "" -N 192.168.1.100

# What you can discover:
- User accounts (enumdomusers)
- Group memberships (enumdomgroups)
- Password policies (getdompwinfo)
- Shared resources (netshareenumall)
- Logged on users (netconnenum)
- Active sessions (netsessenum)

It's like walking up to a building and having the security guard tell you everyone who works there, what departments they're in, and when they last changed their passwords.

RPC Interfaces: The Attack Surface Catalog

Every RPC interface is a potential entry point. Some greatest hits:

MS-SAMR (Security Account Manager Remote)

  • UUID: 12345778-1234-ABCD-EF00-0123456789AC
  • What it does: User and group management
  • Why attackers love it: User enumeration without authentication

MS-DRSR (Directory Replication Service Remote)

  • UUID: E3514235-4B06-11D1-AB04-00C04FC2DCD2
  • What it does: AD replication
  • Why attackers love it: DCSync attacks (pretend to be a DC, get all passwords)

MS-RPRN (Print System Remote)

  • UUID: 12345678-1234-ABCD-EF00-0123456789AB
  • What it does: Printing
  • Why attackers love it: PrinterBug/SpoolSample for coerced authentication

MS-EFSR (Encrypting File System Remote)

  • UUID: C681D488-D850-11D0-8C52-00C04FD90F7E
  • What it does: EFS operations
  • Why attackers love it: PetitPotam - coerce authentication from anywhere

MS-TSCH (Task Scheduler)

  • UUID: 86D35949-83C9-4044-B424-DB363231FD0C
  • What it does: Schedule tasks
  • Why attackers love it: Remote code execution as SYSTEM

The Authentication Maze: How RPC Decides Who You Are

The Authentication Levels: A Spectrum of Trust

RPC has authentication levels like a restaurant has dress codes - they exist, but enforcement varies:

  1. RPC_C_AUTHN_LEVEL_NONE: "I don't care who you are"
  2. RPC_C_AUTHN_LEVEL_CONNECT: "Show ID at the door, then do whatever"
  3. RPC_C_AUTHN_LEVEL_CALL: "Show ID for each request"
  4. RPC_C_AUTHN_LEVEL_PKT: "Show ID for each packet"
  5. RPC_C_AUTHN_LEVEL_PKT_INTEGRITY: "ID + tamper-proof seal"
  6. RPC_C_AUTHN_LEVEL_PKT_PRIVACY: "ID + encryption + tin foil hat"

Most services default to "CONNECT" because checking credentials is hard and developers are lazy.

The NTLM Relay Paradise

RPC services LOVE accepting NTLM authentication, and most don't check for signing. It's like accepting photocopied money because checking for watermarks is too much work.

Attacker: "Hey Service A, authenticate to me!"
Service A: "Here's my NTLM challenge response"
Attacker: *forwards to Service B* "I'm Service A!"
Service B: "Cool, what do you want to do?"
Attacker: "Everything."