Seit ein paar Tagen erreichen mich in meinen Projekten immer mehr besorgte Fragen zu den SharePoint-Sicherheitslücken, die unter dem Namen ToolShell (CVE-2025-53770 und CVE-2025-53771) bekannt geworden sind. Wer noch SharePoint Server On-Premises oder eine hybride Umgebung betreibt, dürfte durch die Meldungen von Microsoft und die CVE-Einträge bereits aufgeschreckt worden sein. Die Lücken werden tatsächlich aktiv ausgenutzt, und die Angreifer haben es gezielt auf Systeme abgesehen, die aus dem Internet erreichbar sind. SharePoint-Online-Kunden können diesmal aufatmen, denn betroffen sind ausschließlich On-Premises-Installationen. Wie ernst die Lage ist, sieht man schon daran, dass Microsoft in kürzester Zeit Sicherheitsupdates für SharePoint Server Subscription Edition und 2019 bereitgestellt und Handlungsempfehlungen veröffentlicht hat. Das Update für 2016 kam wenig später.

Über ToolShell führen Angreifer beliebigen Code auf SharePoint-Servern aus

Durch die Schwachstellen können Angreifer auf ungepatchten SharePoint-Servern beliebigen Code ausführen. Insbesondere CVE-2025-53770 wird schon für gezielte Angriffe genutzt. Am stärksten gefährdet sind Systeme, die direkt oder über eine Port-Weiterleitung aus dem Internet erreichbar sind – in vielen hybriden Szenarien leider immer noch gängige Praxis. Im Kundenhinweis von Microsoft und im CVE-Portal sind die wichtigsten Maßnahmen aufgeführt: Updates installieren, die AMSI-Integration im „Full Mode“ mit Defender Antivirus aktivieren, die ASP.NET-Machine-Keys rotieren und kompromittierte Systeme isolieren. Wie sich AMSI im Detail konfigurieren lässt, beschreibt der offizielle Artikel auf Microsoft Learn.

# PowerShell auf dem SharePoint-Server (Admin, mit aktuellstem CU)
Set-SPAMSIIntegrationConfig -Enabled $true -Mode Full
Restart-Service w3svc # IIS neu starten

Voraussetzung dafür sind SharePoint Server 2019/Subscription Edition, ein aktuelles CU und ein aktiver Defender Antivirus.

Fünf Sofortmaßnahmen sichern betroffene Server Schritt für Schritt ab

Wer SharePoint Server noch produktiv nutzt, darf sich auf keinen Fall auf automatische Updates oder das Standard-Monitoring verlassen. In vielen Tenants, die ich betreue, laufen noch hybride Farmen, häufig mit kaum dokumentierten Internetzugängen für Extranet, Workflow-Apps oder individuelle Integrationen. Im Moment sind diese Maßnahmen am wichtigsten:

  • Sicherheitsupdates so schnell wie möglich auf allen SharePoint-Servern einspielen
  • AMSI-Integration im Full Mode zusammen mit Defender Antivirus aktivieren
  • ASP.NET-Machine-Keys umgehend rotieren (z. B. mit Set-SPMachineKey oder Update-SPMachineKey)
  • Aus dem Internet erreichbare Server nach Möglichkeit sofort isolieren
  • Nach Indicators of Compromise (IoCs) sowie verdächtigen Prozessen und Dateien suchen

Ausgerechnet die Rotation der Machine Keys fällt oft unter den Tisch, obwohl sie bei einer möglichen Kompromittierung entscheidend ist. Fehlt dieser Schritt, können Angreifer unter Umständen weiterhin Sessions oder Tokens missbrauchen. Die passenden PowerShell-Befehle finden sich im Guidance-Artikel von Microsoft.

Lokale und hybride Server bleiben das eigentliche Grundproblem

Die aktuelle Angriffswelle führt wieder einmal vor Augen, wie verwundbar lokale und hybride SharePoint-Server sind. Viele Unternehmen haben den Großteil ihrer Workloads längst nach SharePoint Online verlagert. Für Spezialfälle, Integrationen oder Altanwendungen laufen aber weiterhin On-Prem-Server, oft mit Internetzugang oder schwachen Netzwerkgrenzen. Gepatcht wird selten so zügig wie nötig, und ein erweitertes Monitoring (z. B. Defender for Identity) fehlt häufig. Hybride Umgebungen mit Synchronisation oder Single Sign-On sind besonders beliebte Angriffsziele, weil sie Cloud und lokale Ressourcen miteinander verbinden. Wer noch On-Prem-Server betreibt, sollte seine Architektur kritisch hinterfragen und ernsthaft über eine Migration nachdenken. Ein „Cloud first“-Ansatz reicht nicht, solange Altlasten mitlaufen.

Praktischer Tipp: Wer den Überblick über seine SharePoint-Server verloren hat, sollte kurzfristig ein Inventar erstellen und den Internetzugang dieser Systeme zentral steuern, notfalls auch nur mit einem vorübergehenden Geo-Blocking an der Firewall.

Typische Indikatoren verraten einen bereits kompromittierten Server

Ob ein SharePoint-Server schon kompromittiert ist, lässt sich mit dem klassischen Ereignisprotokoll oft nicht zuverlässig feststellen. Typische Hinweise sind verdächtige Prozesse, nicht signierte DLLs im Bin-Verzeichnis von SharePoint oder ungewöhnliche PowerShell-Skripte. Wer Defender einsetzt, sollte den Server gezielt scannen und die Funde anschließend im Microsoft-Defender-Portal auswerten. Darüber hinaus helfen EDR-Lösungen oder spezialisierte Monitoring-Tools dabei, Anomalien aufzuspüren.

Das Vorgehen der Angreifer lässt sich mit einer einfachen Grafik gut veranschaulichen:

flowchart TD
Internet["Internet"] --> Attack["Angriff auf Port 443/80"]
Attack --> SharePointServer["SharePoint-Server (ungepatcht)"]
SharePointServer --> CodeExec["Code-Ausführung"]
CodeExec --> Persist["Persistenz/Seitwärtsbewegung"]
Persist --> HybridBridge["Hybrid-Verbindung zur Cloud"]
HybridBridge --> CloudTenant["Cloud-Tenant (potenziell)"]

Abbildung: So gelangen Angreifer mit ToolShell über ungepatchte SharePoint-Server in hybride Umgebungen.

Von einem kompromittierten On-Prem-Server aus kann ein Angreifer weiter in Richtung Cloud vordringen oder andere Ziele im Netzwerk ansteuern, vor allem dann, wenn privilegierte Konten oder Konnektoren eingebunden sind. Spätestens hier kommen Themen wie Privileged Identity Management und Conditional Access für Hybrid-Admins ins Spiel.

SharePoint On-Premises bleibt auf Dauer ein Risiko

Für mich ist der ToolShell-Vorfall eine weitere deutliche Warnung. Selbst vollständig gepatcht und bestmöglich gehärtet bleiben lokale und hybride Server der wunde Punkt vieler Microsoft-Umgebungen. Die Komplexität nimmt von Jahr zu Jahr zu, und mit ihr wächst der Aufwand für Security-Monitoring und Incident Response. Wer heute noch On-Premises-Workloads betreibt, kommt an konsequentem Patch-Management, regelmäßiger Key-Rotation und restriktiven Netzwerkregeln nicht vorbei. Auf lange Sicht führt aber nur die Migration in die Cloud wirklich nachhaltig aus diesen wiederkehrenden Bedrohungen heraus. Für Spezialfälle lohnt es sich, Alternativen wie App-Services oder modernisierte Workflows zu prüfen, denn jeder Server weniger zählt. Und wer jetzt patcht, sollte sich nicht in Sicherheit wiegen, sondern schon mit dem nächsten Angriff rechnen.