RPC-Triage

Statico vs dinamico, leggete questo prima. Vale la pena chiarire subito il confine tra analisi dinamica e statica: questo strumento esegue la sua classificazione esclusivamente tramite analisi statica. Legge le strutture MIDL/NDR compilate direttamente dal binario e non esegue mai nulla.

Triage statico per la superficie d'attacco RPC di Windows. Puntatelo su una cartella di eseguibili PE; trova tutti quelli che registrano un server RPC, recupera le firme dei metodi NDR di ogni interfaccia, i binding di trasporto e i flag di registrazione direttamente dalle strutture MIDL compilate, e poi classifica ogni interfaccia in base a raggiungibilità x pericolosità con una ricevuta aritmetica completa allegata a ogni punteggio, così potete verificare i calcoli a mano.

Gli strumenti RPC esistenti recuperano volentieri le firme dei metodi di un'interfaccia e i suoi flag di registrazione. Quello che nessuno di essi fa è prendere entrambi e rispondere all'unica domanda che decide davvero dove spendete il vostro tempo: dato che posso raggiungere questa interfaccia, e dato ciò che i suoi metodi accettano come input, con quanta urgenza dovrei esaminarla rispetto a tutto il resto sulla macchina? È questo vuoto che questo strumento colma.

Cosa fa

• Filtra la cartella di destinazione in modo che Ghidra analizzi automaticamente solo i binari che registrano effettivamente un server RPC (importano rpcrt4.dll e chiamano una delle API RpcServerRegisterIf\*). Su System32 è la differenza tra un pomeriggio e una settimana.

• Estrae, per ogni interfaccia: UUID, la catena RPC_SERVER_INTERFACE / MIDL_SERVER_INFO, l'autorevole DispatchTableCount, l'opnum di ogni metodo + le direzioni dei parametri + gli opcode NDR decodificati, i flag di registrazione (R9), la presenza della security-callback ("bouncer"), il security descriptor (best-effort) e i binding di endpoint / trasporto.

• Classifica ogni interfaccia pulita su due assi indipendenti e li moltiplica in un unico punteggio composito 0-100, suddiviso in bucket Critical / High / Moderate / Low.

• Si spiega da solo: ogni punteggio include una stringa di ricevuta che elenca ogni componente e l'aritmetica che ha prodotto il numero finale.

Come funziona

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

Dipendenza zero da simboli: Un differenziatore tecnico critico di questo motore è che opera interamente senza simboli di debug. Percorrendo programmaticamente le dispatch table e analizzando i bytecode NDR (Network Data Representation) grezzi e le strutture MIDL compilate direttamente dalla memoria, lo strumento bypassa la necessità dei file .pdb di Microsoft o di query live all'endpoint mapper. Questo garantisce che il motore funzioni out-of-the-box su binari System32 stripped e di produzione, esattamente come vengono distribuiti.

Requisiti

• Ghidra 11.x (usa il support/analyzeHeadless incluso). Serve una JDK 17+ nel PATH.

• Python 3.8+ sul lato driver, con pefile.

• Lo script di estrazione viene eseguito sotto la Jython 2.7 inclusa in Ghidra - nessuna importazione di terze parti, nulla da installare lì.

• Obiettivi: file PE Windows x64. L'analisi in sé è indipendente dal sistema operativo (Ghidra è multipiattaforma), quindi non è necessario eseguirla su Windows.

Installazione

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

requirements.txt: pefile>=2023.2.7

Utilizzo

Tutto è gestito da orchestrator.py: filtra, importa, analizza ed esegue l'estrattore per voi.

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

Prima esecuzione vs esecuzioni successive (importante). La prima esecuzione fa la parte lenta: filtra, importa i binari corrispondenti, esegue l'analisi automatica completa, poi inserisce un marcatore .analysisComplete in --projdir. Ogni esecuzione successiva sullo stesso progetto salta importazione/analisi (-process -noanalysis) e riesegue solo lo script sui programmi già analizzati. Quindi analizzare System32 è un costo una tantum e iterare sull'output è economico. Se l'analisi viene interrotta, il marcatore non viene scritto e lo strumento elimina il progetto parziale (.rep / .gpr) e ricomincia da zero.

Output

Un file JSON: un elenco di binari, ciascuno con un array Interfaces. Un'esecuzione completa su System32 è inclusa in questo repository in output/FullBatchRun.json; è l'output grezzo e non curato, così potete vedere esattamente cosa produce lo strumento su larga scala. Per ogni interfaccia:

Tag; il gate di igiene dei dati:

• Clean: recuperato in modo pulito; classificato normalmente.

• Needs-Review: classificato, ma la scansione della dispatch table ha superato il conteggio stored (di solito un blocco thunk finale). Il punteggio è reale ma riporta [Provisional]; verificate il conteggio dei metodi prima di citarlo.

• Diagnostics / Diagnostics (2): la riga è un artefatto di estrazione (una stringa ASCII agganciata erroneamente come UUID e/o un puntatore MIDL corrotto). Non classificato (Rank: N/A). Questi vengono mantenuti apposta: segnalano lo stato di salute dello strumento, non sono superficie d'attacco.

La nota FLAG: Walked X != Stored Y . Il DispatchTableCount stored è autorevole ed è ciò che usa ogni punteggio. Il conteggio ottenuto dalla scansione è un controllo incrociato indipendente di eseguibilità; quando i due non coincidono (comunemente un 2x pulito) l'interfaccia viene taggata Needs-Review così sapete di controllarla. Non cambia mai silenziosamente un punteggio.

Come leggere una ricevuta di punteggio

Questa è la parte che rende un punteggio discutibile:

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]

Leggetela da sinistra a destra:

1. Moderate/35: tier e punteggio composito.

2. Gate:35 [...]: l'asse di raggiungibilità. Parte dalla base di trasporto (ncacn_np:41, una named pipe), poi elenca ogni modificatore di registrazione con il suo contributo con segno: MultiEndpointBonus:15 (registrata su più trasporti), HasBouncer:-46 (è presente una security callback, che abbassa la raggiungibilità) e BouncerIsNotCaching:+25. Sommati e poi limitati a [5,100] -> 35.

3. Surface:100 [...]: l'asse di pericolosità. Ogni segnale attivato è Nome:conteggio x(opnums):direzione:peso, es. HasBogusStruct si è attivato su 1 parametro (opnum 5) e il suo peso è 61. Poi un contributo basato sul conteggio: InPtrs:6:18 = 6 in-pointer controllati dal chiamante che contribuiscono +18, Count:12:6 = 12 metodi aggiungono +6. Il è la somma pre-cap, , è il moltiplicatore di confidenza (scende a 0.5 quando le firme sono incerte); Surface finale .

Un secondo esempio che mostra il clamp e lo sconto per bassa confidenza:

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 da solo porta il gate sotto zero, quindi si limita al minimo di 5; le firme erano incerte quindi Surface è dimezzato (* 0.5); il composito arriva a 3. Spazio di input pericoloso, ma di fatto irraggiungibile -> correttamente de-prioritizzato.

Tier

Critical >= 75, High >= 50, Moderate >= 25, Low altrimenti (un'interfaccia con superficie recuperata zero è Low indipendentemente dal gate). Le soglie si basano sul composito; il modello dietro di esse è in docs/Surface_Scoring_Methadology.md.

Il modello di punteggio

Tutte e tre le tabelle dei pesi (basi di trasporto, modificatori del gate, segnali di superficie) sono derivate con il Processo Analitico Gerarchico; confronti a coppie, pesi a media geometrica e un rapporto di consistenza misurato. La derivazione completa, le matrici, i numeri di consistenza e le note calcolate a mano sono in docs/Surface_Scoring_Methadology.md.

Validazione

Affinché l'estrazione non sia solo auto-confermante, le interfacce recuperate da questo strumento sono state verificate in modo incrociato con un estrattore IDL RPC indipendente e affermato (il parser RpcServer in NtObjectManager di James Forshaw) eseguito sugli stessi binari. I dump di riferimento per lsass, samsrv e winlogon sono in validation/, e la procedura completa è in validation/VALIDATION.md. Confrontate uno qualsiasi di essi con il binario corrispondente in output/FullBatchRun.json: gli UUID delle interfacce, i conteggi di metodi/opnum e le direzioni dei parametri coincidono (ad esempio, l'interfaccia 12E65DD8-... di winlogon mostra cinque metodi, Proc0-Proc4, in entrambi). Lo strumento di riferimento si ferma al recupero dell'IDL; questo strumento prende la stessa superficie recuperata e aggiunge la classificazione raggiungibilità x pericolosità. Nessuna affiliazione con quel progetto; viene usato puramente come controllo indipendente di ground truth.

Limitazioni

• Solo statico. Nulla viene invocato. La raggiungibilità è inferita dalla registrazione, non a runtime.

• I punteggi Needs-Review sono provvisori finché il conteggio dei metodi non viene verificato visivamente.

Rimanete aggiornati

Questo strumento fa parte della mia ricerca in corso su ALPC/RPC e internals di Windows. Pubblicherò ulteriori risultati e rilascerò strumenti companion nel prossimo futuro. Se lo avete trovato utile, prendete in considerazione di seguirmi su GitHub o sui miei social qui sotto per essere notificati dei prossimi rilasci.

Uso responsabile

Uno strumento di triage / mappatura statico per la ricerca di vulnerabilità su sistemi di vostra proprietà. Riporta la superficie d'attacco, non le vulnerabilità. Qualsiasi cosa troviate nelle interfacce che evidenzia dovrebbe passare attraverso la divulgazione coordinata (MSRC) prima di qualsiasi dettaglio pubblico.

Licenza

MIT