ToolShell reloaded: SharePoint-Forensik nach dem Machine-Key-Diebstahl
19.07.2026 sharepointtoolshellweb-shell-forensicsincident-response
Im Juli 2025 erschütterte „ToolShell" die On-Premises-Welt von Microsoft SharePoint: Eine Kette aus vier CVEs erlaubte unauthentifizierten Remote-Code-Execution auf Enterprise-Servern weltweit. Ein Jahr später, im Juli 2026, taucht der Name wieder auf – diesmal im Zusammenhang mit einem Einbruch in das Homeland Security Information Network (HSIN) des US-Heimatschutzministeriums. Der Fall zeigt exemplarisch, warum SharePoint-Kompromittierungen zu den forensisch anspruchsvollsten Szenarien überhaupt gehören.
Die Anatomie einer Kette, die nicht sterben will
Die ursprüngliche ToolShell-Kette kombinierte zwei bereits gepatchte Schwachstellen mit zwei Zero-Days. Diese Schwachstellen betreffen selbst gehostete SharePoint Server 2016, 2019 und Subscription Edition und ermöglichen unauthentifizierte Remote-Code-Ausführung sowie Sicherheitsumgehungen. Besonders brisant: Die Kombination aus unauthentifizierter Remote-Code-Ausführung und dem Diebstahl kryptografischer Schlüssel schafft einen perfekten Sturm für dauerhafte Kompromittierung und laterale Bewegung.
Genau diese Schlüssel sind der Kern des forensischen Problems. Angreifer extrahieren ASP.NET-Machine-Keys, die zur Signierung von Authentifizierungstoken verwendet werden, was Nutzer-Impersonation und dauerhaften, credential-losen Zugriff ermöglicht, der erste Patching-Versuche überlebt. Ein Server kann also vollständig gepatcht sein und trotzdem kompromittiert bleiben, solange die gestohlenen Schlüssel im Umlauf sind.
Die kanadische Cyber-Sicherheitsbehörde dokumentierte in einer Fallanalyse zudem eine Variante ohne die bekannte Standard-Webshell: Ein zentraler Indikator aus Microsofts Kundenhinweisen, die Datei spinstall0.aspx, wurde im untersuchten Fall nicht gefunden – der Akteur nutzte stattdessen eine neuartige Technik mit individuellen .NET-Payloads, ohne dass ein PowerShell-Prozess durch IIS gestartet wurde. Für Forensiker bedeutet das: Wer sich ausschließlich auf bekannte IOCs verlässt, übersieht maßgeschneiderte Varianten.
Warum Patchen allein die Beweislage nicht rettet
Behörden weltweit mussten nach ToolShell ein ungewohnt striktes Vorgehen kommunizieren. Die Cyber Security Agency of Singapore stellte klar: Patchen allein reicht nicht aus, wenn der SharePoint-Server bereits kompromittiert wurde – Maßnahmen wie die Rotation von Schlüsseln, der Neustart des IIS-Dienstes und die Entfernung von Artefakten wie Webshells sind entscheidend, um das Risiko zu minimieren. CISA ergänzte in ihrer Guidance eine für viele überraschende Reihenfolge: ASP.NET-Machine-Keys müssen rotiert, dann nach dem Sicherheitsupdate erneut rotiert und der IIS-Webserver neu gestartet werden – wird IIS neu gestartet, ohne bösartige Modul-Einträge aus applicationHost.config und web.config manuell zu entfernen, laden diese beim Neustart erneut.
Für die forensische Beweissicherung gilt daher eine strikte Reihenfolge: Ziel der ersten Phase ist es, Kompromittierungsspuren zu erkennen und den Umfang der Verletzung zu bestimmen, ohne den Systemzustand vorschnell zu verändern, was wertvolle forensische Beweise zerstören könnte – diese Phase muss sofort ausgeführt werden. Konkret bedeutet das die Zentralisierung von IIS-Logs, SharePoint-ULS-Logs und Windows-Event-Logs sowie – bei kritischen Systemen – vollständige Disk-Images, um gelöschte Dateien und Zeitleisten offline rekonstruieren zu können.
Der Fall HSIN 2026: Wenn Geschichte sich wiederholt
Im Juli 2026 bestätigte das DHS einen Einbruch in HSIN, wobei parallel eine neue Schwachstelle, CVE-2026-45659, in den KEV-Katalog von CISA aufgenommen wurde. Nach bisherigem Kenntnisstand erlangte ein unbekannter Bedrohungsakteur zwischen Ende Mai und Anfang Juni 2026 unautorisierten Zugriff auf HSIN, wobei die Angreifer sowohl HSIN-Server als auch ein für die behördenübergreifende Zusammenarbeit genutztes SharePoint-System angriffen. Die Reaktion fiel ungewöhnlich scharf aus: CISA gab Bundesbehörden bis zum 4. Juli Zeit, den Fix unter der Binding Operational Directive 26-04 anzuwenden – ein ungewöhnlich enges Drei-Tage-Fenster und ein starkes Signal, dass aktive Ausnutzung bereits irgendwo in der Bundesverwaltung im Gange ist. Zudem gilt: Es handelt sich um einen CWE-502-Deserialisierungsfehler mit CVSS 8.8, für dessen Auslösung ein authentifizierter Angreifer laut Microsoft-Advisory nichts weiter als Site-Member-Rechte benötigt – die niedrigste SharePoint-Zugriffsstufe.
Für DFIR-Teams ist die Lehre eindeutig: SharePoint-Deserialisierungsketten sind kein einmaliges Ereignis, sondern eine wiederkehrende Angriffsklasse. Wer nach einem ToolShell-artigen Vorfall nur den CVE schließt, riskiert, dass die eigentliche Hintertür – gestohlene Schlüssel, persistente Module, manipulierte Config-Dateien – unentdeckt bleibt und beim nächsten verwandten CVE erneut ausgenutzt wird.
← Zurück zur Übersicht