135, 593 - Pentesting MSRPC

Reading time: 11 minutes

Informazioni di base

Il protocollo Microsoft Remote Procedure Call (MSRPC), un modello client-server che consente a un programma di richiedere un servizio da un programma situato su un altro computer senza comprendere le specifiche della rete, è stato inizialmente derivato da software open-source e successivamente sviluppato e protetto da copyright da Microsoft.

L'endpoint mapper RPC può essere accessibile tramite la porta TCP e UDP 135, SMB sulla TCP 139 e 445 (con una sessione nulla o autenticata), e come servizio web sulla porta TCP 593.

135/tcp   open     msrpc         Microsoft Windows RPC

Come funziona MSRPC?

Iniziato dall'applicazione client, il processo MSRPC prevede la chiamata a una procedura stub locale che interagisce con la libreria runtime del client per preparare e trasmettere la richiesta al server. Questo include la conversione dei parametri in un formato standard di Rappresentazione Dati di Rete. La scelta del protocollo di trasporto è determinata dalla libreria runtime se il server è remoto, garantendo che l'RPC venga consegnato attraverso lo stack di rete.

Identificazione dei servizi RPC esposti

L'esposizione dei servizi RPC su TCP, UDP, HTTP e SMB può essere determinata interrogando il servizio di localizzazione RPC e i singoli endpoint. Strumenti come rpcdump facilitano l'identificazione di servizi RPC unici, denotati da valori IFID, rivelando dettagli sul servizio e binding di comunicazione:

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]

L'accesso al servizio di localizzazione RPC è abilitato attraverso protocolli specifici: ncacn_ip_tcp e ncadg_ip_udp per l'accesso tramite la porta 135, ncacn_np per le connessioni SMB e ncacn_http per la comunicazione RPC basata sul web. I seguenti comandi esemplificano l'utilizzo dei moduli di Metasploit per auditare e interagire con i servizi MSRPC, concentrandosi principalmente sulla porta 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

Tutte le opzioni tranne tcp_dcerpc_auditor sono specificamente progettate per mirare a MSRPC sulla porta 135.

Interfacce RPC notevoli

• IFID: 12345778-1234-abcd-ef00-0123456789ab
• Named Pipe: \pipe\lsarpc
• Descrizione: Interfaccia LSA, utilizzata per enumerare gli utenti.
• IFID: 3919286a-b10c-11d0-9ba8-00c04fd92ef5
• Named Pipe: \pipe\lsarpc
• Descrizione: Interfaccia LSA Directory Services (DS), utilizzata per enumerare domini e relazioni di fiducia.
• IFID: 12345778-1234-abcd-ef00-0123456789ac
• Named Pipe: \pipe\samr
• Descrizione: Interfaccia LSA SAMR, utilizzata per accedere agli elementi del database SAM pubblico (ad es., nomi utente) e forzare le password degli utenti indipendentemente dalla politica di blocco degli account.
• IFID: 1ff70682-0a51-30e8-076d-740be8cee98b
• Named Pipe: \pipe\atsvc
• Descrizione: Pianificatore di attività, utilizzato per eseguire comandi da remoto.
• IFID: 338cd001-2244-31f1-aaaa-900038001003
• Named Pipe: \pipe\winreg
• Descrizione: Servizio di registro remoto, utilizzato per accedere e modificare il registro di sistema.
• IFID: 367abb81-9844-35f1-ad32-98f038001003
• Named Pipe: \pipe\svcctl
• Descrizione: Gestore di controllo dei servizi e servizi server, utilizzati per avviare e fermare servizi da remoto ed eseguire comandi.
• IFID: 4b324fc8-1670-01d3-1278-5a47bf6ee188
• Named Pipe: \pipe\srvsvc
• Descrizione: Gestore di controllo dei servizi e servizi server, utilizzati per avviare e fermare servizi da remoto ed eseguire comandi.
• IFID: 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57
• Named Pipe: \pipe\epmapper
• Descrizione: Interfaccia DCOM, utilizzata per la forzatura delle password e la raccolta di informazioni tramite WM.

Identificazione degli indirizzi IP

Utilizzando https://github.com/mubix/IOXIDResolver, proveniente da Airbus research, è possibile abusare del metodo ServerAlive2 all'interno dell'interfaccia IOXIDResolver.

Questo metodo è stato utilizzato per ottenere informazioni sull'interfaccia come indirizzo IPv6 dalla macchina HTB APT. Vedi qui per il writeup di 0xdf APT, include un metodo alternativo utilizzando rpcmap.py da Impacket con stringbinding (vedi sopra).

Esecuzione di un RCE con credenziali valide

È possibile eseguire codice remoto su una macchina, se le credenziali di un utente valido sono disponibili utilizzando dcomexec.py dal framework impacket.

Ricorda di provare con i diversi oggetti disponibili

• ShellWindows
• ShellBrowserWindow
• MMC20

Porta 593

Il rpcdump.exe da rpctools può interagire con questa porta.

Fuzzing automatizzato delle interfacce MSRPC

Le interfacce MS-RPC espongono una vasta e spesso non documentata superficie di attacco. Il modulo PowerShell open-source MS-RPC-Fuzzer si basa su NtObjectManager di James Forshaw per creare dinamicamente stub client RPC dai metadati dell'interfaccia già presenti nei binari di Windows. Una volta che uno stub esiste, il modulo può bombardare ciascuna procedura con input mutati e registrare l'esito, rendendo possibile il fuzzing riproducibile e su larga scala degli endpoint RPC senza scrivere una sola riga di IDL.

1. Inventario delle interfacce

# 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 estrarrà l'UUID, la versione, le stringhe di binding (named-pipe / TCP / HTTP) e i prototipi completi delle procedure per ogni interfaccia che incontra e li memorizzerà in rpcServerData.json.

2. Esegui il fuzzer

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

Opzioni rilevanti:

• -MinStrLen / -MaxStrLen – intervallo di dimensioni per le stringhe generate
• -MinIntSize / -MaxIntSize – intervallo di valori per gli interi mutati (utile per il testing di overflow)
• -Sorted – eseguire le procedure in un ordine che rispetta le dipendenze dei parametri in modo che gli output di una chiamata possano servire come input della successiva (aumenta drammaticamente i percorsi raggiungibili)

Il fuzzer implementa 2 strategie:

1. Default fuzzer – valori primitivi casuali + istanze predefinite per tipi complessi
2. Sorted fuzzer – ordinamento consapevole delle dipendenze (vedi docs/Procedure dependency design.md)

Ogni chiamata è scritta in modo atomico in log.txt; dopo un crash, l'ultima riga ti dice immediatamente quale procedura ha causato il problema. Il risultato di ogni chiamata è anche categorizzato in tre file JSON:

• allowed.json – chiamata riuscita e dati restituiti
• denied.json – il server ha risposto con Access Denied
• error.json – qualsiasi altro errore / crash

3. Visualizza con Neo4j

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

Import-DataToNeo4j converte gli artefatti JSON in una struttura a grafo dove:

• I server RPC, le interfacce e le procedure sono nodi
• Le interazioni (ALLOWED, DENIED, ERROR) sono relazioni

Le query Cypher possono quindi essere utilizzate per individuare rapidamente procedure pericolose o per riprodurre esattamente la catena di chiamate che ha preceduto un crash.

⚠️ Il fuzzer è distruttivo: aspettati crash del servizio e persino BSOD – eseguilo sempre in uno snapshot VM isolato.

Enumerazione automatizzata delle interfacce e generazione dinamica del client (NtObjectManager)

Il guru di PowerShell James Forshaw ha esposto la maggior parte degli interni di Windows RPC all'interno del modulo open-source NtObjectManager. Utilizzandolo, puoi trasformare qualsiasi DLL / EXE del server RPC in un client stub completo in pochi secondi – senza IDL, MIDL o unmarshalling manuale richiesti.

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

L'output tipico espone i tipi di parametro esattamente come appaiono in MIDL (ad es. FC_C_WSTRING, FC_LONG, FC_BIND_CONTEXT).

Una volta che conosci l'interfaccia, puoi generare un client C# pronto per la compilazione:

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

All'interno dello stub prodotto troverai metodi come:

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

L'assistente PowerShell Get-RpcClient può creare un oggetto client interattivo in modo da poter chiamare immediatamente la procedura:

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

Autenticazione (Kerberos / NTLM) e livelli di crittografia (PacketIntegrity, PacketPrivacy, …) possono essere forniti direttamente tramite il cmdlet Connect-RpcClient – ideale per bypassare i Descrittori di Sicurezza che proteggono i named pipe ad alta privilegio.

Fuzzing RPC Consapevole del Contesto (MS-RPC-Fuzzer)

La conoscenza statica dell'interfaccia è ottima, ma ciò che desideri davvero è il fuzzing guidato dalla copertura che comprende context handles e catene di parametri complesse. Il progetto open-source MS-RPC-Fuzzer automatizza esattamente quel flusso di lavoro:

1. Enumerare ogni interfaccia/procedura esportata dal binario target (Get-RpcServer).
2. Generare client dinamici per ogni interfaccia (Format-RpcClient).
3. Randomizzare i parametri di input (lunghezza delle stringhe ampie, intervalli interi, enum) rispettando il tipo NDR originale.
4. Tracciare context handles restituiti da una chiamata per alimentare automaticamente le procedure successive.
5. Eseguire chiamate ad alto volume contro il trasporto scelto (ALPC, TCP, HTTP o named pipe).
6. Registrare stati di uscita / errori / timeout ed esportare un file di importazione Neo4j per visualizzare le relazioni interfaccia → procedura → parametro e i cluster di crash.

Esempio di esecuzione (target named-pipe):

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

Un singolo write out-of-bounds o un'eccezione inaspettata verrà visualizzato immediatamente con l'esatto opnum + payload fuzzed che l'ha attivato – punto di partenza perfetto per un exploit proof-of-concept stabile.

⚠️ Molti servizi RPC vengono eseguiti in processi che girano come NT AUTHORITY\SYSTEM. Qualsiasi problema di sicurezza della memoria qui di solito si traduce in un'elevazione di privilegi locale o (quando esposto su SMB/135) esecuzione di codice remoto.

Riferimenti

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