135, 593 - Pentesting MSRPC

Reading time: 10 minutes

Grundlegende Informationen

Das Microsoft Remote Procedure Call (MSRPC) Protokoll, ein Client-Server-Modell, das es einem Programm ermöglicht, einen Dienst von einem Programm anzufordern, das sich auf einem anderen Computer befindet, ohne die Einzelheiten des Netzwerks zu verstehen, wurde ursprünglich aus Open-Source-Software abgeleitet und später von Microsoft entwickelt und urheberrechtlich geschützt.

Der RPC-Endpunkt-Mapper kann über TCP- und UDP-Port 135, SMB über TCP 139 und 445 (mit einer null oder authentifizierten Sitzung) und als Webdienst über TCP-Port 593 zugegriffen werden.

135/tcp   open     msrpc         Microsoft Windows RPC

Wie funktioniert MSRPC?

Initiiert durch die Client-Anwendung, umfasst der MSRPC-Prozess den Aufruf einer lokalen Stub-Prozedur, die dann mit der Client-Laufzeitbibliothek interagiert, um die Anfrage an den Server vorzubereiten und zu übertragen. Dies beinhaltet die Umwandlung von Parametern in ein standardisiertes Network Data Representation-Format. Die Wahl des Transportprotokolls wird von der Laufzeitbibliothek bestimmt, wenn der Server remote ist, um sicherzustellen, dass das RPC durch den Netzwerk-Stack geliefert wird.

Identifizierung exponierter RPC-Dienste

Die Exposition von RPC-Diensten über TCP, UDP, HTTP und SMB kann durch Abfragen des RPC-Standortdienstes und einzelner Endpunkte bestimmt werden. Tools wie rpcdump erleichtern die Identifizierung einzigartiger RPC-Dienste, die durch IFID-Werte gekennzeichnet sind und Details zu den Diensten und Kommunikationsbindungen offenbaren:

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]

Der Zugriff auf den RPC-Standortdienst erfolgt über spezifische Protokolle: ncacn_ip_tcp und ncadg_ip_udp für den Zugriff über Port 135, ncacn_np für SMB-Verbindungen und ncacn_http für webbasierte RPC-Kommunikation. Die folgenden Befehle veranschaulichen die Nutzung von Metasploit-Modulen zur Überprüfung und Interaktion mit MSRPC-Diensten, wobei der Schwerpunkt hauptsächlich auf Port 135 liegt:

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

Alle Optionen außer tcp_dcerpc_auditor sind speziell für das Targeting von MSRPC auf Port 135 konzipiert.

Bemerkenswerte RPC-Schnittstellen

• IFID: 12345778-1234-abcd-ef00-0123456789ab
• Benannte Pipe: \pipe\lsarpc
• Beschreibung: LSA-Schnittstelle, verwendet zur Auflistung von Benutzern.
• IFID: 3919286a-b10c-11d0-9ba8-00c04fd92ef5
• Benannte Pipe: \pipe\lsarpc
• Beschreibung: LSA-Verzeichnisdienste (DS) Schnittstelle, verwendet zur Auflistung von Domänen und Vertrauensbeziehungen.
• IFID: 12345778-1234-abcd-ef00-0123456789ac
• Benannte Pipe: \pipe\samr
• Beschreibung: LSA SAMR-Schnittstelle, verwendet zum Zugriff auf öffentliche SAM-Datenbankelemente (z. B. Benutzernamen) und zum Brute-Forcen von Benutzerpasswörtern unabhängig von der Kontosperrpolitik.
• IFID: 1ff70682-0a51-30e8-076d-740be8cee98b
• Benannte Pipe: \pipe\atsvc
• Beschreibung: Aufgabenplaner, verwendet zum Remote-Ausführen von Befehlen.
• IFID: 338cd001-2244-31f1-aaaa-900038001003
• Benannte Pipe: \pipe\winreg
• Beschreibung: Remote-Registry-Dienst, verwendet zum Zugreifen auf und Ändern der Systemregistrierung.
• IFID: 367abb81-9844-35f1-ad32-98f038001003
• Benannte Pipe: \pipe\svcctl
• Beschreibung: Dienststeuerungsmanager und Serverdienste, verwendet zum Remote-Starten und Stoppen von Diensten und Ausführen von Befehlen.
• IFID: 4b324fc8-1670-01d3-1278-5a47bf6ee188
• Benannte Pipe: \pipe\srvsvc
• Beschreibung: Dienststeuerungsmanager und Serverdienste, verwendet zum Remote-Starten und Stoppen von Diensten und Ausführen von Befehlen.
• IFID: 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57
• Benannte Pipe: \pipe\epmapper
• Beschreibung: DCOM-Schnittstelle, verwendet für Brute-Force-Passwortangriffe und Informationssammlung über WM.

Identifizierung von IP-Adressen

Mit https://github.com/mubix/IOXIDResolver, stammt von Airbus research, ist es möglich, die ServerAlive2-Methode innerhalb der IOXIDResolver-Schnittstelle auszunutzen.

Diese Methode wurde verwendet, um Schnittstelleninformationen wie IPv6-Adressen von der HTB-Box APT zu erhalten. Siehe hier für den 0xdf APT-Bericht, der eine alternative Methode mit rpcmap.py von Impacket mit stringbinding (siehe oben) enthält.

Ausführen eines RCE mit gültigen Anmeldeinformationen

Es ist möglich, Remote-Code auf einem Rechner auszuführen, wenn die Anmeldeinformationen eines gültigen Benutzers verfügbar sind, indem dcomexec.py aus dem Impacket-Framework verwendet wird.

Denken Sie daran, es mit den verschiedenen verfügbaren Objekten zu versuchen

• ShellWindows
• ShellBrowserWindow
• MMC20

Port 593

Das rpcdump.exe von rpctools kann mit diesem Port interagieren.

Automatisiertes Fuzzing von MSRPC-Schnittstellen

MS-RPC-Schnittstellen bieten eine große und oft undokumentierte Angriffsfläche. Das Open-Source-Modul MS-RPC-Fuzzer für PowerShell baut auf James Forshaws NtObjectManager auf, um dynamisch RPC-Client-Stubs aus den bereits in Windows-Binärdateien vorhandenen Schnittstellendaten zu erstellen. Sobald ein Stub existiert, kann das Modul jede Prozedur mit mutierten Eingaben bombardieren und das Ergebnis protokollieren, was reproduzierbares, großflächiges Fuzzing von RPC-Endpunkten ohne das Schreiben einer einzigen Zeile IDL ermöglicht.

1. Inventarisierung der Schnittstellen

# 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 extrahiert die UUID, Version, Bindungsstrings (benannte Pipe / TCP / HTTP) und vollständige Prozedurprototypen für jede Schnittstelle, die es findet, und speichert sie in rpcServerData.json.

2. Führen Sie den Fuzzer aus

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

Relevante Optionen:

• -MinStrLen / -MaxStrLen – Größenbereich für generierte Strings
• -MinIntSize / -MaxIntSize – Wertebereich für mutierte Ganzzahlen (nützlich für Überlauf-Tests)
• -Sorted – Verfahren in einer Reihenfolge ausführen, die Parameterabhängigkeiten berücksichtigt, sodass die Ausgaben eines Aufrufs als Eingaben des nächsten dienen können (erhöht dramatisch die erreichbaren Pfade)

Der Fuzzer implementiert 2 Strategien:

1. Standard-Fuzzer – zufällige primitive Werte + Standardinstanzen für komplexe Typen
2. Sortierter Fuzzer – abhängigkeitssensible Anordnung (siehe docs/Procedure dependency design.md)

Jeder Aufruf wird atomar in log.txt geschrieben; nach einem Absturz sagt die letzte Zeile sofort, welches Verfahren das Problem verursacht hat. Das Ergebnis jedes Aufrufs wird auch in drei JSON-Dateien kategorisiert:

• allowed.json – Aufruf erfolgreich und Daten zurückgegeben
• denied.json – Server hat mit Zugriff verweigert geantwortet
• error.json – jeder andere Fehler / Absturz

3. Visualisieren mit Neo4j

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

Import-DataToNeo4j konvertiert die JSON-Artefakte in eine Graphstruktur, in der:

• RPC-Server, Schnittstellen und Prozeduren Knoten sind
• Interaktionen (ALLOWED, DENIED, ERROR) Beziehungen sind

Cypher-Abfragen können dann verwendet werden, um gefährliche Prozeduren schnell zu erkennen oder die genaue Kette von Aufrufen, die einem Absturz vorausging, erneut abzuspielen.

⚠️ Der Fuzzer ist destruktiv: Erwarten Sie Dienstabstürze und sogar BSODs – führen Sie ihn immer in einem isolierten VM-Snapshot aus.

Automatisierte Schnittstellenerfassung & dynamische Clientgenerierung (NtObjectManager)

PowerShell-Guru James Forshaw hat die meisten der Windows RPC-Interna im Open-Source-Modul NtObjectManager offengelegt. Damit können Sie jede RPC-Server-DLL / EXE in einen voll funktionsfähigen Client-Stubs in Sekunden verwandeln – keine IDL, MIDL oder manuelles Unmarshalling erforderlich.

# 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 *

Typische Ausgaben zeigen die Parametertypen genau so, wie sie in MIDL erscheinen (z.B. FC_C_WSTRING, FC_LONG, FC_BIND_CONTEXT).

Sobald Sie die Schnittstelle kennen, können Sie einen bereit zum Kompilieren C#-Client generieren:

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

Innerhalb des erzeugten Stubs finden Sie Methoden wie:

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

Der PowerShell-Helfer Get-RpcClient kann ein interaktives Client-Objekt erstellen, sodass Sie das Verfahren sofort aufrufen können:

$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)

Authentifizierung (Kerberos / NTLM) und Verschlüsselungsstufen (PacketIntegrity, PacketPrivacy, …) können direkt über das Connect-RpcClient Cmdlet bereitgestellt werden – ideal zum Umgehen von Sicherheitsbeschreibungen, die hochprivilegierte benannte Pipes schützen.

Kontextbewusstes RPC-Fuzzing (MS-RPC-Fuzzer)

Statisches Schnittstellenwissen ist großartig, aber was Sie wirklich wollen, ist coverage-guided fuzzing, das Kontext-Handles und komplexe Parameterketten versteht. Das Open-Source-Projekt MS-RPC-Fuzzer automatisiert genau diesen Workflow:

1. Enumerieren Sie jede Schnittstelle/Prozedur, die von der Ziel-Binärdatei exportiert wird (Get-RpcServer).
2. Generieren Sie dynamische Clients für jede Schnittstelle (Format-RpcClient).
3. Randomisieren Sie Eingabeparameter (Längen von breiten Zeichenfolgen, Ganzzahlbereiche, Enums), während Sie den ursprünglichen NDR-Typ respektieren.
4. Verfolgen Sie Kontext-Handles, die von einem Aufruf zurückgegeben werden, um nachfolgende Prozeduren automatisch zu speisen.
5. Führen Sie hochvolumige Aufrufe gegen den gewählten Transport (ALPC, TCP, HTTP oder benannte Pipe) durch.
6. Protokollieren Sie Exit-Status / Fehler / Zeitüberschreitungen und exportieren Sie eine Neo4j Importdatei, um Schnittstelle → Prozedur → Parameter Beziehungen und Absturzcluster zu visualisieren.

Beispielausführung (benannte Pipe-Ziel):

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

Ein einzelner Out-of-Bounds-Schreibvorgang oder eine unerwartete Ausnahme wird sofort mit der genauen opnum + fuzzed Payload, die ihn ausgelöst hat, angezeigt – ein perfekter Ausgangspunkt für einen stabilen Proof-of-Concept-Exploit.

⚠️ Viele RPC-Dienste werden in Prozessen ausgeführt, die als NT AUTHORITY\SYSTEM laufen. Jedes Problem mit der Speichersicherheit hier führt normalerweise zu einer lokalen Privilegieneskalation oder (wenn über SMB/135 exponiert) Remote Code Execution.

Referenzen

• 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)