RPC-Triage

Statique vs dynamique : lisez d'abord ceci. Il vaut la peine d'être clair d'emblée sur la frontière entre analyse dynamique et statique : cet outil ne fait son classement que par analyse statique. Il lit les structures MIDL / NDR compilées directement dans le binaire et n'exécute jamais rien.

Triage statique pour la surface d'attaque RPC de Windows. Pointez-le sur un dossier de binaires PE ; il trouve tous ceux qui enregistrent un serveur RPC, récupère les signatures de méthodes NDR de chaque interface, les liaisons de transport et les indicateurs d'enregistrement directement dans les structures MIDL compilées, puis classe chaque interface selon accessibilité x danger, avec un reçu arithmétique complet attaché à chaque score afin que vous puissiez vérifier le calcul à la main.

Les outils RPC existants récupèrent volontiers les signatures de méthodes d'une interface et ses indicateurs d'enregistrement. Ce qu'aucun d'eux ne fait, c'est prendre les deux et répondre à la seule question qui décide réellement où vous passez votre temps : étant donné que je peux atteindre cette interface, et étant donné ce que ses méthodes acceptent en entrée, avec quelle urgence dois-je l'examiner par rapport à tout le reste de la machine ? C'est cette lacune que l'outil comble.

Ce qu'il fait

• Filtre le dossier cible pour que Ghidra n'analyse automatiquement que les binaires qui enregistrent réellement un serveur RPC (ils importent rpcrt4.dll et appellent l'une des API RpcServerRegisterIf\*). Sur System32, c'est la différence entre un après-midi et une semaine.

• Extrait, par interface : l'UUID, la chaîne RPC_SERVER_INTERFACE / MIDL_SERVER_INFO, le DispatchTableCount faisant autorité, l'opnum de chaque méthode + les directions de paramètres + les opcodes NDR décodés, les indicateurs d'enregistrement (R9), la présence du callback de sécurité (« bouncer »), le descripteur de sécurité (au mieux), et les liaisons endpoint / transport.

• Classe chaque interface propre sur deux axes indépendants et les multiplie en un score composite 0-100, réparti en seaux Critique / Élevé / Modéré / Faible.

• S'explique lui-même : chaque score est accompagné d'une chaîne de reçu listant chaque composant et l'arithmétique qui a produit le nombre final.

Comment ça fonctionne

target dir --(pefile filter) --> only RPC-registering PEs
          --(Ghidra headless auto-analysis) --> analyzed program DB
          --(extract_rpc_interfaces.py script) --> interfaces + NDR + flags + endpoints
          --(two-axis AHP ranking engine) --> ranked interfaces + receipts
           --> single JSON report

Dépendance zéro symbole : Un différenciateur technique essentiel de ce moteur est qu'il fonctionne entièrement sans symboles de débogage. En parcourant programmatiquement les tables de dispatch et en analysant les bytecodes NDR (Network Data Representation) bruts et les structures MIDL compilées directement depuis la mémoire, l'outil contourne le besoin des fichiers .pdb de Microsoft ou des requêtes en direct au endpoint mapper. Cela garantit que le moteur fonctionne prêt à l'emploi sur les binaires System32 de production, dépouillés, exactement tels qu'ils sont livrés.

Prérequis

• Ghidra 11.x (utilise le support/analyzeHeadless fourni). Nécessite un JDK 17+ dans le PATH.

• Python 3.8+ côté pilote, avec pefile.

• Le script d'extraction s'exécute sous le Jython 2.7 fourni avec Ghidra - aucune importation tierce, rien à installer de ce côté.

• Cibles : fichiers PE Windows x64. L'analyse elle-même est indépendante du système d'exploitation (Ghidra est multiplateforme), vous n'avez donc pas besoin de l'exécuter sous Windows.

Installation

git clone https://github.com/talha-nazeef-ahmed/RPC-Triage
cd RPC-Triage/
python -m pip install -r requirements.txt   # just pefile

requirements.txt : pefile>=2023.2.7

Utilisation

Tout est piloté par orchestrator.py : il filtre, importe, analyse et exécute l'extracteur pour vous.

python orchestrator.py \
  -t \"C:\Windows\System32\" \
  -g \"C:\ghidra_12.1.2_PUBLIC\" \
  -s \".\extract_rpc_interfaces.py\" \
  -o \".\out\report.json\" \
  --stagedir \".\out\staged\" \
  --projdir  \".\out\ghidra_proj\" \
  --projname RPC_Atlas

Première exécution vs ré-exécution (important). La première exécution fait la partie lente : elle filtre, importe les binaires correspondants, exécute l'analyse automatique complète, puis dépose un marqueur .analysisComplete dans --projdir. Chaque exécution ultérieure sur le même projet ignore l'import/analyse (-process -noanalysis) et réexécute simplement le script sur les programmes déjà analysés. Analyser System32 est donc un coût unique, et itérer sur la sortie est peu coûteux. Si l'analyse est interrompue, le marqueur n'est pas écrit et le projet partiel (.rep / .gpr) est supprimé et repart de zéro.

Sortie

Un fichier JSON : une liste de binaires, chacun avec un tableau Interfaces. Une exécution complète sur System32 est incluse dans ce dépôt à output/FullBatchRun.json ; c'est la sortie brute, non organisée, afin que vous puissiez voir exactement ce que l'outil produit à grande échelle. Par interface :

Étiquettes ; la porte d'hygiène des données :

• Clean : récupéré proprement ; classé normalement.

• Needs-Review : classé, mais la traversée de la table de dispatch a dépassé le nombre stocké (généralement un bloc de thunk final). Le score est réel mais porte [Provisional] ; vérifiez le nombre de méthodes avant de le citer.

• Diagnostics / Diagnostics (2) : la ligne est un artefact d'extraction (une chaîne ASCII mal interprétée comme un UUID et/ou un pointeur MIDL corrompu). Non noté (Rank: N/A). Ils sont conservés exprès : ils rendent compte de la santé de l'outil, ce ne sont pas de la surface d'attaque.

La note FLAG: Walked X != Stored Y . Le DispatchTableCount stocké fait autorité et c'est celui que chaque score utilise. Le nombre parcouru est une vérification indépendante d'exécutabilité ; lorsque les deux divergent (souvent un facteur 2 propre), l'interface est étiquetée Needs-Review afin que vous sachiez qu'il faut l'examiner. Cela ne change jamais silencieusement un score.

Comment lire un reçu de score

C'est la partie qui rend un score contestable :

Moderate/35 | Gate:35 [ncacn_np:41, MultiEndpointBonus:15, HasBouncer:-46, BouncerIsNotCaching:25] | Surface:100 [HasBogusStruct:1x(opnums 5):[in]:61, HasCallerSizedBuffer:5x(opnums 0,6,11):[in]:49, InPtrs:6:18, Count:12:6 -> raw:134 [capped to 100] * 1.0 -> 100] | (35 * 100) / 100 = 35 [Provisional]

Lisez-le de gauche à droite :

1. Moderate/35 : palier et score composite.

2. Gate:35 [...] : l'axe d'accessibilité. Il part de la base de transport (ncacn_np:41, un pipe nommé), puis liste chaque modificateur d'enregistrement avec sa contribution signée : MultiEndpointBonus:15 (enregistré sur plusieurs transports), HasBouncer:-46 (un callback de sécurité est présent, ce qui réduit l'accessibilité), et BouncerIsNotCaching:+25. Somme puis plafonnée à [5,100] -> 35.

3. Surface:100 [...] : l'axe de danger. Chaque signal déclenché est Nom:nombre x(opnums):direction:poids, p. ex. HasBogusStruct s'est déclenché sur 1 paramètre (opnums 5) et son poids est 61. Puis une contribution basée sur le nombre : InPtrs:6:18 = 6 pointeurs d'entrée contrôlés par l'appelant contribuant +18, Count:12:6 = 12 méthodes ajoutant +6. Le est la somme avant plafonnement, , est le multiplicateur de confiance (il tombe à 0.5 lorsque les signatures sont incertaines) ; Surface finale .

Un deuxième exemple montrant le plafonnement et la décote de faible confiance :

Low/3 | Gate:5 [Dynamic / epmapper:29, LocalCallOnly:-100, SecureOnly:-65, HasBouncer:-46, BouncerIsNotCaching:25] | Surface:50 [... -> raw:140 [capped to 100] * 0.5 -> 50] | (5 * 50) / 100 = 3

LocalCallOnly:-100 seul fait passer la porte sous zéro, donc elle se plafonne au plancher de 5 ; les signatures étaient incertaines, donc Surface est réduite de moitié (* 0.5) ; le composite atterrit à 3. Espace d'entrée dangereux, mais effectivement inaccessible -> correctement déprioritisé.

Palierss

Critique >= 75, Élevé >= 50, Modéré >= 25, Faible sinon (une interface avec une surface récupérée nulle est Faible quel que soit la porte). Les seuils reposent sur le composite ; le modèle qui les sous-tend est dans docs/Surface_Scoring_Methadology.md.

Le modèle de notation

Les trois tables de poids (bases de transport, modificateurs de porte, signaux de surface) sont dérivées avec le processus de hiérarchie analytique ; comparaisons par paires, poids de moyenne géométrique et ratio de cohérence mesuré. La dérivation complète, les matrices, les nombres de cohérence et les notes calculées à la main sont dans docs/Surface_Scoring_Methadology.md.

Validation

Pour que l'extraction ne soit pas simplement auto-confirmante, les interfaces que cet outil récupère ont été recoupées avec un extracteur IDL RPC indépendant et bien établi (l'analyseur RpcServer de NtObjectManager de James Forshaw) exécuté sur les mêmes binaires. Les dumpss de référence pour lsass, samsrv et winlogon sont dans validation/, et la procédure complète est dans validation/VALIDATION.md. Comparez n'importe lequel d'entre eux au binaire correspondant dans output/FullBatchRun.json : les UUID d'interface, les nombres de méthodes/opnums et les directions de paramètres correspondent (par exemple, l'interface 12E65DD8-... de winlogon affiche cinq méthodes, Proc0-Proc4, dans les deux). L'outil de référence s'arrête à la récupération de l'IDL ; cet outil prend la même surface récupérée et ajoute par-dessus le classement accessibilité x danger. Aucune affiliation avec ce projet ; il est utilisé uniquement comme vérification indépendante de vérité terrain.

Limitations

• Statique uniquement. Rien n'est invoqué. L'accessibilité est déduite de l'enregistrement, pas au moment de l'exécution.

• Les scores Needs-Review sont provisoires jusqu'à ce que le nombre de méthodes ait été vérifié visuellement.

Restez informé

Cet outil fait partie de mes recherches en cours sur ALPC/RPC et les internals de Windows. Je publierai d'autres découvertes et des outils compagnons dans un avenir proche. Si vous avez trouvé cela utile, pensez à me suivre sur GitHub ou sur mes réseaux sociaux ci-dessous pour être notifié des prochaines publications.

Utilisation responsable

Un outil statique de triage / cartographie pour la recherche de vulnérabilités sur des systèmes que vous possédez. Il signale la surface d'attaque, pas les vulnérabilités. Tout ce que vous trouverez ensuite dans les interfaces qu'il met en évidence doit passer par une divulgation coordonnée (MSRC) avant toute divulgation publique.

Licence

MIT