SharePoint /_trust WS-Federation-Deserialisierung: PoC- & Erkennungshinweise

Live-Dokumentation (GitHub Pages): https://sp-poc.wismansec.com/ (HTML-Darstellung dieses Dokuments).

Betroffen: SharePoint Server 2016, 2019 und Subscription Edition.

Rekonstruktion eines Eindringens in einen SharePoint Server (Subscription Edition) in einer isolierten Lab-Umgebung, erstellt, um (a) die vollständigen Angriffsmöglichkeiten zu verstehen, (b) zu ermitteln, wonach ein Verteidiger suchen sollte, einschließlich verdeckter Persistenz, und (c) einen PoC zu teilen, um andere Ermittler zu unterstützen.

Nur autorisierte Forschung. Alles hier wurde auf isolierter, persönlich besitzener Labor-Hardware und mit eigenen Konten durchgeführt, gegen einen Build, der für den Test bewusst ungepatcht gelassen wurde. Das zugrunde liegende Problem wird vom Hersteller behoben; installieren Sie die aktuellen Updates. Führen Sie dies nicht gegen Systeme aus, die Sie nicht besitzen und für die Sie keine ausdrückliche Testgenehmigung haben. Maschinenschlüssel-Werte, interne Hostnamen/IPs und Callback-Domains sind im Text und in den Beispiel-Artefakten geschwärzt. Die SIEM-Screenshots sind unverändert und tragen die echten Namen des Labors; siehe Hinweis in §4.

• Von: WismanSec
• Fix: Juli-2026-Updates (KB5002882)
• Zugehörige CVEs (dieses Cluster, CISA-KEV-gelistet): CVE-2026-50522, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644
• Schwachstellenklasse: die Familie der /_trust-SecurityContextToken-BinaryFormatter-Deserialisierung

---

TL;DR für Responder

• Ein einzelner nicht authentifizierter POST /_trust/default.aspx (WS-Federation-Anmeldung) mit einem bösartigen SecurityContextToken löst im SharePoint-Workerprozess (w3wp.exe) eine BinaryFormatter-Deserialisierung aus und ermöglicht Remote-Codeausführung mit der Identität des Web-App-Pools.
• Dieselbe Primitive kann die Farm-Maschinenschlüssel (ValidationKey/DecryptionKey) vollständig im Prozess auslesen. In einer Farm mit Standardkonfiguration: kein Kindprozess, kein AV-Alarm, kein Beacon (das Aktivieren der AMSI-Anforderungsbody-Prüfung für /_trust erkennt und blockiert sie; siehe §5). Mit diesen Schlüsseln kann ein Angreifer __VIEWSTATE/Authentifizierungstokens fälschen, die das Patchen überstehen.
• Patchen allein reicht nicht. Rotieren Sie die Maschinenschlüssel auf jeder Farm, die Sie als betroffen vermuten, und suchen Sie nach der /_trust-Anforderungssignatur, die das einzige Artefakt ist, das in jeder Variante vorhanden ist.

---

1. Die Schwachstelle

SharePoint stellt einen passiven WS-Federation-Anmeldeendpunkt unter /_trust/default.aspx bereit. Eine manipulierte Anmeldeantwort (wa=wsignin1.0 + wresult=<RequestSecurityTokenResponse>) bettet ein SecurityContextToken ein, dessen <Cookie>-Element ein base64-kodierter, DEFLATE-komprimierter BinaryFormatter-Stream ist. Serverseitig wird dieses Cookie dekomprimiert und ohne Typeinschränkung deserialisiert, sodass eine Gadget-Kette (über ysoserial.net) vom Angreifer kontrollierten Code in w3wp.exe ausführt.

Anforderungsskelett (nicht authentifiziert):

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. Zwei Ketten aus einer Primitive

Kette	Gadget	Wirkung	Ausgabekanal
OOB-RCE	TypeConfuseDelegate → -EncodedCommand-PowerShell	Codeausführung mit Identität des Anwendungspools	out-of-band (HTTP/DNS-Beacon)
Maschinenschlüssel-Offenlegung	ActivitySurrogateDisableTypeCheck → ActivitySurrogateSelectorFromFile (kompiliert KeyDump.cs prozessintern)	gibt ValidationKey/DecryptionKey aus	inline in der HTTP-Antwort

Skripte (bereinigt) in scripts/: eine parametrisierte OOB-RCE und der zweistufige Schlüssel-Dump. Die Payload-Zustellung verwendet PowerShell -EncodedCommand, sodass mehrzeilige Payloads die cmd.exe-/Transportebenen intakt überstehen (keine ;/&&-Quoting-Probleme).

3. Labor

Eine einzelne SharePoint-SE-Farm (Build auf Stand vor dem Fix fixiert), App-Pool-Identität LAB\sp_pool, PowerShell 5.1, Microsoft Defender mit Cloudschutz aktiviert. Telemetrie (Windows-Ereignisprotokoll, SharePoint-Protokolle, Defender for Endpoint) wurde an nano, ein leichtgewichtiges Open-Source-SIEM, übertragen; der Angreifer-Host lief mit ysoserial.net; ein interactsh-Client stellte den OOB-Listener bereit. Adressen und Domains sind im Text geschwärzt; siehe Screenshot-Hinweis in §4.

4. Ergebnisse: Aufruf → Artefakt-Matrix

Jede Zeile ist eine echte Detonation; Artefakte stammen pro Lauf aus dem SIEM + OOB-Listener.

Screenshots sind unverändert. Sie tragen die echten Host- und NetBIOS-Namen des Labors, die grob sind und sich von den bereinigten SHAREPOINT01 / LAB im gesamten Text unterscheiden. Gleiche Läufe, gleiche Ereignisse, nichts inszeniert. Arbeitssichere Äquivalente in artifacts/.

Aufruf	Prozessbaum (als LAB\sp_pool, High)	Defender	OOB-Beacon	Primäre Artefakte
OOB-RCE, Standard	w3wp.exe → cmd.exe → powershell.exe → conhost.exe	Behavior:Win32/WebshellLauncher.A (EID 1116 erkennen / 1117 Entfernen)	eingegangen (Wettlauf)	4688-Baum; Defender 1116/1117; /_trust-POST
OOB-RCE, -RawCmd	w3wp.exe → powershell.exe → conhost.exe (ohne cmd)	keine	eingegangen (DNS+HTTP)	4688-Baum; /_trust-POST; Beacon
OOB-RCE, -DropFile	w3wp.exe → powershell.exe	keine	eingegangen	Datei geschrieben nach …\TEMPLATE\LAYOUTS\ (nicht im objektzugriffsüberwachten Protokoll)
OOB-RCE, -Diag	w3wp.exe → powershell.exe → whoami.exe	keine	eingegangen	Umgebungs-Offenlegung exfiltriert: {host, whoami, PSver, LanguageMode}
Maschinenschlüssel-Dump	(keine, prozessintern)	keine	(keine)	nur der /_trust-POST + anomale Antwort mit den Schlüsseln

Diese Ergebnisse gelten für die Standard-AMSI-Konfiguration (Balanced-Modus, /_trust nicht gescannt). Mit aktivierter AMSI-Anforderungsbody-Prüfung für /_trust (Full-Modus oder gezielt) wird jede Zeile stattdessen auf der Anforderungsebene blockiert: HTTP 400, Exploit:Script/SpCookieExec.A, vor der Ausführung (siehe §5).

Jede RCE-Detonation in einer Abfrage

Alle vier dokumentierten Detonationen, 15:01 bis 15:18 UTC, jeder Kindprozess von w3wp.exe läuft mit der Pool-Identität. Drei der vier sind direkt erzeugte powershell.exe-Prozesse. Nur der Lauf um 15:03:34 geht durch cmd.exe, und nur dieser Lauf wurde erkannt. Erweitert man das Zeitfenster über diesen hinaus, gelangen frühere Entwicklungsiterationen vom selben Morgen in die Ergebnismenge, daher gilt die Aussage nur für diese vier Läufe.

Derselbe Exploit, zwei Prozessbäume

Standard-Aufruf: w3wp.exe → cmd.exe → powershell.exe, mit conhost.exe daneben. Dies ist die Form, auf die Behavior:Win32/WebshellLauncher.A anspricht.