135, 593 - Pentesting MSRPC

Reading time: 11 minutes

Informations de base

Le protocole Microsoft Remote Procedure Call (MSRPC), un modèle client-serveur permettant à un programme de demander un service à un programme situé sur un autre ordinateur sans comprendre les spécificités du réseau, a été initialement dérivé d'un logiciel open-source et développé et protégé par Microsoft.

Le mappage des points de terminaison RPC peut être accédé via le port TCP et UDP 135, SMB sur TCP 139 et 445 (avec une session nulle ou authentifiée), et en tant que service web sur le port TCP 593.

135/tcp   open     msrpc         Microsoft Windows RPC

Comment fonctionne MSRPC ?

Initie par l'application cliente, le processus MSRPC implique l'appel d'une procédure stub locale qui interagit ensuite avec la bibliothèque d'exécution cliente pour préparer et transmettre la demande au serveur. Cela inclut la conversion des paramètres en un format standard de représentation de données réseau. Le choix du protocole de transport est déterminé par la bibliothèque d'exécution si le serveur est distant, garantissant que l'RPC est livré à travers la pile réseau.

Identification des services RPC exposés

L'exposition des services RPC à travers TCP, UDP, HTTP et SMB peut être déterminée en interrogeant le service de localisation RPC et les points de terminaison individuels. Des outils tels que rpcdump facilitent l'identification des services RPC uniques, désignés par des valeurs IFID, révélant les détails du service et les liaisons de communication :

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'accès au service de localisation RPC est activé via des protocoles spécifiques : ncacn_ip_tcp et ncadg_ip_udp pour accéder via le port 135, ncacn_np pour les connexions SMB, et ncacn_http pour la communication RPC basée sur le web. Les commandes suivantes illustrent l'utilisation des modules Metasploit pour auditer et interagir avec les services MSRPC, en se concentrant principalement sur le 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

Toutes les options sauf tcp_dcerpc_auditor sont spécifiquement conçues pour cibler MSRPC sur le port 135.

Interfaces RPC notables

• IFID : 12345778-1234-abcd-ef00-0123456789ab
• Named Pipe : \pipe\lsarpc
• Description : Interface LSA, utilisée pour énumérer les utilisateurs.
• IFID : 3919286a-b10c-11d0-9ba8-00c04fd92ef5
• Named Pipe : \pipe\lsarpc
• Description : Interface LSA Directory Services (DS), utilisée pour énumérer les domaines et les relations de confiance.
• IFID : 12345778-1234-abcd-ef00-0123456789ac
• Named Pipe : \pipe\samr
• Description : Interface LSA SAMR, utilisée pour accéder aux éléments de la base de données SAM publique (par exemple, les noms d'utilisateur) et forcer les mots de passe des utilisateurs indépendamment de la politique de verrouillage de compte.
• IFID : 1ff70682-0a51-30e8-076d-740be8cee98b
• Named Pipe : \pipe\atsvc
• Description : Planificateur de tâches, utilisé pour exécuter des commandes à distance.
• IFID : 338cd001-2244-31f1-aaaa-900038001003
• Named Pipe : \pipe\winreg
• Description : Service de registre à distance, utilisé pour accéder et modifier le registre système.
• IFID : 367abb81-9844-35f1-ad32-98f038001003
• Named Pipe : \pipe\svcctl
• Description : Gestionnaire de contrôle de service et services serveur, utilisé pour démarrer et arrêter des services à distance et exécuter des commandes.
• IFID : 4b324fc8-1670-01d3-1278-5a47bf6ee188
• Named Pipe : \pipe\srvsvc
• Description : Gestionnaire de contrôle de service et services serveur, utilisé pour démarrer et arrêter des services à distance et exécuter des commandes.
• IFID : 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57
• Named Pipe : \pipe\epmapper
• Description : Interface DCOM, utilisée pour le craquage de mots de passe par force brute et la collecte d'informations via WM.

Identification des adresses IP

En utilisant https://github.com/mubix/IOXIDResolver, provenant de Airbus research, il est possible d'abuser de la méthode ServerAlive2 à l'intérieur de l'interface IOXIDResolver.

Cette méthode a été utilisée pour obtenir des informations sur l'interface sous forme d'adresse IPv6 de la boîte HTB APT. Voir ici pour le rapport 0xdf APT, il inclut une méthode alternative utilisant rpcmap.py de Impacket avec stringbinding (voir ci-dessus).

Exécution d'un RCE avec des identifiants valides

Il est possible d'exécuter du code à distance sur une machine, si les identifiants d'un utilisateur valide sont disponibles en utilisant dcomexec.py du framework impacket.

N'oubliez pas d'essayer avec les différents objets disponibles

• ShellWindows
• ShellBrowserWindow
• MMC20

Port 593

Le rpcdump.exe de rpctools peut interagir avec ce port.

Fuzzing automatisé des interfaces MSRPC

Les interfaces MS-RPC exposent une surface d'attaque large et souvent non documentée. Le module PowerShell open-source MS-RPC-Fuzzer s'appuie sur NtObjectManager de James Forshaw pour créer dynamiquement des stubs de client RPC à partir des métadonnées d'interface déjà présentes dans les binaires Windows. Une fois qu'un stub existe, le module peut bombarder chaque procédure avec des entrées mutées et enregistrer le résultat, rendant le fuzzing reproductible à grande échelle des points de terminaison RPC possible sans écrire une seule ligne d'IDL.

1. Inventaire des 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 extraira le UUID, la version, les chaînes de liaison (named-pipe / TCP / HTTP) et les prototypes de procédure complets pour chaque interface qu'il rencontre et les stockera dans rpcServerData.json.

2. Exécutez le fuzzer

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

Options pertinentes :

• -MinStrLen / -MaxStrLen – plage de taille pour les chaînes générées
• -MinIntSize / -MaxIntSize – plage de valeur pour les entiers mutés (utile pour les tests de débordement)
• -Sorted – exécute les procédures dans un ordre qui respecte les dépendances des paramètres afin que les sorties d'un appel puissent servir d'entrées pour le suivant (augmente considérablement les chemins accessibles)

Le fuzzer implémente 2 stratégies :

1. Fuzzer par défaut – valeurs primitives aléatoires + instances par défaut pour les types complexes
2. Fuzzer trié – ordonnancement conscient des dépendances (voir docs/Procedure dependency design.md)

Chaque appel est écrit de manière atomique dans log.txt ; après un crash, la dernière ligne vous indique immédiatement la procédure fautive. Le résultat de chaque appel est également catégorisé en trois fichiers JSON :

• allowed.json – l'appel a réussi et a renvoyé des données
• denied.json – le serveur a répondu avec Accès refusé
• error.json – toute autre erreur / crash

3. Visualiser avec Neo4j

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

Import-DataToNeo4j convertit les artefacts JSON en une structure de graphe où :

• Les serveurs RPC, interfaces et procédures sont des nœuds
• Les interactions (ALLOWED, DENIED, ERROR) sont des relations

Des requêtes Cypher peuvent ensuite être utilisées pour repérer rapidement des procédures dangereuses ou pour rejouer la chaîne exacte d'appels qui a précédé un crash.

⚠️ Le fuzzer est destructeur : attendez-vous à des plantages de service et même des BSOD – exécutez-le toujours dans un instantané de VM isolé.

Énumération d'Interface Automatisée & Génération Dynamique de Client (NtObjectManager)

Le gourou de PowerShell James Forshaw a exposé la plupart des internals de Windows RPC à l'intérieur du module open-source NtObjectManager. En l'utilisant, vous pouvez transformer n'importe quel DLL / EXE de serveur RPC en un stub de client entièrement fonctionnel en quelques secondes – sans IDL, MIDL ou désérialisation manuelle requise.

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

La sortie typique expose les types de paramètres exactement comme ils apparaissent dans MIDL (par exemple, FC_C_WSTRING, FC_LONG, FC_BIND_CONTEXT).

Une fois que vous connaissez l'interface, vous pouvez générer un client C# prêt à être compilé :

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

À l'intérieur du stub produit, vous trouverez des méthodes telles que :

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

L'outil PowerShell Get-RpcClient peut créer un objet client interactif afin que vous puissiez appeler la procédure immédiatement :

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

L'authentification (Kerberos / NTLM) et les niveaux de cryptage (PacketIntegrity, PacketPrivacy, …) peuvent être fournis directement via le cmdlet Connect-RpcClient – idéal pour contourner les descripteurs de sécurité qui protègent les pipes nommés à privilèges élevés.

Fuzzing RPC Sensible au Contexte (MS-RPC-Fuzzer)

La connaissance statique de l'interface est excellente, mais ce que vous voulez vraiment, c'est un fuzzing guidé par la couverture qui comprend les handles de contexte et les chaînes de paramètres complexes. Le projet open-source MS-RPC-Fuzzer automatise exactement ce flux de travail :

1. Énumérer chaque interface/procédure exportée par le binaire cible (Get-RpcServer).
2. Générer des clients dynamiques pour chaque interface (Format-RpcClient).
3. Randomiser les paramètres d'entrée (longueur des chaînes larges, plages d'entiers, énumérations) tout en respectant le type NDR original.
4. Suivre les handles de contexte retournés par un appel pour alimenter automatiquement les procédures de suivi.
5. Effectuer des appels à fort volume contre le transport choisi (ALPC, TCP, HTTP ou pipe nommé).
6. Enregistrer les statuts de sortie / défauts / délais d'attente et exporter un fichier d'importation Neo4j pour visualiser les relations interface → procédure → paramètre et les clusters de plantage.

Exécution d'exemple (cible de pipe nommé) :

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

Une seule écriture hors limites ou une exception inattendue sera immédiatement révélée avec l'opnum exact + la charge utile fuzzée qui l'a déclenchée – point de départ parfait pour un exploit de preuve de concept stable.

⚠️ De nombreux services RPC s'exécutent dans des processus fonctionnant en tant que NT AUTHORITY\SYSTEM. Tout problème de sécurité mémoire ici se traduit généralement par une élévation de privilèges locale ou (lorsqu'il est exposé via SMB/135) exécution de code à distance.

Références

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