SharePoint /_trust Deserializzazione WS-Federation: PoC e Note di Rilevamento

Writeup live (GitHub Pages): https://sp-poc.wismansec.com/ (rendering HTML di questo documento).

Interessati: SharePoint Server 2016, 2019 e Subscription Edition.

Ricostruzione di un'intrusione in SharePoint Server (Subscription Edition) in un laboratorio isolato, realizzata per (a) comprendere la piena capacità dell'attaccante, (b) determinare cosa un difensore dovrebbe cercare, inclusa la persistenza stealth, e (c) condividere un PoC per aiutare altri investigatori.

Solo ricerca autorizzata. Tutto ciò che è descritto qui è stato eseguito su hardware e account di laboratorio isolati e di proprietà personale, contro una build volutamente lasciata senza patch per il test. Il problema di fondo è risolto dal vendor; applicare gli aggiornamenti correnti. Non eseguire questo contro sistemi che non possiedi e per i quali non hai esplicita autorizzazione al test. I valori delle machine key, i nomi host/IP interni e i domini di callback sono oscurati nel testo e negli artefatti di esempio. Gli screenshot del SIEM non sono modificati e riportano i nomi reali del laboratorio; vedere la nota nel §4.

• Di: WismanSec
• Fix: aggiornamenti di luglio 2026 (KB5002882)
• CVE correlate (questo cluster, elencate in CISA KEV): CVE-2026-50522, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644
• Classe di vulnerabilità: la famiglia di deserializzazione BinaryFormatter del SecurityContextToken di /_trust

---

TL;DR per i responder

• Una singola POST /_trust/default.aspx non autenticata (accesso WS-Federation) con un SecurityContextToken malevolo innesca la deserializzazione BinaryFormatter nel worker di SharePoint (w3wp.exe), ottenendo esecuzione remota di codice come identità del pool di applicazioni web.
• La stessa primitiva può estrarre le machine key della farm (ValidationKey/DecryptionKey) interamente in-process. In una farm con configurazione predefinita: nessun processo figlio, nessun alert AV, nessun beacon (l'abilitazione della scansione del body della richiesta AMSI per /_trust lo rileva e lo blocca; vedere §5). Quelle chiavi permettono a un attaccante di forgiare token __VIEWSTATE/di autenticazione che sopravvivono al patching.
• Applicare le patch non basta. Ruotare le machine key su qualsiasi farm che si ritiene colpita e cercare la firma della richiesta /_trust, che è l'unico artefatto presente in ogni variante.

---

1. La vulnerabilità

SharePoint espone un endpoint di accesso passivo WS-Federation su /_trust/default.aspx. Una risposta di accesso creata ad hoc (wa=wsignin1.0 + wresult=<RequestSecurityTokenResponse>) incorpora un SecurityContextToken il cui elemento <Cookie> è uno stream BinaryFormatter compresso DEFLATE e codificato in base64. Lato server, quel cookie viene decompresso e deserializzato senza restrizioni di tipo, quindi una gadget chain (tramite ysoserial.net) esegue codice controllato dall'attaccante dentro w3wp.exe.

Scheletro della richiesta (non autenticata):

POST /_trust/default.aspx HTTP/1.1
Content-Type: application/x-www-form-urlencoded

wa=wsignin1.0&wctx=<url>&wresult=<RequestSecurityTokenResponse>...
  <SecurityContextToken><Cookie>BASE64(DEFLATE(BinaryFormatter payload))</Cookie>...

2. Due chain da un'unica primitiva

Chain	Gadget	Effetto	Canale di uscita
RCE OOB	TypeConfuseDelegate → -EncodedCommand PowerShell	esecuzione di codice come identità del pool	out-of-band (beacon HTTP/DNS)
Divulgazione delle machine key	ActivitySurrogateDisableTypeCheck → ActivitySurrogateSelectorFromFile (compila KeyDump.cs in-process)	estrae ValidationKey/DecryptionKey	inline nella risposta HTTP

Script (sanitizzati) in scripts/: una RCE OOB parametrizzata e il key-dump in due fasi. La consegna del payload usa PowerShell -EncodedCommand così i payload multi-istruzione sopravvivono intatti ai layer cmd.exe/di trasporto (nessuna rottura di quoting con ;/&&).

3. Laboratorio

Farm SharePoint SE singola (build fissata pre-fix), identità del pool di applicazioni LAB\sp_pool, PowerShell 5.1, Microsoft Defender attivo con protezione cloud. La telemetria (Windows Event Log, log di SharePoint, Defender for Endpoint) veniva inviata a nano, un SIEM open-source leggero; l'host attaccante eseguiva ysoserial.net; un client interactsh forniva il listener OOB. Indirizzi e domini sono oscurati nel testo; vedere la nota sugli screenshot nel §4.

4. Risultati: matrice invocazione → artefatto

Ogni riga è una detonazione reale; artefatti estratti dal SIEM + listener OOB per ogni esecuzione.

Gli screenshot non sono modificati. Riportano i nomi host e NetBIOS reali del laboratorio, che sono grezzi e diversi da quelli sanitizzati SHAREPOINT01 / LAB usati nel testo. Stesse esecuzioni, stessi eventi, nulla di messo in scena. Equivalenti sicuri per il lavoro in artifacts/.

Invocazione	Albero dei processi (come LAB\sp_pool, High)	Defender	Beacon OOB	Artefatti principali
RCE OOB, predefinita	w3wp.exe → cmd.exe → powershell.exe → conhost.exe	Behavior:Win32/WebshellLauncher.A (EID 1116 rilevamento / 1117 rimozione)	arrivato (gara)	albero 4688; Defender 1116/1117; POST /_trust
RCE OOB, -RawCmd	w3wp.exe → powershell.exe → conhost.exe (senza cmd)	nessuno	arrivato (DNS+HTTP)	albero 4688; POST /_trust; beacon
RCE OOB, -DropFile	w3wp.exe → powershell.exe	nessuno	arrivato	scrittura file in …\TEMPLATE\LAYOUTS\ (non nel log con audit degli accessi agli oggetti)
RCE OOB, -Diag	w3wp.exe → powershell.exe → whoami.exe	nessuno	arrivato	esfiltrazione di informazioni sull'ambiente: {host, whoami, PSver, LanguageMode}
Dump delle machine key	(nessuno, in-process)	nessuno	(nessuno)	solo la POST /_trust + risposta anomala con le chiavi

Questi esiti valgono per la configurazione AMSI predefinita (modalità Balanced, /_trust non scansionato). Con la scansione AMSI del body della richiesta su /_trust abilitata (modalità Full o mirata), ogni riga viene invece bloccata al livello della richiesta: HTTP 400, Exploit:Script/SpCookieExec.A, prima dell'esecuzione (vedere §5).

Ogni detonazione RCE, in una sola query

Tutte e quattro le detonazioni documentate, dalle 15:01 alle 15:18 UTC, ogni figlio di w3wp.exe in esecuzione come identità del pool. Tre su quattro sono powershell.exe generati direttamente. Solo l'esecuzione delle 15:03:34 passa da cmd.exe, e solo quella è stata rilevata. Allargando la finestra oltre questa, anche le iterazioni di sviluppo precedenti della stessa mattina entrano nel set di risultati, quindi l'affermazione è limitata a queste quattro esecuzioni.

Lo stesso exploit, due alberi di processi

Invocazione predefinita: w3wp.exe → cmd.exe → powershell.exe, con conhost.exe affiancato. Questa è la forma su cui fa leva Behavior:Win32/WebshellLauncher.A.