MS‑RPC e UUID in Windows: guida completa alla mappatura di servizi e interfacce

Come ottenere la mappatura tra servizi MS‑RPC e relativi UUID in ambienti Windows: criteri di unicità, versionamento e procedure operative per estrarre & documentare gli endpoint da host locali o remoti con strumenti nativi, SDK e tecniche di analisi del traffico.

Indice

Mappatura dei servizi MS‑RPC ai rispettivi UUID: guida pratica e completa

In molti contesti di amministrazione, hardening, audit e troubleshooting è necessario rispondere a domande molto concrete: “dove trovo l’UUID di una certa interfaccia RPC?”, “posso avere una tabella completa dei mapping servizio ⇄ interfacce ⇄ UUID?”, “come gestisco le versioni?”. Questa guida mette in fila i concetti fondamentali e, soprattutto, fornisce un percorso operativo per ricostruire la mappatura sul tuo ambiente, che è l’unica fonte realmente completa e affidabile.

Domande tipiche e aspettative

Esiste una tabella pubblica e completa che elenca ogni servizio MS‑RPC con il suo UUID?
Un servizio può avere più UUID? Due servizi differenti possono condividere lo stesso UUID?
Esistono UUID “di gruppo” per combinazioni di servizi?
Come si gestiscono le versioni di un’interfaccia (major/minor) e la relazione con gli UUID?

Risposte rapide (sintesi)

Tema	Soluzione / conclusione
Tabella completa dei mapping	Non esiste un catalogo pubblico onnicomprensivo mantenuto da Microsoft. Gli UUID “ufficiali” si trovano nelle specifiche, nei file IDL/ACF dei kit di sviluppo e, soprattutto, enumerando il tuo host (Endpoint Mapper, Registro, strumenti come `rpcdump` o RpcView).
Unicità dell’UUID	L’UUID è definito per essere globalmente unico. Due servizi differenti non condividono lo stesso UUID di interfaccia.
Più UUID per uno stesso servizio	Sì: un servizio Windows può esporre più interfacce RPC, ciascuna con il proprio UUID. Inoltre una stessa interfaccia può comparire in più versioni.
UUID “di gruppo” per combinazioni	No: le interfacce vengono registrate singolarmente. Un’eventuale interfaccia “aggregatrice” avrebbe comunque un proprio UUID, senza “rappresentare” retroattivamente interfacce preesistenti.
Versionamento	Le versioni minor preservano la compatibilità; si cambia UUID o la major quando ci sono rotture di compatibilità. È prassi generare un nuovo UUID per interfacce “breaking”.

Concetti base: cosa mappiamo davvero

MS‑RPC (l’implementazione Microsoft di DCE/RPC) ruota attorno a quattro elementi da distinguere con cura:

Interfaccia RPC: definita in IDL (Interface Definition Language); espone metodi e tipi. Ha un UUID e una versione (major.minor).
Endpoint: punto di contatto concreto su un determinato protocol sequence (es. ncacnnp per named pipe, ncacnip_tcp per TCP/IP, ncalrpc per Local RPC). Esempi: \pipe\spoolss, 135/tcp.
Endpoint Mapper (EPM): servizio standard (porta 135 o \pipe\epmapper) che mantiene la rubrica runtime degli endpoint registrati.
Servizio Windows / processo: uno o più processi che hostano una o più interfacce e registrano gli endpoint presso EPM.

La “mappatura” che interessa agli operatori è quindi un many‑to‑many:

Servizio → più interfacce (UUID) → più endpoint (e viceversa, una singola interfaccia può essere raggiungibile su più endpoint, es. TCP e named pipe).

Perché non esiste un elenco universale (e perché non ne serve uno)

Le interfacce RPC non sono statiche: ogni versione di Windows, ruolo server, componente opzionale o applicazione di terze parti può aggiungerne di nuove. Microsoft pubblica gli IDL per molte interfacce nei kit SDK/WDK e nelle “Open Specification”, ma il tuo parco macchine potrebbe ospitare un sottoinsieme (o un superset) diverso. L’unico catalogo completo è quello che puoi costruire interrogando i tuoi host. Il vantaggio? Ottieni informazioni precise, contestualizzate (versioni, endpoint, processi) e aggiornate allo stato reale dell’ambiente.

Come ottenere la mappatura sul tuo ambiente

Metodo A – Enumerazione runtime dall’Endpoint Mapper

È il metodo più fedele alla realtà, perché riflette ciò che è effettivamente registrato e raggiungibile in quel momento.

Strumento: rpcdump.exe dal Windows SDK o strumenti equivalenti. In alternativa, strumenti grafici come RpcView permettono una vista per processo.
Approccio: interrogare epmapper (135/tcp o \pipe\epmapper) per ricevere la lista di tuple {UUID, Versione, Protseq, Endpoint, Annotations}.
Output atteso: per ciascuna interfaccia, vedrai l’UUID, la versione (es. 3.0), i protocolli (TCP/NP/LRPC) e l’endpoint (es. \pipe\spoolss o la porta dinamica TCP).

Esempio illustrativo semplificato (valori di UUID di fantasia):

# Interrogazione EPM (localhost)
UUID: a1b2c3d4-e5f6-47a1-9123-0abcde123456 v1.0
  Annotation : Spooler Service Remote Protocol
  Protseq    : ncacn_np      Endpoint: \pipe\spoolss
  Protseq    : ncacniptcp  Endpoint: 49675
  Process    : spoolsv.exe (PID 812)

UUID: e1af8308-5d1f-11c9-91a4-08002b14a0fa v3.0
Annotation : RPC Endpoint Mapper
Protseq    : ncacniptcp  Endpoint: 135
Protseq    : ncacn_np      Endpoint: \pipe\epmapper
Process    : RpcSs (svchost.exe)

Buone pratiche:

Esegui l’enumerazione da un account con privilegi sufficienti, specialmente su host remoti.
Ripeti in più momenti (avvio, stato operativo, manutenzione) per cogliere variazioni.
Serializza i risultati (CSV/JSON) e versionali in un repository interno.

Metodo B – Analisi locale del Registro di sistema

Il Registro contiene metadati di registrazione RPC utili a ricostruire una parte del mapping. La chiave più utile è:

HKLM\SOFTWARE\Microsoft\Rpc\Interface\

Qui, ogni sottochiave tipicamente corrisponde a una specifica interfaccia (identificata dal suo UUID). A seconda dei componenti installati potresti trovare sottochiavi per versioni, definizioni degli stub, annotazioni e talvolta informazioni sugli endpoint preferiti. Non sempre avrai gli stessi dettagli che trovi a runtime su EPM, ma è una vista complementare preziosa.

Script PowerShell per enumerare le interfacce dal Registro (robusto su varianti del layout, produce un CSV):

$base = 'HKLM:\SOFTWARE\Microsoft\Rpc\Interface'
$out  = @()

if (Test-Path $base) {
  Get-ChildItem $base | ForEach-Object {
    $uuidKey = $_
    $uuid    = $uuidKey.PSChildName
    # Prova a raccogliere eventuali metadati al livello dell'UUID
    $meta    = Get-ItemProperty -Path $uuidKey.PSPath -ErrorAction SilentlyContinue
    $ann     = $meta.Annotation
    $vers    = @()
    # Alcune installazioni hanno sottochiavi per versione (es. "3.0", "1.0")
    Get-ChildItem $uuidKey.PSPath -ErrorAction SilentlyContinue | ForEach-Object {
      $v = $_.PSChildName
      if ($v -match '^\d+(\.\d+)?$') { $vers += $v }
    }
    if (-not $vers) { $vers = @($meta.Version) | Where-Object { $_ } }

    $out += [pscustomobject]@{
      UUID        = $uuid
      Versions    = ($vers -join ', ')
      Annotation  = $ann
      RegistryKey = $uuidKey.PSPath
    }
  }
  $csv = Join-Path $env:TEMP ('rpc-interfaces-' + $env:COMPUTERNAME + '.csv')
  $out | Sort-Object UUID | Export-Csv -Path $csv -NoTypeInformation -Encoding UTF8
  Write-Host "Esportato: $csv"
} else {
  Write-Warning "Chiave non trovata: $base"
}

Cosa aspettarsi: un CSV con le colonne UUID, Versions (se rilevate), Annotation (quando disponibile) e la chiave di registro d’origine per analisi manuale.

Metodo C – Vista per processo con RpcView

Se ti serve capire quale processo ospita quale interfaccia, uno strumento come RpcView offre una rappresentazione orientata al processo: per ogni PID visualizza le interfacce (UUID e versioni) insieme agli endpoint e alle binding. È utilissimo per correlare “servizio ⇄ interfacce ⇄ porte/pipe” e prendere decisioni di hardening o risposta agli incidenti.

Metodo D – Analisi del traffico con Wireshark

Per audit, forensics o debugging di interoperabilità, puoi catturare traffico e cercare i pacchetti Bind e Alter Context DCE/RPC. Ogni bind include l’Interface UUID e la Interface Ver.. Filtri utili:

dcerpc
dcerpc.cnbindto_uuid
dcerpc.cnbindto_uuid ==  e1:af:83:08:5d:1f:11:c9:91:a4:08:00:2b:14:a0:fa  # esempio

In questo modo puoi vedere quali interfacce vengono effettivamente negoziate su rete, con quali versioni e su quali protocolli (TCP, SMB/named pipe, ecc.).

Relazioni, casi d’uso e mappature “tipiche”

Per dare concretezza, riportiamo alcune mappature operative frequenti (senza impegnare UUID specifici, che variano per interfaccia/versione ma sono facilmente estraibili con i metodi descritti):

Servizio / componente	Endpoint (esempi)	Protocol sequence	Note operative
Print Spooler	\pipe\spoolss; porta TCP dinamica	ncacnnp, ncacnip_tcp	Espone più interfacce (gestione code, stampanti, driver). Verificare versioni per compatibilità client.
LSA / Policy (LSARPC)	\pipe\lsarpc	ncacn_np, ncalrpc	Di frequente consultato da strumenti di gestione identità & policy; richiede attenzioni di hardening.
SAM Remote (SAMR)	\pipe\samr	ncacn_np	Operazioni su account e gruppi. Tipicamente protetto da ACL e criteri di rete.
Service Control Manager (SCM)	\pipe\svcctl	ncacn_np	Interfacce per interrogare/controllare i servizi. Usato da strumenti di gestione remota.
Netlogon	\pipe\netlogon	ncacn_np	Presente su DC; operazioni di autenticazione/registrazione. Spesso soggetto a controlli specifici.
Remote Registry	\pipe\winreg	ncacn_np	Gestione Registro remoto. Disabilitarlo dove non necessario riduce la superficie d’attacco.
Task Scheduler (AT / SchedSvc)	\pipe\atsvc	ncacn_np	Programmazione attività. Interfacce storiche ancora presenti per compatibilità.
Endpoint Mapper	\pipe\epmapper; 135/tcp	ncacnnp, ncacnip_tcp	Rubrica degli endpoint. Non ospita le interfacce applicative, ma ne pubblica gli endpoint.

Nota: per ottenere gli UUID specifici associati a queste interfacce nel tuo ambiente, utilizza il Metodo A (EPM) o C (RpcView). È comune trovare più interfacce per ciascun servizio, ognuna con il proprio UUID e (talvolta) più versioni.

Unicità, versionamento e compatibilità: linee guida operative

Unicità

Un UUID di interfaccia è globalmente unico. È scelto dall’autore dell’IDL (tipicamente con generatori come uuidgen) e poi “congelato”.
Due interfacce diverse non condividono lo stesso UUID.

Versioni (major.minor)

La minor cresce per evoluzioni compatibili (aggiunta di metodi in fondo, estensione non breaking, correzioni di bug).
La major cambia quando si introducono rotture di compatibilità (firma dei metodi, semantica, rimozioni).
Regola pratica: nuovo UUID per una nuova interfaccia non compatibile; altrimenti valuta l’incremento della major mantenendo o meno l’UUID in base alla strategia di compatibilità e deploy in campo.

Compatibilità client/server

Un client con minor più bassa può in molti casi parlare con un server con minor più alta, se la major coincide.
Quando la major differisce, è consigliabile — e spesso necessario — negoziare una nuova interfaccia (e quindi un nuovo UUID).

Flusso operativo consigliato per costruire un catalogo aziendale

Definisci il perimetro: server critici (AD DS, file/print, SQL, Exchange, app line-of-business), desktop golden image, jump host, strumenti di gestione.
Automatizza l’enumerazione EPM (Metodo A): periodicamente e dopo patch importanti. Salva JSON/CSV con timestamp.
Correla con i processi (Metodo C): conserva mappature {PID, processo, servizio} ⇄ {UUID, versione, endpoint}.
Arricchisci con il Registro (Metodo B): utile per stabilità e metadati anche quando l’endpoint non è attivo al momento dell’enumerazione.
Versiona e confronta: differ tra snapshot per evidenziare nuove interfacce o variazioni su versioni/endpoint.
Documenta policy: per ogni interfaccia esposta all’esterno del segmento, definisci motivazione, proprietario, compensazioni (FW, ACL SMB, segmentazione).

Esempio di pipeline con PowerShell (parsing generico)

Di seguito un esempio che mostra come parsare grossolanamente l’output di uno strumento di enumerazione (testo) per estrarre tuple {UUID, Versione, Protseq, Endpoint}. Adatta le regex al formato del tuo strumento.

$text = Get-Content -Path '.\epm-output.txt' -Raw

$uuidRe   = '(?&lt;UUID&gt;[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})'
$verRe    = 'v(?&lt;Ver&gt;\d+(\.\d+)?)'
$psRe     = 'Protseq\s:\s(?&lt;PS&gt;\w+)'
$epRe     = 'Endpoint\s:\s(?&lt;EP&gt;[\\\/\w\.\-:]+)'

$records = @()

foreach ($block in ($text -split "(?ms)^UUID:\s")) {
  if ($block -notmatch $uuidRe) { continue }
  $uuid = [regex]::Match($block, $uuidRe).Groups["UUID"].Value
  $ver  = [regex]::Match($block, $verRe).Groups["Ver"].Value
  $psm  = [regex]::Matches($block, $psRe)
  $epm  = [regex]::Matches($block, $epRe)

  for ($i = 0; $i -lt [Math]::Max($psm.Count, $epm.Count); $i++) {
    $ps = if ($i -lt $psm.Count) { $psm[$i].Groups["PS"].Value } else { $null }
    $ep = if ($i -lt $epm.Count) { $epm[$i].Groups["EP"].Value } else { $null }
    $records += [pscustomobject]@{
      UUID     = $uuid
      Version  = $ver
      Protseq  = $ps
      Endpoint = $ep
    }
  }
}

$records | Sort-Object UUID, Protseq | Export-Csv -Path .\rpc-endpoints.csv -NoTypeInformation
Write-Host "CSV creato: .\rpc-endpoints.csv"

Tip: arricchisci questi dati con una join su Get-Process / Get-CimInstance Win32_Service per associare PIDs/processi/servizi a endpoint locali.

FAQ, casi limite e insidie

Due servizi diversi possono condividere lo stesso UUID?

No. Se osservi collisioni apparenti, stai in realtà vedendo la stessa interfaccia ospitata da più processi/servizi (ad esempio per motivi di architettura o isolamento), oppure output “normalizzato” che confonde interfacce differenti. Verifica sempre l’UUID completo e la versione.

Lo stesso servizio ha più UUID: è normale?

Sì. È routine che un servizio esponga più interfacce: amministrazione, query, eventi, gestione oggetti, ecc. Ogni interfaccia ha un proprio UUID e spesso anche più binding (TCP, NP, LRPC).

Esistono UUID “di gruppo” per pubblicare combinazioni di servizi?

No. Gli UUID identificano interfacce, non bundle di servizi. Puoi definire un’interfaccia che chiama internamente più componenti, ma avrà comunque il suo UUID e non sostituirà quelli delle interfacce chiamate.

Come gestire le versioni in applicazioni interne

Congela l’UUID alla prima release pubblica.
Incrementa la minor per aggiunte compatibili (metodi “append‑only”, estensioni opzionali).
In caso di breaking change, valuta un nuovo UUID o una nuova major deliberata. Evita “silenziosamente” di cambiare la semantica sotto la stessa versione.
Documenta in IDL gli range di versioni supportati dai client.

Perché vedo endpoint TCP “dinamici” diversi ad ogni riavvio?

Molte interfacce su ncacniptcp usano porte effimere assegnate al volo. La risoluzione avviene via Endpoint Mapper (135/tcp): il client contatta EPM, recupera l’endpoint effimero corrente e poi esegue il bind all’interfaccia desiderata.

È possibile “nascondere” un’interfaccia disabilitando EPM?

No. L’EPM è infrastrutturale. L’hardening si realizza limitando i protocolli (es. disabilitare ncacn_np dove non serve), applicando ACL/Firewall e riducendo la superficie d’attacco disabilitando servizi non necessari o limitandone la pubblicazione a segmenti di rete dedicati.

Come riconosco un UUID in file di log e tracciati?

Usa una regex robusta per GUID/UUID, ad esempio:

[0-9a-fA-F]{8}-([0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}

Playbook di troubleshooting

Scenario: un client non riesce a connettersi a una funzione di stampa remota

Con EPM estrai l’UUID e l’endpoint correnti dell’interfaccia di stampa.
Verifica protocolli attivi: se il client prova ncacnnp ma il server espone solo ncacnip_tcp, correggi i binding o la configurazione.
Controlla Firewall e segmentazione per l’endpoint TCP pubblicato (porta effimera).
Esamina versioni: se il client supporta v2.0 ma il server pubblica v1.0, attiva compatibilità o aggiorna il componente.

Scenario: hardening di un server

Snapshot degli endpoint via EPM ➜ CSV.
Classifica: necessari (funzioni core) vs opzionali (diagnostica, legacy).
Per ciascun endpoint non necessario su ncacn_np, valuta la disattivazione o il confinamento in LRPC (ncalrpc) se l’uso è locale.
Applica regole FW basate su profili e scope IP; verifica che la risoluzione via 135/tcp funzioni solo da reti autorizzate.

Checklist per creare (e mantenere) un inventario degli UUID

Enumerazione EPM programmata (almeno mensile, e comunque dopo patch major).
Normalizzazione con schema: Host, Timestamp, UUID, Version, Protseq, Endpoint, Process, ServiceName, Annotation.
Rilevazione differenze: alert su nuovi UUID esposti e su endpoint che cambiano protocol/porta.
Allineamento con CMDB: collega ogni interfaccia a un service owner e a una justification (perché è esposta).
Runbook di decommission: quando un servizio viene rimosso, verifica che le sue interfacce non siano più registrate presso EPM.

Appendice A — Glossario essenziale

MS‑RPC: implementazione Microsoft del framework DCE/RPC.
UUID: identificatore globale univoco di un’interfaccia RPC.
IDL: linguaggio di definizione dell’interfaccia (metodi, tipi, versioni).
Protocol sequence: trasporto/trasporto‑incapsulamento (es. ncacniptcp, ncacn_np, ncalrpc).
Endpoint: concreto punto di contatto (porta/pipe) su uno specifico protocol sequence.
Endpoint Mapper (EPM): servizio che mappa {UUID,Version} ⇄ {Protseq,Endpoint} a runtime.

Appendice B — Best practice di sviluppo IDL

Genera l’UUID una sola volta e inseriscilo nell’IDL; non rigenerarlo a ogni build.
Documenta chiaramente i contratti: per ciascun metodo, eccezioni, buffer, semantica.
Usa l’incremento minor per estensioni compatibili; assegna un nuovo UUID quando rompi la compatibilità.
Aggiungi un’Annotation significativa durante la registrazione per semplificare la vita agli operatori.

Appendice C — Esempio di tabella di mappatura locale

Un esempio di tabella (dati esemplificativi, UUID fittizi) come potrebbe uscire dal tuo pipeline:

Host	Processo/Servizio	Interfaccia (UUID)	Versione	Protseq	Endpoint	Annotation
FILESRV01	spoolsv.exe (Print Spooler)	a1b2c3d4-e5f6-47a1-9123-0abcde123456	1.0	ncacn_np	\pipe\spoolss	Spooler Service Remote Protocol
FILESRV01	spoolsv.exe (Print Spooler)	a1b2c3d4-e5f6-47a1-9123-0abcde123456	1.0	ncacniptcp	49675	Spooler Service Remote Protocol
DC01	lsass.exe (LSA)	0f1e2d3c-4b5a-6978-8091-a2b3c4d5e6f7	3.0	ncacn_np	\pipe\lsarpc	Local Security Authority Policy
DC01	RpcSs (svchost.exe)	e1af8308-5d1f-11c9-91a4-08002b14a0fa	3.0	ncacniptcp	135	Endpoint Mapper

Un catalogo reale avrà decine o centinaia di righe per host; l’importante è mantenere lo schema dati coerente nel tempo in modo da poter confrontare facilmente gli snapshot.

Conclusioni operative

Non inseguire un elenco “assoluto”: costruisci il tuo inventario con enumerazioni periodiche e IDL di riferimento.
Accetta la natura many‑to‑many: uno stesso servizio può (e spesso deve) avere più interfacce/UUID.
Gestisci il versionamento: usa la minor per evoluzioni compatibili, un nuovo UUID o la major per breaking change.
Usa strumenti e automazione: EPM, Registro, RpcView, parsing e pipeline in PowerShell sono gli ingredienti fondamentali.

Appendice D — Checklist di sicurezza (hardening rapido)

Riduci l’esposizione di ncacn_np (named pipe) alle sole reti fidate; preferisci ncalrpc per funzioni locali.
Segmenta e filtra l’accesso a 135/tcp (EPM) e alle porte dinamiche RPC secondo il principio del minimo privilegio.
Monitora nuove registrazioni di endpoint: possono indicare installazioni non autorizzate o modifiche di configurazione.
Allinea le patch di sicurezza dei componenti che espongono interfacce RPC note.

Appendice E — Modello di policy interna per interfacce RPC

Oggetto: Policy di pubblicazione interfacce RPC
Scopo : Definire criteri di pubblicazione, versionamento e monitoraggio
1) Ogni nuovo servizio deve dichiarare le interfacce RPC (UUID, versioni, endpoint, protseq).
2) Per ciascuna interfaccia indicare: owner, business justification, ambito di rete, requisiti FW.
3) Versionamento: minor per evoluzioni compatibili; nuovo UUID per breaking change.
4) Monitoraggio: snapshot EPM settimanale e dopo change/patch; differ e revisione.
5) Decommission: rimozione/chiusura endpoint verificata e firmata dal service owner.

Riferimenti pratici interni

SDK/WDK aziendali con IDL compilate per audit interno.
Repository di script (PowerShell) per enumerazione EPM e parsing output.
Runbook SOC/NOC per triage di problemi RPC (con esempi di filtri Wireshark e checklist di verifica).

In sintesi

Non esiste una “tavola periodica” universale degli UUID MS‑RPC, e non serve: con l’enumerazione runtime dell’Endpoint Mapper, l’analisi del Registro, l’uso di strumenti come RpcView e una pipeline minima in PowerShell puoi costruire — e mantenere — l’unico catalogo che conta: quello del tuo ambiente. L’unicità dell’UUID, la granularità per interfaccia e il versionamento major/minor ti danno gli strumenti per pianificare compatibilità e hardening in modo rigoroso.

Q&A finale (promemoria)

Tabella completa pubblica? No, ricavala da documentazione + enumerazione del tuo ambiente.
Due servizi con stesso UUID? No.
Più UUID per un servizio? Sì, tramite più interfacce.
UUID “comune” per combinazioni? No, ogni interfaccia è registrata singolarmente.
Versioni diverse => UUID nuovi? Solo per breaking change; altrimenti cresce la minor con la stessa major.

Pronti a partire: prendi uno snapshot EPM oggi stesso, salva i risultati, e costruisci il tuo primo inventario di interfacce. Avrai uno strumento prezioso per governance, sicurezza e diagnosi.